What is clean coding?
Clean coding refers to writing codes in a systematic format that is clear and easy to understand by other coders or developers. Clean coding is a subjective phenomenon, and developers have different opinions about the same. Although they follow some ideas and best practices that constitute a clean code, at the same time, there are no hard fast rules around the same.
Each developer has their own writing style, methods, and structures they follow. But, it's better if they stick to basic or industry standards, accepting the fact that they are writing and structuring these codes for the company, not for their personal use. The next person or another team member who might need to work around the code should not take up too long or revamp the entire project as it might be costlier for the company. Hence, developers & coders must abide by the basic principles of clean coding and industry standards.
“Clean code is not written by following a set of rules. You don’t become a software craftsman by learning a list of heuristics. Professionalism and craftsmanship come from values that drive disciplines. & Clean Code always looks like it was written by someone who cares.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
Robert C. Martin constantly emphasizes the fact that codes need to be written in a format that is easy to read and change. This means the person who's writing the codes needs to focus on writing them with clarity and reduce the possibility of misunderstandings. The flow and consistency must be followed throughout the project, and it should be written with known methods that could easily be accessed by another person in case of changes and debugging, etc...
What are the basic clean coding principles?
The clean code principles don't talk or include programming languages into the picture or don't create a complex between choosing the programming language. These principles are the most basic ground rules that one needs to keep back of the mind while writing codes and programs. There’s another set of principles which are called s SOLID principles a bit different and more technical than the basic principles.
1. DRY (Don’t repeat yourself)
This principle highlights the importance of uniqueness, unambiguity, and using a single representation of codes within a system. This means that codes should not be written twice or used repetitively without a unique identification or attribution. Violation DRY principle is referred to as WET: We Enjoy Typing, Write Everything Twice, Waste Everyone's Time.
2. KISS (Keep It Simple Stupid)
The focus here is to write codes that are simpler and non-complex. Designers or developers should not use codes that are unnecessarily complex or hard to understand or take time to comprehend by the second person. This simplicity can be achieved by answering a simple question, "how do we write it simpler?".
3. YAGNI (You Aren't Gonna Need It)
YAGNI is part of the Extreme Programming (XP) methodology, focused to improve software quality and increase responsiveness. The developer should not add functionality to the codes unless it necessary unless it's worth mentioning or required in that place. Adding functions to the codes beforehand can take away a lot of time and might turn out to be a waste if not used in the future.
4. Curley’s Law (Do one thing)
Curley’s law says that an entity like class, function, or variable should mean one thing in the entire doc. These things can not have two attributes or meaning throughout the programming of one project, though they can change with other projects depending on the need & requirement.
5. Boy-Scout Rule
To avoid technical debts due to prolonged and constant changing of code, they should make a system of changing the bad codes then and there. If someone finds or feels that code is not appropriate or has scope for betterment, the team should correct and fix the same at the time of detection.
How to "name" variables for clean coding? or How to write clean codes?
1. Use intention revealing names
The name of the variable, function, class should be sufficient to understand the entire code and the intent behind writing that code, without running through the entire code.
2. Avoid misinformation or faulty words
Avoid using words that mean something specific in general, and if misplaced can mean something else.
Example: A grocery list means that it’s a list of carrying grocery items. But, in this case, the code just denotes “Grocery” and not the list.
3. Avoid noise words
Avoid using noise words like Data, Value, Info, Variable, Table, String, Object, etc... are used as a suffix but generally don't add up to the bigger picture. This means these words are redundant and not should be avoided.
4. Use pronounceable names
Rather than putting up a random text and explaining it in the comment after the codes doesn’t make any sense. One should rather right these codes and attribute in a clear language that doesn’t need to be explained with additional text or comments.
5. Use searchable names
Use proper terms and opt for searchable, named constants instead of using random numbers or words. One should not add single-letter names for constants since they might appear at many places if we run a search.
Clean code architecture (Robert Cecil Martin / Uncle Bob)
This core layer consists of business logic and principle that remains intact throughout the code structure and differ from organization to organization. These logics could include language that coders use, the structure they follow, function attribution & naming of values, etc...
B. Use Cases/ Application:
This layer is all about the application-specific approach and business logic that programmers keep as the base orientation of the project.
This layer consists of software and programs which we use for converting and streamlining data in a suitable format.
D. Framework & Driver/Details:
Here comes the thing about clean coding, the rules described here would define the presentation of data & codes and choosing the principles, database, and the web framework of clean coding to make the project easier to change and comprehend.