Clean Code Robert C. Martin
A Handbook of Agile Software CraftsmanshipMay 01, 2016 - 946 words - 5 mins Found a typo? Edit me
Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.
Chapter 1: What Is Clean Code?
- The code can be measured with either “good” or “bad” in the code review or by how many minutes it takes you to talk about it.
- A clean code should be elegant, efficient, readable, simple, without duplications, and well-written.
- You should add value to the business with your code.
- Clean code offers quality and understanding when we open the source file.
- It is necessary that your code is clean and readable for anyone to find and easily understand. Avoid wasting others’ time.
Chapter 2: 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.
- Use names that reflect the system domain, the context, and the problems that must be solved.
Chapter 3: Functions
- Methods should be easy to read and understand.
- Methods should convey its intention.
- Methods should be small.
- They must have up to 20 lines.
- Methods should only do one thing.
- 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 justification.
Booleantype as a parameter already states that it does more than one thing.
- Avoid duplication.
Chapter 4: Comments
- One of the common reasons for 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 happening.
- Comments can be useful when placed in certain places.
- Don’t explain your code with comments. Use informative vars/method names.
- Comments can be used to express the importance of certain points.
- Do not write comments with redundant, useless, or false information.
- They shouldn’t be used to indicate who changed or why, use versioning.
- Don’t comment code that will not be used. Remove it instead.
Chapter 5: 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 the changes that will be made.
- Smaller classes are easier to understand.
- Set a limit of characters per line of code. For example 120.
- Try to keep more next related concepts vertically to create a code stream.
- Use spaces between operators, parameters, and commas.
Chapter 6: Objects and Data Structure
- Follow the Law of Demeter:
- Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.
- Each unit should only talk to its friends; don’t talk to strangers.
- Only talk to your immediate friends.
- Do not make dumb objects.
- Objects hide the data abstraction and expose methods that operate the data.
- Data structures expose your data and do not have significant methods.
Chapter 7: 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.
- 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
NULLin methods, preferably to return an empty object.
- Avoid passing
NULLto the methods; this can generate
Chapter 8: Boundary
- In third-party code, to avoid passing objects, APIs look forward in order to keep things in the same class.
- Perform tests on the API’s third party.
- Study the documentation and test the third API before you start using it.
- Check well the features you will use.
Chapter 9: Unit Tests
- Make sure each piece of code is doing what you expect it to do.
- Follow the TDDs law:
- Don’t create code before you have a failing test.
- Don’t create more tests than necessary to fail.
- You cannot write more code than enough to pass the test that is failing.
- Keep your test clean.
- The tests must undergo changes in the same way that the code.
- The dirtier the code, the more difficult test will be to maintain.
- Use the F.I.R.S.T rule for testing:
- The test is fast-running.
- The tests are independent of others.
- The test is repeatable in various environments.
- The test is self-validating.
- The test is timely.
- The test is as important as the production code.
Chapter 10: Classes
- By default, classes should start with the variables:
- Static and constants public.
- Static and variable private.
- Instances and variables privates.
- Soon after comes the functions.
- The class name should represent its responsibility.
- The class must have only one responsibility: one reason to change.
- You should try to make a brief description of the class.
- The methods should be small and one responsibility.
This interview is based on Uncle Bob’s book “Clean Code”. They cover some existing guides that can help you become a better programmer and explore how books and current trends are shaping the software landscape.