Clean Code

Making Your Code Speak -

Imagine you're at a café trying to order a coffee, but the menu is in a language you don't understand. Frustrating, right? That's how I felt about coding until I explored the concept of Clean Coding.

Martin Fowler once said, “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” This sums up my recent enlightenment at the Tech Lunch event in a Lancaster business community. This event was hosted by one of the cofounders ‘Maharani Hariga’ from adirani Digital Solutions, the company I’ve been working with for the past 1 year as a Product Marketer. Her insights into Clean Coding as a ‘non - techie’ cofounder, triggered a good conversation in the hub among other developers & founders. That is when I came up with the idea of writing a blog about it.  

Here’s a blend of what I learned from the event –

1.    Naming is Key – Phil Karlton has put  it aptly, “There are only two hard things in Computer Science: cache invalidation and naming things.” Naming variables or any element in your code should be like naming a character in a novel – it tells a story. For example, if you want to showcase the time spent on a particular activity, Instead of cryptic names like 'var d', use descriptive names like 'elapsedTimeInDays'. It should reveal its purpose, action, and usage.

2.    Meaningful Comments –  The comments that you write for a piece of code have to be clear & describe the function of the code currently. This prevents the misinterpretations of the code piece by the developer. Usually, the comments are the first insight into any method or function, which can be a direct point of reference for any developer to read the code & develop a functionality on top of it.

3.     Avoid Disinformation – Be precise with your words. If you’re naming a collection of accounts, 'accounts' is better than 'accountList', unless it’s specifically a list. Misleading names can lead developers down the wrong path.

4.     Clear Code Layout – Just like a well-organized room, your code should have a structure that’s easy to navigate. Avoid the dreaded 'spaghetti code'. No developer likes reading a series of if-else loops, so complex that it’s difficult to understand what’s going on in the code.

5.     Embrace the Single Responsibility Principle (SRP) – Each piece of your code should have one job instead of being a jack of all trades. It keeps things simple and avoids confusion.

Reflecting on these principles, coding now feels less like a puzzle and more like a clear conversation. It's not just about the code working; it's about it being understandable, maintainable, and welcoming to the next person who reads it. It’s about making the complex simple, the unclear clear, and turning the daunting into the doable.

So, wrapping this up, I've realized that coding isn't just about getting the job done. It's about writing code that's easy for everyone to read and work with, kind of like writing a clear, helpful note to a friend instead of a confusing one. Every time we sit down to code, we're not just typing commands – we are being mindful of the next developer that will be reading the code. Let’s aim to make our code clear and welcoming, just like a good story that everyone can enjoy. That way, we're not just coders – we're storytellers using code as our language.