Hace una semana, publicaba un pequeño resumen y mis apuntes sobre el libro “Clean Coder” de Robert C. Martin (ver parte I). Hoy hago lo propio con el resumen del libro de la misma colección, “Clean Code”.

Os dejo cosas que subrayé y anoté del libro que me parecieron interesantes, espero que lo disfrutéis.

In software, 80% or more of what we do is quaintly called “maintenance”: the act of repair.

 

In about 1951, a quality approach called Total Productive Maintenance (TPM) came on the Japanese scene. Its focus is on maintenance rather than on production. One of the major pillars of TPM is the set of so—called 5S principles. 58 is a set of disciplines— and here I use the term “discipline” instructively. These 58 principles are in fact at the foundations of Lean

 

The 5S philosophy comprises these concepts:

– Seiri, or organization (think “sort” in English). Knowing where things are—using approaches such as suitable naming—is crucial. You think naming identifiers isn’t important? Read on in the following chapters.

– Seiton, or tidiness (think “systematize” in English). There is an old American saying: A place for everything, and everything in its place. A piece of code should be where you expect to find it—and, if not, you should re-factor to get it there.

– Seiso, or cleaning (think “shine” in English): Keep the workplace free of hanging wires, grease, scraps, and waste. What do the authors here say about littering your code with comments and commented-out code lines that capture history or wishes for the future? Get rid of them.

– Seiketsu, or standardization: The group agrees about how to keep the workplace clean. Do you think this book says anything about having a consistent coding style and set of practices within the group? Where do those standards come from? Read on.

– Shutsuke, or discipline (self-discipline). This means having the discipline to follow the practices and to frequently reflect on one’s work and be willing to change.

 

There are two parts to learning craftsmanship: knowledge and work. You must gain the knowledge of principles, patterns, practices, and heuristics that a craftsman knows, and you must also grind that knowledge into your fingers, eyes, and gut by working hard and practicing.

 

Learning to write clean code is hard work.

 

You must see them agonize over decisions and see the price they pay for making those decisions the wrong way.

 

You are reading this book for two reasons. First, you are a programmer. Second, you want to be a better programmer. Good. We need better programmers.

 

LeBlanc’s law: Later equals never.

 

But the fault, dear Dilbert, is not in our stars, but in ourselves. We are unprofessional.

 

So too it is unprofessional for programmers to bend to the will of managers who don’t understand the risks of making messes.

 

The only way to make the deadline—the only way to go fast—is to keep the code as clean as possible at all times.

 

Clean code is focused.

 

Leave the campground cleaner than you found it.

 

If a name requires a comment, then the name does not reveal its intent.

 

We should avoid words whose entrenched meanings vary from our intended meaning.

 

Spelling similar concepts similarly is information. Using inconsistent spellings is disinformation.

 

_If a variable or constant might be seen or used in multiple places in a body of code, it is imperative to give it a search-friendly name. _

 

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.

 

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.

 

So, another way to know that a function is doing more than “one thing” is if you can extract another function from it with a name that is not merely a restatement of its implementation

 

A long descriptive name is better than a long descriptive comment.

 

Flag arguments are ugly. Passing a boolean into a function is a truly terrible practice. It immediately complicates the signature of the method, loudly proclaiming that this function does more than one thing. It does one thing if the flag is true and another if the flag is false!

 

We should never ignore any part of code. The parts we ignore are where the bugs will hide.

 

In general output arguments should be avoided. If your function must change the state of something, have it change the state of this owning object.

 

Functions should either do something or answer something, but not both.

 

But never forget that your real goal is to tell the story of the system, and that the functions you write need to fit cleanly together into a clear and precise language to help you with that telling.

 

“Don ’t comment bad code— rewrite it.”

 

The proper use of comments is to compensate for our failure to express ourself in code

 

Comments are always failures

 

Truth can only be found in one place: the code.

 

Objects hide their data behind abstractions and expose functions that operate on that data. Data structure expose their data and have no meaningful functions.

 

Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing functions.

 

The Law of Demeter says that a method f of a class C should only call the methods of these:

– An object created by f

– An object passed as an argument to f

– An object held in an instance variable of C

The method should not invoke methods on objects that are returned by any of the allowed functions. In other words, talk to friends, not to strangers.

 

In learning tests we call the third-party API, as we expect to use it in our application. We’re essentially doing controlled experiments that check our understanding of that API. The tests focus on what we want out of the API.

 

Three laws 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 testing.

 

Test code is just as important as production code.

 

F.I.R.S.T.

Fast: Tests should be fast.

Independent: Tests should not depend on each other.

Repeatable: Tests should be repeatable in any environment.

Self-Validating: The tests should have a boolean output. Either they pass or fail.

Timely: The tests need to be written in a timely fashion.

 

The problem is that too many of us think that we are done once the program works.

 

The startup process of object construction and wiring is no exception. We should modularize this process separately from the normal runtime logic and we should make sure that we have a global, consistent strategy for resolving our major dependencies.

 

According to Kent, 21 design is “simple” if it follows these rules:

• Runs all the tests
• Contains no duplication
• Expresses the intent of the programmer
• Minimizes the number of classes and methods

The rules are given in order of importance.

• agile
• clean code
• robert c martin
• tdd