#technology

The Six Principles of Clean Code.

First off, let’s just clear this up: clean code does not mean working code. Good? Let’s get into it.

Let's show you a very common situation in the life of a programmer:

  1. Spend 3 hours writing 900 lines of code.
  2. Come back the next day to check code.
  3. Spend 3 days trying to figure out what I was thinking.

Think of it like not being able to read your own handwriting, but for a novel.

Clean code prevents this all-too-common problem.

It makes the initial writing a lot slower but saves you countless days later on. In short, clean code is:

  • Readable
  • Well structured
  • Easy to maintain
  • Testable
  • Elegant

It’s awfully hubristic to think that code only needs to be written once. This is an impossibility. Accept this, and you’ll do great things. After all the bug fixes, business changes, and tweaks, the tech world is ever expanding and you’ll need to add new functionalities all the time.

On top of that, innovating feature after feature to impress the end user and stay 10 steps ahead of your competitors. Those are only a few reasons you need to care about clean code. There are thousands of reasons, but we’re saving the two most important for last.

How to Escape the Loop of Doom.

As obvious as it sounds to invest that time early, clean code is surprisingly rare. Whether it be ignorance, hubris, deadlines, or even job security (haha) there are a million reasons it never happens. You’re constantly squeezed to deliver those bug fixes, tweaks, and new features. Then you find yourself back again in the Loop of Doom.

  1. The client has new feedback/request
  2. Come back to check code
  3. Spend 3 days trying to figure out what I was thinking when I wrote it so recently
  4. Figure it out
  5. Spend 3 hours writing 900 lines of code
  6. Fix bug/add featurs
  7. Submit to client
  8. The client has new feedback/request

The Loop of Doom makes everyone a liar. Seriously. The biggest lie in the world is:

“I’ll clean it up later.”

Later never comes.

Do it right the first time, because hours add up to days. Legends say career coders could even waste years trying to remember what the hell they were thinking. It’s the stuff of nightmares. Stop thinking about yesterday, and start thinking in terms of the lifespan of the application.

Rule of Thumb: Imagine that every developer who comes after you has your home address. And a battle axe.

Hell hath no fury like unreadable code. These guys live in the Loop of Doom after all. Now you know what clean code is, why it matters, and the rule of thumb to make sure your squeaky clean code is up to standard.

Resistance is Futile.

Your code could even be an advertisement for Tide. Don’t let that sense of security settle though, because we’re descending right back into the chaos of programming. I hope you brought a change of clothes, because your eyes are about to piss tears.

What is wrong with coding being readable, maintainable, testable, and elegant?

All of these qualities are subjective.

Cue the sounds of bodies hitting the floor. It becomes infinitely more complex when you’re working with multiple teams, multiple clients, and on occasion, across international borders. Please keep the screaming to a minimum. It’s up to your team to define readable, maintainable, testable, and elegant. Here are a few of our principles to help guide your treacherous journey:

1. The Dry Principle.

Don’t repeat yourself. This means no copy/pasta spaghetti code. It’s confusing, so stop it.

2. The Rose Principle.

Shakespeare was wrong. A rose by ANY other name is not sweet. Not sweet at all. And the developers will hunt you down. Set your standards *clearly *and early.

Save a Life, Name it Right:

Here’s an example:

  • theList- don’t you @#$#@** dare
  • Product List - still kinda hate you
  • ProductCatalog - you will live another day

ProTips for Pro-Programmers.

  • Use Nouns for Variables, Properties, Parameters- Indexer, CurrentUser, PriceFilter
  • Use Verbs for Methods and Functions- SaveOrder(), GetDiscounts(), RunPayroll()

Suicide Mission.

recdptrl

received patrol? record department role? Receding pterodactyl? Record Petrol?

The key is to be consistently pronounceable and unambiguous. Imagine if you needed your mom to find it and you had to give her instructions on the phone. If it sounds impossible, then your code needs a clean up.

3. The Standard Principle.

It doesn’t matter if it’s Camel Case, Pascal Case, or Lower Case. Have a standard and meet it consistently all the time.

4. The Lying Comments Principle.

It’s not terrible to assume comments always lie. Code is constantly updated, and moved around, but comments rarely follow.

Another way comments lie is that they can cover up bad code. I’ll say it louder for the people in the back: **comments do not make up for bad code. **If your comments are long, then you should probably just rewrite your code instead.

Not all comments are bad but use them properly. Most of all, keep it simple, stupid.

Good comments:

  • Canbeusedto describe intentorclarification- Ex: // *Sample *input: Oct 5, 2015 – 13:54:15PDT
  • Canbeusedtogivewarningsorconsequences- Ex: //*We do a deep copy of this collectionto make sure that updates to the copy do not effect the other.
  • CanbeusedforTo-Dos- Especially useful when the IDE supportsit
  • These should be temporary.

Bad Comments:

  • Avoid “journaling”comments- Ex: // 03/20/1996 – jjc – Added taxcalculation
  • This is what source control is for: Who, What, When
  • Avoid “noise”comments- Ex: // Default**constructor
  • Donotcommentoutcode- Codenolongerinuseshouldbedeleted
  • Ifneeded,youcanalwaysretrieve itfromsourcecontrol

5. The Tool Principle.

Know them. Really, know them. Their favorite ice cream flavors, what they like to do when it’s raining outside, all that good stuff. Keep methods short, they should always fit on a single screen and preferably no longer than 10 lines. Don’t be these guys:

Stack your methods:

  • High level: An overview of the functionality.
  • Mid-level: More details, but not too deep.
  • Detailed: The “weeds” of the functionality.

6. The Refactoring Principle.

This is another way to keep your code clean and elegant. Here are the two steps to do it:

  1. Bring your code under test.
  2. Safely and confidently refactor your code.

Clean code is a lot of work.

It’s constant vigilance and an uphill battle. But it’s well worth it. If you’re still not convinced, here are the two last and only reasons you need to always clean code:

  1. You are a programmer.
  2. You want to be a better programmer.

And you don’t need any more reasons than that.

Victor Mong

Victor Mong

Backend Engineer @ Mäd. Victor works behind-the-scenes, ensuring that all our technology is working smoothly and is highly performant.

Read More
The Six Principles of Clean Code.
Share this

Subscribe to Why #workwithmad