A long time ago I used this summary of some key points that I made to study about the book clean code. I hope it helps others.
This summary doesn't exclude the need to read the book Clean Code.
What is Clean Code?
The code can be measured with good or bad in the code review from how many WTF / or how many minutes you talk.
A clean code should be elegant, efficient, readable, simple, without duplications, well written, should be written carefully and must always have a responsibility.
You should add value to the business.
Clean code offers quality and understanding when we open a class.
It is necessary that your code is clean and readable for anyone to find it, can easily understand it avoiding waste of time and facilitating the work of all.
Meaningful Names:
Names of the classes, variables, methods, must be meaningful, clearly indicating that a method does or what an attribute is.
Should create pronounceable names to facilitate communication.
We should avoid acronyms.
Avoid confusing names, which can take anyone who reads the code to wrong conclusions.
Use names that reflect the system domain, the context and the problems that must be solved.
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.
They must have up to 20 lines. (I think should have up to 10 lines)
Methods should only do one thing, they should do it the right way and just do it.
You should use names with words that can say what he really does.
The optimal number of parameters of a method is zero, after one and two.
Three should be avoided, but if it should 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 returns something.
Avoid duplication.
Comments:
One of the most common reasons for the comments is because the code is bad.
When thinking about writing a comment it is because the code should be refactored.
Comments do not save a bad code.
Try to explain what the code causes the code.
Comments can be useful when placed in certain places.
Create method names and informative variables instead of explaining the code with comments.
Use a comments can be used to express the importance of certain points in the code.
The best comment is one that needs to be written, because your code already explained.
Do not write comments redundant, useless or false information.
It should not be used to indicate who changed or why, for that already exist versioning.
Don’t comment code that will not be used, remove, it just pollutes the code and leaves no doubt in anyone reading.
Formatting:
It should give importance formatting 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.
Try to write 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.
Objects and Data Structure:
Follow the Law of Demeter:
One 'M' method of an object 'O' can only consume services of the following types of objects:
- The object itself 'O;
- The 'M' parameters;
- Any object created / instantiated 'M';
- Direct Components 'O'.
Make good abstraction and encapsulation.
Do not make dumb objects.
Objects hide the data abstraction and exposes methods that operate the data.
Data structure, exposes your data and do not have significant methods
Error Handling:
Error handling should be planned carefully by all programmers.
When happen wrong things we have to get him to do the right things
Should give preference to launch an exception than treat it just to hide.
Create message of some kind of information.
Mention it failed where was this failure, if possible why it failed.
Look separate business rules for errors or error handling.
Avoid returning a NULL in methods, preferably to return an empty object.
Avoid passing null to the methods, it can generate NullPointerExceptions.
Boundary:
In third-party code to avoid passing objects API’s looking forward to keep it in the same class.
Performs tests on API's Third Party
Study the documentation and well test the third API before you start using it.
Check well the features you will use
These step can help increase yield when there are new updates API and you can only run your tests to check for this update
Create tests the functionality of the API.
Unit Tests:
Make sure each piece of code is doing what you expect it to do.
Follow the TDD’s law:
- Not Create code before you have a failing test.
- Shouldn’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 more difficult test will be, to give maintenance.
Look create an assert for testing
Use the F.I.R.S.T rule for testing:
- The test is FAST running
- The test should be INDEPENDENT of other
- REPEATABLE in various environments
- SELF- VALIDATING
- TIMELY
The test is as important as the production code.
Classes:
By default java classes should start with the variables:
- Static and constant public
- Static and variable private
- Instances and variables privates
- Soon after come the functions
The class name should represent your responsibility
The class must have only one responsibility
To know the size of the class is ideal or we should not measure her responsibility
You should try to make a brief description of the class
The methods should be:
- Small
- And even lower
- They must have only one responsibility
Systems:
It is important to recognize and separate responsibilities of a system.
It should be separate and modularize the logic execution, allowing an independent strategy for solving application dependency
Is an element important to take care of dependency injection allowing objects only take care of the business of logic.
It is very difficult to create a system properly first, must be made available to the story, then refactor it and the expand system to continue implementing new stories.
To get to that point is necessary TDD, refactoring and clean code.
We must build POJOs-based logic through testing and evolve from simple to interconnect the various aspects necessary.
Emergence:
Rules given by Kent Beck to create good designs:
- Run all tests: they verify that the system behaves as expected.
- Eliminate duplication: for with duplicate code has additional work.
- To express the intention of the programmer: use more expressive code can to Facilitate maintenance. Choose good names for functions, classes and tests shouldn’t be small and well written.
- Minimize the number of classes and methods: following this pattern can ignore it if the classes are very small.
- Apply all knowledge to improve the design during refactoring: greater cohesion, reducing coupling, separate responsibilities, reducing classes and methods, choose the best names.
Even applying it once you will not be able to have good software you need to do this for over and over again, to achieve continuous improvement.
Concurrence:
The concurrency is an aspect that may be present in the codes.
For uncoupling allows improving the yield and structure of an application.
The concurrency can improve response times and application efficiency.
You should consider the following ideas about the concurrence:
- It injects a certain overload.
- It can be complex to operate.
- Errors caused by it can be difficult to reproduce
- Usually requires design changes.
The concurrence problem is that different segments of an application may be following tangled multi-threading, which can cause unexpected problems in normal situations.
For concurrence reasons it is important that each class has a unique responsibility.
Create Sections synchronized minimized. Run tests are often the best way to find any errors in the code.
However, it is difficult to do when there are concurrence tests
A good way to test is to insert codes for testing in the middle of the implemented code.
Successive Refinement:
The code only work is not enough to have a good code.
Professionals who care only about the code that works cannot be considered professional.
We can not consider that we have no time to refactor to one code, since this code that was not taken care of today can become a problem after becoming a problem for the team, because no one will want to mess with it.
Try not to let the rot code, it is much cheaper to create a clean code than cleaning a rotten code as move in a tangle can be an arduous task.
The solution then comes down to maintain the cleanest code possible and as simple as possible without ever leaving the rot started.
JUnit:
Look to cover tests each not every method but each code line.
No code is immune improvement, and each of us has a responsibility to make the code a little better than we found it.
Refactoring is an iterative process full of trial and error inevitably converging to something that we feel is worthy of a professional.
Refactoring:
Before making any kind of refactoring is important to have good coverage tests.
After increase or create test coverage can begin to leave the clearest code and fix some bugs.
Now after leaving the code clearer probably someone else can clean even more.
Smells and Heuristics:
What you should not do about comments:
- Inappropriate information
- Obsolete Comment
- Redundant Comment
- Review misspelled
- Commented Code
Environment:
- Build requires more than one step
- Tests require more than one step
Functions/Methods:
- Many arguments
- Flags with Boolean
- Methods unused
General
- Multiple Languages to a file.
- Overridden Insurance
- Code Duplication
- Code on the wrong level of abstraction
- Class basis depending on derivatives
- Lots of information in a method
- Dead Code (Unused)
- Vertical Separation
- Inconsistency
- Disorder
- Responsibility BLEND
- Static inappropriate
- Use explanatory variables
- Function names should say what they do
- Understand the Algorithm
- Make logical dependencies
- Make Polymorphism to instead of If / Else or Switch / Case
- Follow standard conventions
- Be precise
- Encapsulating conditionals
- Avoid negative conditionals
- Functions should do something
- Functions should come down only one level of abstraction
- Maintain configurable data at high levels
Java
- Avoid long lists of import using *
- Not Inherit Constants
- Prefer to instead of Enums Constants
Names
- Choose descriptive names
- Choose names at the appropriate level of abstraction
- Use standard nomenclature where possible
- Clear names
- Use long names for long Scopes
- Avoid encodings
- Names should describe side effects
Tests
- Lack of testing
- Use a cover tool!
- Make Trivial tests
- A test is ignored a question about an ambiguity
- Test coverage patterns can be revealing
- Tests should be fast
Clean Code is not written following a set of rules.
You do not become a software professional learning just a list of what you do and what n is done.
Professionalism and craftsmanship comes from values and discipline in lists of what you should and should not do when creating a code.
