Clean. your. code.

real programming assignment. A substitute teacher came into class and said: ”Oh, no one told you? You HAVE to read Clean Code and make sure to put evidence on your documentation about how and where you used it.” A WEEK AWAY from the deadline. The class went dead silent, I am pretty sure we where all like

But let me tell you, reading that book made my life as a developer a lot easier. Not only because of its rules and principles, but because it helps you to understand the importance of consistence and neatness across the code, regardless if you follow its rules to the tee or you create your own ones. Why people make a huge deal after Clean Code? Because your code should be readable and understandable to any developer who reads it -that includes you- countless times I went back to old projects and couldn't figure out what I was trying to do.

It. is. exhausting.

So, if you follow a pre-meditated set of rules and standards, you will end up with code that is clear and in which changes will be easy peasy lemon squeesy. What is more, asking for help, and getting a fellow dev to understand you will be muuuuuuch easier, and we all want that.

Im going to share with you the things that I am used to doing and that I think help me be more organized and enhance the quality of my code. Of course, this is a bit subjective for example, the book says “Use as little comments as possible”, whereas a lot of people consider comments to be clarifying.

1. Meaningful names

This one is a must.

• Names of classes, variables, methods, functions, must be meaningful and clearly indicate what a method does or what an attribute is.

• Use names that reflect the system domain, context and business logic.

• Avoid acronyms. You might understand it now, but maybe you wont in a couple of weeks when you come back to it.

• Don’t add ‘list’, ‘array’, ‘hash’, etc. to the name, or else you will be tied to a structure, just use the entities' plural. It would be really confusing to have a usersList and then see it was declared as an Array. Stick to ‘users’ and everyone will know they are handling a collection.

2. Functions

• The method should be easy to read and understand, conveying its intention clearly.

• It shouldn’t be too long. The book says 20 lines, this clearly depends on the programming language, but I think 10 is best. If it is longer, it probably is doing one than more thing, and you could divide it in smaller ones, which takes us to the next rule.

• Methods should only do one thing.

• Zero parameters is ideal. Again, it depends on what you are trying to do. But keep the numbers of parameters as small as possible.

3. Comments

Well, this one is really disputed. Some people say that if the code has too many comments is because it is not self-explanatory and therefore not clean enough. Others say comments make the code more readable. In my opinion, unless you are handling a really difficult task, or a complicated algorithm, comments shouldn’t exist. What can I say, I just hate seeing those green things on my screen.

4. Formatting

• Limit of characters per line of code: 120, so you wont have to scroll horizontally to read.

• Use spaces between operators, parameters, and commads.

For this one, I always use IDE formatter extensions, correctly aligned and formatted at the click of a key, no hustle.

5. Error Handling

GOTTA CATCH THEM ALL

When something goes wrong, getting a good error message, has to be one of the greatest joys and I can’t stress this enough, really.

• Mention that it failed. Say where the failure was, and if possible say why it failed.

• When an error happens, you have to get the system to do the right things.

• Never just try to hide errors, catch them and print them, using logs preferably.
  

The book covers many more things like Unit Tests, Refactoring, Classes, but I stated the ones I always apply and that I am more in concordance with. And that is the thing, maybe you don’t agree with everything it says, maybe you like to do things your own way, and that is ok, as long as you (and your team) are consistent through the whole project. That being said, I truly recommend to follow programming languages standards, as teams tend to change a lot, and you will make it easier for the person coming after you.