Clean Code - Chapter 1 & Chapter 2

Hi readers, in this and other post we are gone learn a little about the chapters of an amazing book, that will be "Clean Code: A Handbook of Agile Software Craftsmanship" of the author Robert C. Martins. In fact this a resume about what he and other professional people and developers said about improve our practices on making good code. So, let's started.

Chapter 1 - Clean Code

In this chapter Martins try to give us an introduction about the meaning of write code, what it this purpose or how we can defined on right way the practices for do - write - quality code.

As a principal point the author signs this: "If you learn from beginning to do bad things and write bad code, some time you will mess up and everything is gone be wrong"; so is a good proposal do right things from beginning, is better do that than try to correct bad practices from people. Is - maybe - a slow way to learn trying to has good practices doing great code, that can help us in the future, than be a machine writing code but making bad code.

When something is wrong with the people that in any project an others come the project because the oldest are gone, they discover that everything is poor, an unstable. So they solution to the problem becomes in a "redesign on the sky" that is too much expensive and doesn't help for the deadline project.

People who know about the business, doesn't waste time trying to solve problems after making a mess, they try to prevent the mess; because a problem can delay the deadline of the project and this affects negative the position of the company. In fact, the better way to prevent that this happens is "KEEP CODE AS CLEAN YOU CAN".

In other case, for help you to keep your code clean, learn the Boy Scout Rule, an boy scout has the rule that they don't leave a place more dirty than they found it. The same pass with code, if you see bad code, try to make it better.

Chapter 2 - Meaningful Names

Well, the title of the book said everything... Meaningful names... Meaningful names... ... ... Always remember that. In this job you always need to be clear about your code, about what you do, about what you trying to solve and invent, about everything. Just like an writer try to be clear for sell his book like a best seller, a programmer need to clear for the other people can understand theirs master pieces.

Let me explain this with an example. Is no the same type:

        int x; // hours of work

than this:

        int laboralHours;

Let's continue, in the first part of the example you see that we need a comment for explain the meaning of the variable, in the second one that wouldn't be necessary; that is ;because in the second one we wrote a meaningful name. The second variable explain for herself the usability of her, and that is a very good practice. 

If we can avoid comments for explain the usability of our variables is better, this doesn't mean that we don't need comments but is better and help us for typed less.

Other tips from the book are: use pronounceable names - don't write something like gendmyhms, than is a generator of days, months, years, hours, minutes and seconds - for your projects, use searchable names, don't be cute, don't repeat names for variables and classes, avoid encoding the names (don't type something that only you can understand), add context to the name (is better a larger variable name than a code than no one can read), don't add funny context to the names, etc...

There exists another rules for type better names, but I leave you the others; because - yes, this is a summary but - the only way to learn something, and learn it right is practising and expend hours trying to understand the meaning of the things.

So, let me know if this help, if is not, the feedback is well received. In the next post we're gone to see Clean Code - Chapter 3 & Chapter 4.

References

Clean Code: A Handbook of Agile Software Craftsmanship
Robert C. Martin