Skip to content

Instantly share code, notes, and snippets.

@delbetu
Last active December 5, 2016 00:31
Show Gist options
  • Save delbetu/33f04ec80c1d549d99a6bf7c14bdc0f4 to your computer and use it in GitHub Desktop.
Save delbetu/33f04ec80c1d549d99a6bf7c14bdc0f4 to your computer and use it in GitHub Desktop.
Uncle Bob best practices - Functions

Functions

Functions are the first tier of organization Should have as few levels of indent as possible Functions should be well named and should be organized into well named classes within well named namespaces

Function size

Functions should be 4,6 lines.

A function should do one thing, it should do it well and it should do it only

what does one thing means ? If your function is composed of many different sections then is clearly doing more than one thing. If the function manipulates more than one level of abstraction is doing more than one thing. But abstraction levels are fuzzy, this fuzziness is undesirable. We want an un ambiguos way to tell that a function is doing just one thing. This way is continue to extract functions until you cannot extract any more

Large functions tends to hide classes

When you have a function that can be divided into several functional areas and you have variables that are used by all those functional areas then you have Class Since a Class is a group of functions that uses a common set of variables.

Why not make it smaller ?

I didn’t have time to make it smaller It takes time to eliminate redundancy It takes time to organise our thoughts It takes time to make things small Leaving something big is irresponsable, careless, it skip the breaking down your thoughts and explain them at your readers You might be saving yourself a little bit of time but you are costing everyone else a lot of time. Or maybe yourself will have to face same code in future and will have to break down your thoughts and try to understand it spending time doing this. So leaving a function long at the end is going to cost a lot of time and effort.

A large function is a scope

That scope is divided into different sections of functionality Usually seen as mayor indentations Those different sections communicate with each other using variables that are local to the entire scope So what do you have when you got a set of variables in a long scope accessed by many different segments of functionality ? A CLASS!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment