Coding Crowd+ ✨ Clean ✨

What is a Clean Code?

First things first, here are some quotes from professionals regarding clean code.

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;


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.


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.




Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Amrisandha Prasetyo

Computer science student at Universitas Indonesia | Aspiring product designer 🎨💻