Clean Code – Part 1

#csharp #beginners #productivity #webdev

Clean code is akin to keeping your home/workspace tidy. Cleaning requires effort, whereas leaving garbage doesn’t.

While I’d love to mention some examples of poor code I’ve seen over the years, I too have fallen foul in the past.

Clean code isn't about vanity! Large messy un-refactored code only adds to technical debt. When another developer works with the same code you’ll have to double the time for them to complete the task due to messy code. Bear in mind time and effort can quickly grow exponentially as each developer hacks and contributes to the same messy code.

Below are suggestions to help keep our code clean.

Move hard-coded values to the database

Instead of this…

do this...

It’s very easy to write constants such as tax rates and bool switches directly into your code without thinking about the long term repercussions. I’m referring to changing values.

In cases like these it is far better to move these values into a database table, or at the very least the application configuration file. This way it will be much quicker and safer to make changes as opposed to opening up the code many years later and making changes, compiling and then praying its works while you upload… you get the idea.

Guard Clauses

Guard clauses follow the fail-fast principle. In the example above I’m performing a null check on the injected IEmailService reference supplied to the constructor (assume I’m using DI). If the reference is null, a related exception will be thrown during runtime.

Dealing with null references is an act of life for any developer. Using guard clauses throughout your code promotes error checking and is a good habit to develop.

Eagle eyed developers may have noticed I’ve compacted an IF statement to one line. You don’t have to do this, but I find it creates less noise and is more succinct.

Choosing appropriate class names

Poor class names…

Class names typically work best when they are nouns. However in more complex scenarios as shown above it is easy to fall foul of this when you need to describe two related classes.

Here’s one solution to fix this:

This is much cleaner and concise. I’ve used inheritance by creating a base class of Customer and then deriving two subclasses from it. In this instance, it allows for shorter class names since there is some context through the inheritance.

As a final note, I’m not a fan of using inheritance-based models everywhere throughout a solution unless there is a valid case as illustrated above. It can add to unnecessary complexity.

Thanks for reading! 🙂

Part 2 is available here:

Article No Longer Available

Top comments (6)

Rose • Aug 24 '20

Great Article!
I've been using the guard clauses a lot in my recent framework.
While mine might look a bit more hacky, it does the same as your code snippet:

public OrderService(IEmailService emailService) {
    _ = emailService ?? throw new ArgumentNullException(nameof(emailService));

    // do rest of code here
}

I've been using that line throughout my code base, just to reduce internal screams. xD

Ken Domino • Aug 24 '20

Writing code is very much like cooking: you're going to make a mess along the way, e.g., using too many mixing bowls, pots, and spoons, spilling food, and having a few food-burning accidents. A good cook knows he's made a mess and will clean up sooner or later. But, just remember: it's not a crime to take a little time to clean up the mess. And, what the cook calls it "clean", the next may say it is "a pigsty." There are a lot of tools out there to help with the clean up. Use them.

Michel Renaud • Aug 24 '20

For values subject to change, we've used databases in the past. This way, authorized users could change them without our involvement. The tables were "insert only", with the date and username of insertion. This allowed us to, for example, run reports with the value (e.g., tax rate) at a given date if we needed to (as opposed to the current value). Call it time travel.

Stuff like DaysInTheWeek would be a constant in the code. It makes for more readable code as opposed to an hardcoded value.