2017-10-09 09:11:00 UTC
Functions are the first line of an organization in any program, writing them well is very important. I am currently reading Uncle Bob Martin 's Clean code. I like the way he has arranged his thoughts into simple sections in a chapter. In summary, to write clean beautiful functions, here are the rules to follow:
1. Functions should be small
2. Functions should be smaller than the what you got from following rule 1
3. Blocks within if, else, while statements should be one line long (that line should be a function call)
4. A function should always do just one thing and they should do it well: If a function does only those steps that are one level below the stated name of the function, then it's doing one thing.
5. A way to know if a function is doing more than one thing is if you can extract another function from it with a name that is not merely a restatement of its implementation. In those cases extract that other function.
6. Statements within a function should have only one level of abstraction: Mixing levels of abstraction only creates confusion
7. Step Down Rule: When you write a program, every function should be followed by those at the next level of abstractions so anyone can read and follow through the program and understand the flow.
8. In case of switch statement, wherever possible, use Abstract factory and bury the switch statement deep inside this abstract factory
9. Use descriptive names for functions: give descriptive names to public and private methods as well, good names go a long way. Longer names are better if they explain better
10. Use a naming convention that allows multiple words to be easily read in the function name: Don't be afraid to take your time in choosing good names
11. Be consistent with function naming in a module. Use same phrases, nouns, and verbs throughout
12. An ideal number of arguments for a function is zero (niladic). Next, comes one (monadic), followed closely by two (dyadic). Three or more arguments (triadic) should be avoided where possible: Arguments always take conceptual power as well as are harder from a testing point of view
13. Passing a boolean into a function as argument is a truly terrible practice: It says that the function does one thing when the boolean is true, and other when its false: Split the function into two functions with those two cases
14. Dyadic functions (Two arguments): They come at a cost. You need to remember the order. For appending to a file, for example, take the function and make it a member of a class File and call it through the class instance passing just one argument
15. If a function seems to need more than two or three arguments, it is likely that some of the arguments ought to be wrapped in a class of their own or should use a hash(dictionary or you can say an object) instead.
16. Use verbs and keywords to make function names more explainable and explain what it is doing: for e.g. instead of write(name) which is using a verb you can add keyword to explain it better writeField(name)
17. In case of temporal coupling: Indicate that coupling and side effect in the name
18. in case of passing an output argument to a function such as a file to append, separate it using OO principles and call it from within a file instance of a class File
19. Separate command from query: Your function should either change the state of an object or it should return some information about the object, doing both leads to confusion: for e.g. public boolean set(String attribute, String value), the function sets the value of a named attribute and returns true is it is successful and false if no such attribute exists. if we call the function using if (set(*username, *unclebob)), it is unclear if it's setting it successfully or checking an old value. The way to resolve it is to separate the command from the query like check for attributeExists(*username) and then call set
20. Always prefer exceptions over returning error codes: use try-catch or begin rescue to handle any error, error codes adds external dependencies.
21. Extract bodies of begin/rescue into functions of their own
22. Try/catch or begin/recuse should be the only blocks in a function, don't add any more code after that
23. Don't repeat yourself: Use functions and OO objects to avoid repetitions at any cost. Duplication is the root of all evil in software
1.Start with the long complicated easy flow and solve the problem and make it work first, it may have lots of indenting and nested loops, have long argument lists, with arbitrary names and have duplicated codes.
2. Write the tests as well.
3. After that go ahead and refine, split, change names and eliminate duplication using the rules above.
4. If needed extract out a whole class.
Owned & Maintained by Saurav Prakash
If you like what you see, you can help me cover server costs or buy me a cup of coffee though donation :)