Naming things in programming

ujwal dhakal
3 min readOct 22, 2019

“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();
tovar ProductPrice
var UserEmailVerificationToken
var 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 page
document.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 page
var elapsed_ms = (new Date()).getTime() - start_ms; // bottom of the page
document.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

--

--