Introduction
This article demonstrates simple code writing or code review tips. As a developer, whatever code we write it should be easy to write and more importantly it should be easy to read, maintain and understand. Writing clean code not only makes the developer’s job easier, it also improves the quality of life for everyone in the development team. In this article, we will see how the dirty code can be improvised to make the code more clear and easy to understand and maintain.
Naming matters
Variable Name selection has a huge impact on the readability of our code. The code snippet should be simple enough that one can determine what it does. Without well-chosen variable names it's completely unclear if the code does what the author intended.
Let's compare reading them like a sentence in a book.
Dirty Code: Loop through a list P, add each P to T, and return.
Dirty Code: Loop through list of prices, add each price to total, and return.
Boolean Comparison
Booleans are a simple concept that many developers don't leverage in the cleanest way. Booleans are an obvious choice when there's a true/false decision to handle. However, it's common for programmers to explicitly compare Booleans against true and false as you see here. This is totally unnecessary and it actually just adds noise to the Conditional in most cases.
Dirty Code
After Code Review
Boolean Assignments
One of our primary goals when writing clean code is to increase the signal to noise. To increase the signal to noise a Boolean should be assigned implicitly as well. There’s a number of clear advantages to this more implicit style of assignment.
-
Number of lines of code
-
In the Dirty example the variable must be initialized separately from its use within the if and else below. This is not the case with clean code.
-
There's also a greater risk for mistakes since the variable must be repeated on three separate lines in the Dirty version.
Dirty Code
Dirty Code
After Code Review
Positive Conditionals
Writing negative conditionals increases the cognitive load and reduces readability.
Dirty Code
After Code Review
Ternary Elegance
Looking at the code below, it seems this is a pretty, clean and easy to read example.
Dirty Code
But, there's still clear room for improvement because the signal to noise can be significantly increased by utilizing the Ternary operator instead. This approach has many of the same benefits as the implicit Boolean assignment that we just discussed.
After Code Review
So the bottom line is, the beauty of the Ternary operator and the implicit Boolean assignment that we just reviewed, is they both honor the Don't Repeat Yourself (DRY) Principle. See, the nice thing is you don't need to repeat the variable that you're setting.
Stringly Typed
In a strongly typed language such as C#, VB.NET or it offers the luxury of compiler safety. If you miss-type a reference then the application will not compile. However, that does not keep developers from using the wrong tool for Conditional logic. Strings are a handy, but using a string in this way is not one of them.
Instead, one can leverage an Enum to make a strongly typed check for the employee type. There is a variety of benefits to this approach.
-
Strongly typed means that there's no way to make a typo.
-
IntelliSense support when you stay strongly typed.
-
It’s Searchable.
After Code Review
![]()
Magic Numbers
Look at the following code. It doesn't convey much information. We're just checking if age is over 21 and less than 58. Now, the problem is we have no idea why 21 or 58 is significant. To figure this out we'd need to read between the lines and by reading the function in hopes of determining exactly why the developer typed 21 or 58 here and not some other number.
Dirty Code
Instead, consider setting a well named Constant for use in Conditionals. As you can see the meaning of the number 21 or 58 is now crystal clear. The biggest benefit to removing the magic number is it clarifies intent.
Complex Conditionals
Many conditionals get out of hand. They tend to grow over time until they are hard to work with and are unclear.
Dirty Code
Before our conditionals grow out of control there is the approach to manage the complexity and clarify intent so that they don't end up confusing messes like Encapsulation via functions. Finally, notice that the return line now clearly describes our intent and reads like a spoken word.
After Code Review
![]()
Polymorphism vs Enums
As we saw earlier Enums and Constants are useful for Conditional logic. However, when logic switching is being used to provide a notably different behavior, resorting to switch statements and Enums can lead to redundant switch statements and the code is hard to read. Instead Polymorphism can often provide a more scalable solution. This is particularly true when you notice a switch statement that occurs more than once in your code.
So, let's have a look at the three specific derived classes that can be called a polymorphic ally to eliminate switching logic. With this structure each class knows how to handle itself so the switch is no longer necessary in multiple places in our code and the logic for each user type is completely encapsulated within these specific classes.
After Code Review
![]()
![]()
Summary
In this article, we saw that setting and maintaining coding standards will help keep our code clean and watching for broken windows during these code reviews will help assure that the quality of our application continues to be respected. Finally, when editing existing code, strive to leave it a little better than you found it. If we consistently do so then we're far less likely to have to rewrite an application later.