How Can Clean Code Help Us?

Code is clean if everyone on the team can easily understand it. A worker who is not the code’s author can read and improve clean code. It is easier to learn, change, add to, and maintain something that is easy to understand.

Rules for everyone for clean code

1. Do what everyone else does.
2. Don’t make things too hard. Always keep things simple. As much as possible, make things simpler.
3. Follow the boy scout rule. Clean up the site after you use it.
4. Always look for the cause. Always try to figure out why something is going wrong.

Rules for design

1. Keep info that can be changed at a high level.
2. Polymorphism is better than if/else or switch/case.
3. Keep multithreading code separate.
4. Don’t make it too easy to configure.
5. Put in place dependency injection.
6. Stick to the Law of Demeter. It is best for a class to only know about its direct relations.

Tips for Understanding

1. Always be the same. Just because you do one thing one way, do everything else the same way.
2. Use factors that explain things.
3. Wrap up the border conditions. Conditions at the boundaries are hard to keep track of. Do all of the work for them in one place.
4. Dedicated value objects are better than basic types.
5. Do not count on logic. Don’t write methods that only work if something else in the same class is also true.
6. Don’t use negative conditionals.

Rules for names

1. Pick names that are clear and describe what they are.
2. Make a difference that matters.
3. Use names that are easy to say.
4. Use names that can be searched.
5. Use named values instead of magic numbers.
6. Don’t use encodings. Don’t type information or add prefixes.

Rules for functions

1. Small.
2. Do one thing.
3. Names should be clear.
4. Would like fewer fights.
5. Do not cause any harm.
6. Don’t come up with flag reasoning. You can split a method into several separate ones that can be called from the client without the flag.

Rules for comments

1. Always use code to describe yourself.
2. Do not repeat yourself.
3. Don’t add noise that we can see.
4. Do not use comments with ending braces.
5. Do not leave comments in code. Just take it off.
6. Use to explain your purpose.
7. Use to make the code clear.
8. Use as a warning of what will happen.

Structure of source code

1. Put ideas in different columns. Linked code should look like it’s packed together vertically.
2. Declare variables close to where they will be used.
3. Functions that depend on each other should be close to each other.
4. Functions that do the same thing should be close to each other.
5. Place the parts so that they go down.
6. Make your words short.
7. Don’t arrange things horizontally.
8. Use empty space to connect things that are related and separate things that are only lightly related.
9. Do not break the line breaks.

Data patterns and objects

1. Cover up the structure inside.
2. Pick data structures over lists.
3. Stay away from structures that are half object and half data.
4. It needs to be small.
5. Do one thing.
6. There are not many instance variables.
7. The base class shouldn’t know anything about the class that comes from it.
8. It’s better to have a lot of functions than to feed code into one to choose an action.
9. Use non-static ways instead of static ones.

Tests

1. One claim per test.
2. Easy to read.
   Speedy.
3. On their own.
4. Doable again.

Code smells bad

1. Being stiff. It’s hard to change the program. A small change sets off a chain of changes that happen all at once.
2. Being weak. One change makes the software not work right in many places.
3. Being stuck. Because there are risks and a lot of work involved, you can’t use parts of the code in other projects.
4. Too much complexity.
5. Repeating yourself too much.
6. Lack of visibility. It’s hard to understand the code.