Allright, so you’ve written some code. Now how do you determine that it’s good code? What’s your approach in evaluating the quality of your code? Do you follow some Software Design Principles? Are you aware of some of the Code Smells? Whenever I write some code, I always ask myself questions about the code I’ve just written. Asking yourself the right questions will help you find the right answers. In this post I will share 3 important questions I always ask myself to help me evaluating the quality of my code.

1. does this class have just one responsibility?

• Description: If your class has more than one responsibility, then responsibilities can become coupled. If responsibilities are coupled, changes to one responsibility may affect the other responsibility. This can lead to fragile design, more complex UnitTests and your code may break in unexpected ways, especially if different clients depend on this class for different reasons or responsibilities. Also, the more responsibilities your class has, the harder it becomes to comprehend your class.
• Possible indications: Lots of import declarations, long classes, long methods, one client depends on this class for one reason and another client depends on this class for another reason.
• Possible solutions: Extract a class that has its own responsibility and delegate from the original class to the extracted class.
• What do you achieve: Simpler class design, testability and robustness improves.

2. is this method side-effects free?

• Description: If your method has side-effects, it does more than its intended purpose. For example it also changes the state by modifying a global or static variable. Or for example, it validates some data and updates the database as well. Methods with side effects make the behavior more difficult to predict, are more difficult to test and are harder to comprehend.
• Possible indications: long methods, it’s hard to write UnitTests for this method, arguments are assigned inside the method body, static or global variables are modified.
• Possible solutions: break method into smaller methods, find alternatives for argument assignments
• What do you achieve: Simpler methods, easier to create UnitTests, possible indications for different responsibilities, more readable code, robustness improves

3. is my code readable for someone unfamiliar with this code?

• Description: If your code is unreadable, it takes more time to understand your code. It is also harder to change your code and it can be risky to change your code, because you may not be sure if your change is correct. Most of your colleagues will probably become frustrated if your code is unreadable, and changing your code takes longer than neccesary.
• Possible indications: long methods, long classes, magical numbers (numbers you don’t know what they stand for), use of uncommon abbreviations, it doesn’t look nice
• Possible solutions: rename methods and variables to something that is understandable, declare variables as close to where they are first used as possible, make it look nice (consistent and correct spacing, indentiation, white lines, etc.), introduce constants for magical numbers, use consistent naming
• What do you achieve: simpler code that’s easy to understand, easy to change, and changing your code takes less time. Also your colleagues won’t be frustrated

These are 3 of the many important questions I ask myself when writing code. They help me evaluating the quality of my work, and thus assist me improving the code I’m working on when necessary. You will notice that when you ask yourself these kind of questions a lot, it becomes a second nature to think about important principles and guidelines.

Popularity: 387 points