Who do we code for? Concept of coding for machines and humans.

clean code

Once one of my mentors told me about the concept of code and the logic behind who engineers actually are and who do they write code for, the question is simple “Who do we code for??” because my understanding at that time was “We code for machines to perform a specific task that make our lives easy or that that helps in automate or perform a task with much precession.” to which he replied “NO! we code for humans so that they can understand the code better, modify it and resuse it.” the reason was simply that machine understands only binary right? it doesn't care about the coding conventions or anything, It’s us who need these things to get ourselves going and to keep us informed because as a developer sometimes you don’t understand how your own code works.

He recommended me a book called Clean Code by Robert Cecil Martin I’ll be sharing the things I learned from it:

Meaningful Names

• Names of the classes, variables, and methods must be meaningful and clearly indicate what a method does or what an attribute is.
• Create pronounceable names to facilitate communication.
• Avoid acronyms and avoid confusing names, which may bring anyone who reads the code to the wrong conclusions.

Functions

• The method should be easy to read and understand.
• The method should convey its intention.
• The methods should be small. Another rule for small methods is that they should be even lower.
• You should use names with words that say what it really does.
• The optimal number of parameters of a method is zero, after one and two.
• Three should be avoided, but if you think it should be used, have a good justification.
• Parameters of the Boolean type as a parameter already clearly states that it does more than one thing.
• Methods must do something and return something.
• Avoid duplication.

Formatting

• Formatting should indicate things of importance since it is a developer of communication form.
• A messy code is hard to read.
• The readability of the code will take effect on all of the changes that will be made.
• Try to write a class with a maximum of 500 lines. Smaller classes are easier to understand.
• Set a limit of characters per line of code.
• A good character limit on a line is 120.
• Try to keep more next related concepts vertically to create a code stream.
• Use spaces between operators, parameters, and commas.

Comments

• One of the most common reasons for the comments is because the code is bad.
• If you’re thinking about writing a comment, then the code should be refactored.
• Comments do not save a bad code.
• Try to explain what the code causes to happen.
• Comments can be useful when placed in certain places.

Error Handling

• Error handling should be planned carefully by all programmers.
• When wrong things occur, we have to get it to do the right things.
• We should give preference to launching an exception than treating it just to hide.
• Create messages with information about the error.
• Mention that it failed. Where was this failure? If possible, mention why it failed.
• Look at separate business rules for errors and error handling.
• Avoid returning a NULL in methods, preferably to return an empty object.
• Avoid passing NULL to the methods; this can generate NullPointerExceptions.

Unit Tests

• Make sure each piece of code is doing what you expect it to do.
• Use the F.I.R.S.T rule for testing:

1. The test is fast-running.
2. The tests are independent of others.
3. The test is repeatable in various environments.
4. The test is self-validating.
5. The test is timely.
6. The test is as important as the production code.

Conclusion

Clean code is not written following a set of rules that is a must. You do not become a software professional just by learning a list of what you do and what you’ve done.

Professionalism and craftsmanship come from values and discipline in lists of what you should and should not do when creating a code.