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 of 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 does, 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 increases 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 maintain, extend and update
- No separation from UX and business model (someone does not agree)
- Procedural code, especially if you have a long list of instructions
- Long functions. Even if it seems difficult, 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 dependencies because they can become hard to understand. Handle code and objects with dependencies is more difficult than handle simple and independent 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 bottleneck to reduce lines of code, a 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.
USE CASES
Trying to think when and why a 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 to make a web page of software fast, small and user-friendly for the user 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.
CITATIONS
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