Coding Crowd+ ✨ Clean ✨
What is a Clean Code?
First things first, here are some quotes from professionals regarding clean code.
Language I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.
- Bjarne Stroustrup, inventor of C++ and author of The C++ Programming
Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.
- Grady Booch, author of Object Oriented Analysis and Design with Applications
You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.
- Ward Cunningham, inventor of Wiki, inventor of Fit, coinventor of eXtreme Programming.
From the quotes above, it can be said that clean code is a code that can help coders during the whole development process. Even though there is no exact definition of clean code, clean coding is overall a set of efforts that can be maintained and pursued to achieve software craftsmanship.
So what is software craftsmanship?
Software craftmanship is about performing well by:
- working well, adding value, doing a good job;
- interacting, communicating, and collaborating with others;
- productively adapting and responding to change;
- having professionalism and ethics.
The Boy Scout Rules
Clean coding is based on “The Boy Scout Rules”, that is:
“Leave the campground cleaner than you found it.”
“Try and leave this world a little better than you found it . . .” — Robert Stephenson Smyth Baden-Powell’s farewell message to the Scouts
Therefore, it can be said that clean coding is a set of efforts to code in a professional way, improving the cleanliness of the code.
The characteristics of a clean code are as follows:
- Elegant, pleasing to read;
- Focused on each function, class, and module to expose single-focused purposes and avoid distracting details that are irrelevant;
- Needs time to maintain and keep it simple and orderly;
- Runs all the tests;
- Contains no duplication;
- Minimizes the number of entities such as classes, methods, functions, and the like.
Implementing Clean Code in Crowd+
In Software, we have different motivations. The different motivations yield different mental thinking and different activities with different points of view. Here are some of the tips from uncle Bob’s book.
Meaningful Names
Meaningful names of variables and constants help developers to understand the use of those variables and constants easier.
For example,
int d; // elapsed time in days can be improved to a more meaningful name such as
int elapsedTimeInDays;Function
Functions are the first line of organization in any program. Therefore, the way functions are created should also be considered by developers, as it can also affect the readability of the entire code.
A function should:
- Be small! Try to create a function as small as possible, to improve the readability of the function.
- Only do one thing. Functions should only do one thing well.
- Be descriptive. This also puts an effect on the readability of the code, as a descriptive function helps other developers understand the purpose of the function easily.
- Have the least side effects possible. This means creating a pure function; a function that does not have any impact on mutable and shared data. Creating a pure function helps to test the correctness of the function, as the result of the function would always be predictable.
- Implement the Command Query Separation pattern. This means a function should either be a command that performs an action, or a query that returns data to the caller, but not both.
Comments
“Don’t comment bad code — rewrite it.”
- Brian W. Kernighan and P.J. Plaugher
When can we write Comments?
- Legal Comments
- Informative Comments
- Explanation of Intent Clarification
- Warning of Consequences TODO Comments Amplification
Bad comments are comments that are:
- Mumbling,
- Redundant,
- Misleading,
- Mandated,
- Journal,
- Noisy,
- Scary.
Prevent the use of Commented-Out Code
Others who see that commented-out code won’t have the courage to delete it. They’ll think it is there for a reason and is too important to delete. So commented-out code gathers like dregs at the bottom of a bad bottle of wine.
Objects and Data Structures
In both of the above cases the second option is preferable. We do not want to expose the details of our data. Rather we want to express our data in abstract terms. This is not merely accomplished by using interfaces and/or getters and setters. Serious thought needs to be put into the best way to represent the data that an object contains. The worst option is to blithely add getters and setters.
Error Handling
- Use Exceptions Rather Than Return Codes
- Write Your Try-Catch-Finally Statement First
- Use Unchecked Exceptions
- Provide Context with Exceptions
- Define Exception Classes in Terms of a Caller’s Needs
- Define the Normal Flow
- Don’t Return Null. Don’t Pass Null.
Consider Listing 7–2 compared to Listing 7–1, it is much cleaner. Regarding the two concerns that were previously tangled, the algorithm for device shutdown and error handling, are now separated. You can look at each of those concerns and understand them independently.
