In this short, but nonetheless useful article, I have summarized the most beneficial tips for writing clean code. These rules are independent of the language you use and are invaluable for both beginners and experienced programmers. Martin Golding’s famous quote is: “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” Writing clean code makes the code easier to understand going forward and is essential for creating a successful maintainable product. Programmers are authors, and your target audience is not the computer; it is other programmers (and yourself). “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”- Martin Fowler. To be able to write clean code, you should train your mind over some time. The hardest part is only making a start, but as time goes by and your skillset improves, it becomes easier. Writing clean code is all about readability, so even the smallest things like changing your habits for naming variables make the most significant difference. According to the book “ : A Handbook of Agile Software Craftsmanship” written by Robert C. Martin: code is clean if it can be understood easily — by everyone on the team. With understandability comes readability, changeability, extensibility, and maintainability. Clean Code General rules for writing clean code Follow standard conventions. Simpler is always better. Reduce complexity as much as possible. Always find the root cause. Always look for the root cause of a problem. Be consistent. If you do something a certain way, do all similar things in the same way. Use explanatory variables. Prefer dedicated value objects to primitive types. Avoid logical dependency. Don’t write methods that work correctly depending on something else in the same class. Avoid negative conditionals. Names Use intention revealing names. Choosing proper names takes time but saves more than it takes. The name of a variable, function, or class should answer all the big questions. It should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent. Essential Rules for Names: Choose descriptive and unambiguous names. Make a meaningful distinction. Use pronounceable names. Use searchable names. Functions The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. This implies that the blocks within if statements, else statements, while statements should be one line long. Probably that line should be a function call. Not only does this keep the enclosing function small, but it also adds documentary value because the function called within the block can have a nicely descriptive name. Essential Rules for Functions: Small. Do one thing. Use descriptive names. Prefer fewer arguments (no more than three of them). Have no side effects (Functions must only do what the name suggests and nothing else). Don’t use flag arguments. Split method into several independent methods that can be called from the client without the flag. Comments. Ideally, comments are not required at all. If your code needs commenting, you are doing something wrong. Our code should explain everything. Modern programming languages are English like through which we can easily justify our point. Correct naming can prevent comments. Essential Rules for Comments: Use as an explanation of intent. Use as clarification of code. Use as a warning of consequences. Always try to explain yourself in code. Don’t be redundant. Don’t use closing brace comments. Don’t comment out code. Just remove. Objects and data structures. Objects hide their data behind abstractions and expose functions that operate on that data. Data structure present their data and have no meaningful functions. Essential Rules for Objects and Data Structures: Hide internal structure. Prefer data structures. Avoid hybrids structures (half object and half data). A small number of instance variables. The base class should know nothing about their derivatives. Better to have many functions than to pass some code into a function to select a behavior. Prefer non-static methods to static methods. It may not be possible to apply all of these rules in your daily code in an instant. But as a result, it will bring great satisfaction from your work and sincere gratitude from people who will read the clean code that you wrote. The best books how to write clean code: Clean Code: A Handbook of Agile Software Craftsmanship (By Robert C. Martin); Refactoring: Improving the Design of Existing Code (By Martin Fowler); Code Complete (By Steve McConnell). Have a Happy Clean Code! Sincerely, Dmytro Pogribnyy.
