Clean Code

I've just finished reading Clean Code of Uncle Bob.
The main ideas are:

-Deja el código más limpio de lo que lo encontrarte (Leave the campground cleaner than you found it.)

 

-Single Responsibility Principle

 

-Dependency Inversion Principle

 

-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.Make your names pronounceable.If you can’t pronounce it, you can’t discuss it without sounding like an idiot.

 

-The more we read the code, the less we see the prefixes. Eventually the prefixes become unseen clutter and a marker of older code.

 

-One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king. Professionals use their powers for good and write code that others can understand.

 

-A class name should not be a verb.

 

-Methods should have verb.

 

-Choose clarity over entertainment value. Don’t Be Cute.

 

-Choosing technical names for those things is usually the most appropriate course.

 

-In an imaginary application called “Gas Station Deluxe,” it is a bad idea to prefix every class with GSD.

 

-Functions should be very small.

 

-Functions should hardly ever be 20 lines long.

 

-Do one thing.

 

-Passing a boolean into a function is a truly terrible practice. This function
does more than one thing.

 

-Try/catch blocks are ugly in their own right. They confuse the structure of the code and
mix error processing with normal processing. So it is better to extract the bodies of the try and catch blocks out into functions of their own.

 

-It preffers throw exceptrions than error codes.

 

-Don’t Use a Comment When You Can Use a Function or a Variable.

 

-Few practices are as odious as commenting-out code.

 

-Small files are usually easier to understand than large files are. Between 500 and 200 lines of code.

 

-Width code file: I used to follow the rule that you should never have to scroll to the right. I personally set my limit
at 120.

 

-Every programmer has his own favorite formatting rules, but if he works in a team, then the team rules.

 

-We want the software to have a consistent style. We don’t want it to appear to have been written by a bunch of disagreeing individuals.

 

-Use Exceptions Rather Than Return Codes. The algorithm and error handling, are separated.

 

-Write Your Try-Catch-Finally Statement First. This helps you define what the user of that code should expect, no matter what goes wrong with the code that is executed in the try.

 

-Don’t Return Null. It’s easy to say that the problem is that it is missing a null check, but in actuality, the problem is that it has too many. If you are tempted to return null from a method, consider throwing an exception or returning a SPECIAL CASE object instead. If you are calling a null-returning method from a third-party API, consider wrapping that method with a method that either throws an exception or returns a special case object.

 

-Don’t Pass Null. Returning null from methods is bad, but passing null into methods is worse.

We can write robust clean code if we see error handling as a separate concern, something that is viewable independently of our main logic.

 

-Law of TDD:

• First Law You may not write production code until you have written a failing unit test.
• Second Law You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
• Third Law You may not write more production code than is sufficient to pass the currently failing test.

-The moral of the story is simple: Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care. It must be kept as clean as production code.

-If your tests are dirty, then your ability to change your code is hampered, and you begin to lose the ability to improve the structure of that code. The dirtier your tests, the dirtier your code becomes. Eventually you lose the tests, and your code rots.

-What makes a clean test? The same thing that makes all code readable: clarity, simplicity, and density of expression.

-One Assert per Test.

-Single Concept per Test.

-Smaller is the primary rule when it comes to designing classes. Single Responsibility Principle (SRP). Classes should have one responsibility. For example five methods.

 

-Many developers fear that a large number of small, single-purpose
classes makes it more difficult to understand the bigger picture. They are concerned that they must navigate from class to class in order to figure out how a larger piece of work gets accomplished. However, a system with many small classes has no more moving parts than a system with a few large classes. There is just as much to learn in the system with a few large classes.

-We want our systems to be composed of many small classes, not a few large ones. Each small class encapsulates a single responsi-bility, has a single reason to change, and collaborates with a few others to achieve the desired system behaviors.

-When cohesion is high, it means that the methods and variables of the class are co-dependent and hang together as a logical whole.

-Classes should be open for extension but closed for modification: Open-Closed Principle (OCP).

-the Dependency Inversion Principle (DIP).5 In essence, the DIP says that our classes should depend upon abstractions, not on concrete details.

-A powerful mechanism for separating construction from use is Dependency Injection (DI), the application of Inversion of Control (IoC) to dependency management.3 Inversion of Control moves secondary responsibilities from an object to other objects that are dedicated to the purpose, thereby supporting the Single Responsibility Principle. In the context of dependency management, an object should not take responsibility for instantiating dependencies
itself. Instead, it should pass this responsibility to another “authoritative” mechanism, thereby inverting the control. Because setup is a global concern, this authoritative mechanism will usually be either the “main” routine or a special-purpose container. Sometimes we have to use proxy pattern, for controling and separate the different issues of each class.

-“data transfer objects” (DTOs), that are essentially “structs” with no behavior, to copy data from one object to another.

-Duplication is the primary enemy of a well-designed system. It represents additional work, additional risk, and additional unnecessary complexity. Somtine we have to use The TEMPLATE METHOD pattern for removing the duplication code.