“Uncle” Bob Martin has written a book called Clean Code. This post just mentions a few pointers from the below-mentioned video of Bob. What does he mean by clean code? It is code that other coders can easily understand. It’s more important to write code for other coders to understand than to write code for the computer to understand. In other words, Uncle Bob would rather have us write code that he can easily read and understand that doesn’t work, than code that works perfectly that is difficult to understand. Why? Because if he understands it he can fix it. If he doesn’t understand and he needs to change it, he might even have to re-write the entire thing.
“Good code matters.” – Kent Beck.
Here are some more pointers from the talk. Code is difficult to write and therefore nobody gets all of their code to work perfectly the first time they write it. Once they do get it to work, they should spend time cleaning it because it will be messy. Just because you tested the code with a few different variables and scenarios does not mean that you are done with that code. If this were not the case and all code is clean, Uncle Bob wasted his time writing his book called Clean Code. You want to write code fast, then write really really good and clean code, which requires you to go back over your code and improve it. You want your code to never be surprising. Each line of code should be pretty much what you expected.
Keep your code simple and well documented. Use names that make sense. Write code like your care about the programmer that is reading your code. Keep your functions small. Your functions should only do one thing. If they do many things that extract them and break them down into more than one function. This will result in your functions being only a few lines long, at most. Try to keep your functions to 3 or fewer arguments.
Have a look at the YouTube video called Clean Code.
Function names should be verbs since functions do things. Every line of a function should be at the same level of abstraction. Functions should be small. Functions should only do one thing. You know that your function only does one thing when you cannot meaningfully extract another function from it. Bob says extract, extract, extract. If you have a very very large function, you may find that what you really have is a class with some fields (variables) and a bunch of methods. Names of functions should be very descriptive. The reader can understand easily and escape early, meaning they can move on to something else quickly. Readers of your code should be able to tell quickly what the code does because of your naming of variables and functions.
What types of variable should you mostly never pass into a function? Booleans. Why not? If you are passing in a boolean you probably have an if statement in the function that has at least two possible outcomes which is really two different functions that perhaps are better off being located in the code that called the function with the boolean argument. Another “rude” and “unclean” thing to do is to pass output arguments into a function.
Here is a list of the chapters of Bob Martin’s book Clean Code
- Clean Code
- Meaningful Names
- Functions
- Comments
- Formatting
- Objects and Data Structures
- Error Handling
- Boundaries
- Unit Tests
- Classes
- Systems
- Emergence
- Concurrency
- Successive Refinement
- JUnit Internals
- Refactoring SerialDate
- Smells and Heuristics
- Appendix A Concurrency II
- Appendix B org.jfree.date.SerialDate
- Appendix C Cross References of Heuristics
Here are some more thoughts from Bob Martin. Avoid switch statements. If you have some of them, seriously consider refactoring your code. Switch statements make your code less maintainable, which is not good. Prefer exceptions to returnig error codes. When Bob writes a try block, the only thing in the function that contains the try block is the try block. There is nothing before the try block and nothing after the try block. Any code that is there (before or after) should be in a separate function. Why? Error processing is one thing and our functions should only do one thing. Never write nested try catch blocks!
To keep track of side effects in your code you can follow a couple of rules. Functions that return void by definition must have a side effect, otherwise, there is no need to ever call them. Functions that return something should never have any side effects. A side effect changes the state of the system. This means that you can call that function as often as you wish and the state of the system is never changed. Interesting.