Can code be clean?

Answer: of course, it can!

~/$: clean_code --initiate_discussion

Hello everyone! I’m Guru Updesh Singh, and I’m back to share some insights on a topic that’s close to every developer’s heart, dreams, and greatest fears: clean code. After diving into articles on clean code principles and code smells and revisiting the first chapters from Robert Martin’s “Clean Code” and Martin Fowler’s “Refactoring,” I’ve got some thoughts and ideas to share.

~/$: code_smells --avoidance_tactics

Let’s start with something I really want to avoid making. Code smells. Have you ever been looking at some code when a funky odor wafts in? That smell is trying to tell you something’s off, even if it’s not outright broken. It can be hard to avoid, especially when you are writing lots of code and trying to get a task done. But my takeaway is that you should always try and avoid spaghetti code – the tangled, confusing mess that makes understanding and maintaining things a nightmare. We’ve all been there, unraveling someone’s 7-year-old code only to find a labyrinth of logic, constants, magic numbers, and weird edge cases. Lets just say an Italian restaurant is not a good place for a software developer — no offense I love Italian food.

~/$: clean_code --adopt_principle

Now, onto a fun little acronym. The DRY (Don’t Repeat Yourself) Principle has been hard-coded into my head since about the first year of school. This means avoiding duplicating code and keeping things modular and reusable. It’s like cooking a big batch of sauce and freezing portions for later – efficient and time-saving. Applying DRY allows me to streamline my code, making it cleaner and more maintainable. But this doesn’t always mean it’s the best solution. Everything has edge cases, and there are always situations in which deviating from this principle is actually the better approach.

~/$: example --conciseness_vs_clarity

Let’s look at an example of striking a balance between conciseness and clarity. Consider this function that counts vowels:

const countVowels = s => (s.match(/[aeiou]/gi) || []).length;
console.log(countVowels("hello world"));

It’s concise but can be cryptic for some. Alternatively, a clearer version might look like this:

function countVowels(s) {
  const vowelRegex = /[aeiou]/gi;
  const matches = s.match(vowelRegex) || [];
  return matches.length;
}
console.log(countVowels("hello world"));

This version is more verbose but much easier to understand. And in general, unless I’m working on a personal project and I just want to see how far I can push syntax, I would say the clearer version is far more professional and will save time and energy in the big picture.

~/$: reflection --writing_clean_code

Writing clean code is an ongoing journey, not a destination. It requires continuous learning, adapting, and refining. And it’s not just about making your life easier as a developer but also about being considerate to others who’ll read your code. Remember, code is more often read than written.

~/$: ./end_blog_post

In conclusion, clean code and avoiding code smells are crucial for efficient and maintainable software development. By adopting principles like DRY and ensuring our code is as clear as it is concise, we make our codebase not just a functional piece of technology but a work of craftsmanship.

ctrl+c

Fowler, Martin, and Kent Beck. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 2018.

Martin, Robert Cecil. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall, 2009.