Clean code part 1
Let's start to talk about clean code thinking about Robert C. Martin (Uncle Bob), Martin Fowler and other great software developers. Their talks and books help us every day to be more professional and do our job better. Let's start to gather some definitions of clean and bad code.
CLEAN CODE is...
- When you need maximum 5 minutes to understand the code
- Easy to read and scroll on your IDE \ editor
- The code does exactly what you expect
- Short, with good function names (often even long) and variables well named to understand their aim. The variable names must explain what the variable do, why it has been created and his role on the function.
- Easy to extend and update
- The code must respect all S.O.L.I.D principles.
BAD CODE is..
- Legacy code is bad. It slows you down and it increase your technical debt. Write unit tests and do a lot of refactoring to increase to quality of your code and put your system under test (SUT).
- No unit test on the production code (no continuous integration)
- Hard to mantain, extend and update
- No separation from UX and business model (someone is not agree)
- Procedural code, especially if you have a long list of instructions
- Long functions. Even if it seems diffcult, try to split functions. Use more classes, wrappers but try to keep functions as short and simple as possible.
- It contains the famous code smells.
- Too many dependencies: try to eliminate dependecies because they can become hard to understand. Handle code and objects with dependecies is more diffucult than handle simple and indipendent classes
Nothing can slow you down than bad code. If the product has bad code, the whole product is a mess! Even if it works! Because you'll find many troubles updating, maintaining and releasing a new feature. If you have legacy code, work effectively to refactor every single file, every line of code, optimize and find the bottle neck to reduce lines of code, charge of work, code smells and everything is not clear on your code at first glance. Use object oriented programming and polymorphism as best you can to replace conditionals and cycles. It will be very useful to have a sequence of instructions that will do exactly what you expect. Don't be afraid to update your code, the unit tests will say you if you have broken something on your code. For this reason Martin Fowler recommends to eliminate dependencies if you can.
Trying to think when and why an user will use my software... I want to write software for a specific utility only. Forget the database, forget configurations, patterns, programming languages... The only thing I need is make a web page of a software fast, small and user-friendly for the use himself. This will allow you to isolate the problem solution and think only about every single use case. You'll discover you can avoid many operations, reduce your code and optimize your software in many different ways.
Some citations of my favorite experts:
- "Every fool can write code that a computer can compile. Good developers can write code that the other humans can understand" - Martin Fowler
- "The only way to go fast is to go well" Uncle Bob
- "Nothing can slow you down than bad code" Uncle Bob