Naming the things in programming

Naming things in programming

“There are only two hard things in Computer Science: cache invalidation and naming things.”

— Phil Karlton

Naming the things in programming is actually quite a hard task when you have multiple options to choose from your thoughts.

In my first year of programming, I thought naming was the easiest thing until I realized I have to write code for humans. Then I started spending more times on naming things, then I started renaming those named things and again I started renaming things while on refactoring.

I have grown from -:

var a,var x, var finalData

arrayManipulation();initialize();start();

to

var ProductPrice var UserEmailVerificationTokenvar ProcessedData

arrayToJson();fetchUserData();startRenderingHtml()

And yet I still felt like I was missing some meaning in them . The names were longer as well. I was afraid my quest to make names meaningful was going to turn them into paragraphs.

And I started realizing that-:

• The variables or functions should be named by its work -: Name of variables/functions should always try to express their meaning without diving into the code base try to pack meaningful information inside the name.

function arrayManipulation(array) {

// converts array to json// returns json

}

In the above example, the naming is quite not specific as our method only converts array to JSON . Readers might wonder whether its a way to filter array ?, map array, converts array to JSON, converts array to XML and so on.

function convertArrayToJson(array) {

// converts array to json// returns json}

`convertArrayToJson` sounds more specific and tell what it really does.

• Naming should be simple enough to be understood by everyone -: Using complex words to describe a simple thing only creates hassle while reading the code.

function constituteJournal() {

//creates journal in DB}

function createJournal() {

//creates journal in DB}

In the above example, `createJournal` makes much more sense than using `constituteJournal`.

• Prefer Concrete Names over Abstract Names -: Many possibilities create confusion using abstract names confuses readers.

var start = (new Date()).getTime(); // top of the page...var elapsed = (new Date()).getTime() - start; // bottom of the pagedocument.writeln("Load time was: " + elapsed + " seconds");

There is nothing obviously wrong with this code, but it doesn’t work, because `getTime()` returns milliseconds, not seconds.By appending _ms to our variables, we can make everything more explicit:

var start_ms = (new Date()).getTime(); // top of the pagevar elapsed_ms = (new Date()).getTime() - start_ms; // bottom of the pagedocument.writeln("Load time was: " + elapsed_ms / 1000 + " seconds")

• Don’t hesitate to use longer names -: We use short words even if it doesn’t provide full insight about the code which is a bad thing to do.

function killProcess(pid) {// kills process by process id

}

Looks like `killProcess` doesn’t hold much information about how it is going to kill the process. It would have been better if we had used.

function killProccessByid(pid) {

//kills process by id}

• Prepare yourself to make a mindset that you won’t be writing more comments now, your naming will provide an insight into the process.

Conclusion -: Just try to avoid generic names. Use concrete / specific names, longer names if you need to, attach important details (pack much information) and mainly focus on code readability. Things take time to change. Happy Coding!

Inspiration

Naming the things in programming was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.