What should we name it?
Take some time. 'a' is definitely not the answer.
One of the most powerful sentences I've read in the book is "...focus on whether the code reads like paragraphs and sentences."
Yes, that should be the goal. Make sure it flows through the reader's mind like an Ilayaraja's symphony. Inspiring new ideas. Connecting you with the moment. And just...
Okay, enough with Raja sir's music. Back to code.
So how do we make that happen?
Here are a few things that are stuck in my mind.
Use names that describe what you are naming. A method? use a verb. A class? use a noun or a noun phrase. A variable? Describe what it stores.
Believe me, I have seen a fair share of variables in my short career that requires you to be an NSA agent to decipher what it means.
Don't name something as A and make it do B. That's borderline evil. Why would you even think of doing something like that?
a2is not a meaningful name. An alphabet followed by a number is in most cases bad naming.
Imagine calling Ram and Bheem from RRR as
a2. Yeahhh... doesn't sound so good. Does it?
Give your variables, methods and classes some character.
While we are here, please for the love of Rajamouli... don't create your own acronyms.
MBis not the right name for
MahendraBahubali. You see how it can be interpreted in multiple ways right?
Also, don't bring fancy movie names here. Why are you naming that thing
Dumbledore? It isn't going to shoot Avada Kedavra on your bugs anyways.
That wasn't an exhaustive list but you get the idea. Name things in code with a short yet sensible name that makes the reader of the code understand what it does.
No one is awarding you to name things like a compiler. Name them like a human and you'll probably have thank yous of many programmers who are going to read what you are writing today.
That's one chapter. Let's meet for the next one.
Although I present the contents of the book in a fun and though provoking way, I highly recommend you to read through the book once to get a sense of it. You can find the book here.