Who is Uncle Bob?

Writing code is the easy part of programming. Our aspiration is to write clean, maintainable code that reads like well-written prose. Yesterday was the day when I googled "Who is Uncle Bob?". I am glad that I did.

Robert Cecil Martin, colloquially called "Uncle Bob", is an American software engineer, instructor, and best-selling author. He is most recognized for developing numerous software design principles and for being a founder of the influential Agile Manifesto. Martin has authored many books and magazine articles. Wikipedia

I guess most of the developers should already know who Uncle Bob is, but if you are new and you have not heard of him yet, he is the author of well-known books like "Clean Code". Here is a video (also embedded below) that I started watching last night and could not recommend it enough to anyone who cares about code. The amount of energy in this presentation alone is impressive. He must have been the most enthusiastic person that I have ever known who talks about clean code with such affection. The many takeaways I gathered from this talk are included below but I strongly recommend anybody to watch the video. It's entertaining for its own sake. And, who doesn't want to write clean code?!

Some pointers

• Functions should be actions, hence the name of functions should be verbs, not nouns.
• The code within a function body should be at the same level of abstraction, not oscillating from high level to low level or vice versa.
• One aspect of writing code that is polite is to allow readers of the code to leave early if they choose so and yet understand what is going on. It's like reading a newspaper, people can choose to read the headings and focus on the details, and choose to move on to the next article if they are bored.
• Have variables that read well. For example: If (isTestable) {}. Readers understand when the if-statement is executed just from that opening line.
• Functions should be small.
• A function that does one thing means no smaller functions can be extracted out from that function.
• If a single huge size function involves a bunch of local variables and a bunch of methods that manipulate them, it is probably a good idea to turn it into a class.
• Imagine if the body of if-statements only contains a function call, it will be easy to understand what is going to happen should this branch execute.
• Function arguments should be no more than 3. If there is a valid reason to have more, it might be wise to create objects to group those data.
• Usually, don't pass boolean into a function, just make two functions for the two truth values.
• Write code that does not make readers double-take: a line of code in the middle of the function body that is hard to understand and forces readers to re-read the entire piece after finishing it.
• Avoid switch statements. It is harder for the addition of new functionalities or objects. To obey the open-close principle, use a "base class + derivatives" structure that is better for future expansion.
• Separate GUI code into modules away from core logic because GUI changes most often. To independently deploy different modules means we can avoid having code changes for GUI breaking the entire code base.
• Typically, functions that return an object do not change the state. On the other hand, functions that just command and returns nothing will change the state and cause side-effect.
• Functions that handle exceptions should only handle exceptions. For example, a function that contains only the try block, and within the try block it calls a function that might trigger the exception.
• How to get rip of similar duplicated loop structure? Have a function that contains the loop structure and accept lambdas that does different things.
• Science doesn't use experiments to prove what is true. It uses experiments/tests to prove what is incorrect and therefore with enough tests, we call it a day and assume something to be almost true in that context. So, write your damn tests :)