What is Bad Code? How to Write Clean Code?

We do programming to solve problems. Unaware of the mind, We often write bad code to get things done faster. And when the changes come, that time we realize how bad our code is. As a human being, just as you have to sleep every day, a programmer must accept that the client's requirements must changes. There are many programmers who are upset when a client’s requirements are changed and cannot easily accept the change. The reason programmers are upset that they wrote bad code past in that project.

In order to write good code, we need to know which is bad code. I’ve created a definition of bad code. The definition is:

A bad code is when a programmer or coder do program to get things done faster without thinking much about future changes and ignoring the possibility of other developers touching the code.

First, we need to know what a bad code really is? I’m giving you some possible reasons for the bad/poor code

• Hard to read and understand: The first characteristic of bad code is that nobody else understands it fast. That means when a developer try to update your code he/she need to put extra time for understanding your code. And finally, if he understands your code he will have trouble adding any new ones. Many times new developers lose jobs because they do not understand the old code. Many times developers leave their jobs because of the existing messy or bad code.
• It contains many levels of nested blocks like if-else statements, loops: Developers often use nested blocks like if-else statements, loops to get the desired result quickly. And when the program successfully compiled, developers forgot to optimize the program.
• Poorly named methods and variables: To save time, we often use the variable /method name lIke X, Y, Z or ABC. That is very bad. When you do programming, you might remember what this XYZ works for. But after a few days when you are going to update this same code again or someone else updates your code, No One can understand the meaning of the variable/method name.
• Unnecessary code comments: Adding many redundant comments trains the reader to skip over every comment, so when there is a comment that is important it will likely not be read.
• Some other reasons:

1. There are very less or no logical separations and everything is written in a single method.
2. The classes are highly coupled and even a small change in the code may require changing many other parts of the system.

Programmers write Bad Code due to many reasons but the most commons are:

1. Meeting the deadlines in a fast-paced project.
2. Unawareness about code quality and best coding practices.
3. Carelessness, i.e. taking shortcuts, not thinking much about future changes.

If you want to avoid bad code and write clean code, you must read Robert C Martin’s Clean Code. According to his book…

Code is clean if it can be understood easily — by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

Here is the summary of Clean Codes. If you follow the rules, Your code will be clean and understandable.

General rules

1. Follow standard conventions.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy scout rule. Leave the campground cleaner than you found it.
4. Always find the root cause. Always look for the root cause of a problem.

Design rules

1. Keep configurable data at high levels.
2. Prefer polymorphism to if/else or switch/case.
3. Separate multi-threading code.
4. Prevent over-configurability.
5. Use dependency injection.
6. Follow the Law of Demeter. A class should know only its direct dependencies.

Understandability tips

1. Be consistent. If you do something a certain way, do all similar things in the same way.
2. Use explanatory variables.
3. Encapsulate boundary conditions. Boundary conditions are hard to keep track of. Put the processing for them in one place.
4. Prefer dedicated value objects to a primitive types.
5. Avoid logical dependency. Don’t write methods that work correctly depending on something else in the same class.
6. Avoid negative conditionals.

Names rules

1. Choose descriptive and unambiguous names.
2. Make a meaningful distinction.
3. Use pronounceable names.
4. Use searchable names.
5. Replace magic numbers with named constants.
6. Avoid encodings. Don’t append prefixes or type information.

Functions rules

1. Small.
2. Do one thing.
3. Use descriptive names.
4. Prefer fewer arguments.
5. Have no side effects.
6. Don’t use flag arguments. Split method into several independent methods that can be called from the client without the flag.

Comments rules

1. Always try to explain yourself in code.
2. Don’t be redundant.
3. Don’t add obvious noise.
4. Don’t use closing brace comments.
5. Don’t comment out code. Just remove.
6. Use as explanation of intent.
7. Use as clarification of code.
8. Use as warning of consequences.

Source code structure

1. Separate concepts vertically.
2. Related code should appear vertically dense.
3. Declare variables close to their usage.
4. Dependent functions should be close.
5. Similar functions should be close.
6. Place functions in the downward direction.
7. Keep lines short.
8. Don’t use horizontal alignment.
9. Use white space to associate related things and disassociate weakly related.
10. Don’t break indentation.

Objects and data structures

1. Hide internal structure.
2. Prefer data structures.
3. Avoid hybrids structures (half object and half data).
4. Should be small.
5. Do one thing.
6. Small number of instance variables.
7. Base class should know nothing about their derivatives.
8. Better to have many functions than to pass some code into a function to select a behavior.
9. Prefer non-static methods to static methods.

Tests

1. One assert per test.
2. Readable.
3. Fast.
4. Independent.
5. Repeatable.

Code smells

1. Rigidity. The software is difficult to change. A small change causes a cascade of subsequent changes.
2. Fragility. The software breaks in many places due to a single change.
3. Immobility. You cannot reuse parts of the code in other projects because of involved risks and high effort.
4. Needless Complexity.
5. Needless Repetition.
6. Opacity. The code is hard to understand.

Buy Clean Code: https://amzn.to/3cfeCoQ

📝 Read this story later in Journal.

👩‍💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.