The Ten Commandments of Clean Code

Code should be clean.

If you’re the only person who will ever see your code, make it as hideous as you want. You’re only punishing yourself.

However, if you ever plan on sharing your code with someone else (e.g. your public GitHub when applying to a job, a project with a team, or a project of your own after an extended period of time) then you want your code to not suck. Just because it works doesn’t mean it doesn’t suck. Even “optimized” code can be bad.

These ten rules are not every rule ever, but they will help you become a much better team player and a much cleaner coder.

“Thou shalt not produce spaghetti code.”

1. D.R.Y. — Don’t repeat yourself

This is first because it’s a classic. Everyone should know it. Don’t repeat yourself. If you’re repeating code, you’re inherently being inefficient (and creating opportunity for bugs). Repetition means there’s an opportunity for abstraction, looping, recursion, etc.

2. Names should be self explanatory

Scenario: you’re creating a variable to hold the number of login attempts a user has made. What would be a good name? If you answered something along the lines of numLoginAttempts, you win! If you name your variables any variation of num, numLog, or (God help us) num1, try again.

Method names should be just as obvious, and ideally follow a verb + “thing it returns or does” pattern. That means opensNewPage should open a new page. A method called getRandomNumber should get a random number. Nothing more, nothing less. Not a random and mutate the original value within the method. Not pushing that random number into a pre-existing array. Just getting it.

3. Name as specifically as possible

You have a user model with a field “age.” Is that the user’s literal age? Their account age? A boolean to discriminate if the user is over 21? An acronym?? Name specificity avoids this kind of problem.

4. Use consistent conventions

Teams often have conventions for how they name their commits, variables, props, etc. Learn what they are, and keep them as best as you can across the ENTIRE codebase. Keeping conventions means you learn the codebase faster and identify problems more easily.