DEV Community

Naming: Every Developer's Nightmare

Samuel Braun on April 18, 2023

Aah.. naming things. A developer's favorite brain sport, nestled somewhere between attending endless meetings and refactoring code. As developers, ...

Read full post

Solomon Ucko • Apr 21 '23

I think ensureMinusAtStart would be a clearer name for the conditional version of addMinusAtStart.

Samuel Braun • Apr 22 '23

You're right! I wasn't sure if "ensure" was clear enough but hearing it from an independent source.. imma change it 👍

John McCabe • May 2 '23

ensureMinusAtStart() is semantically correct if you are doing that, i.e. if you are adding a minus only if there is not one already there. In the case of:

val = startsWithMinusSign(valueOfCurrentField) ? 
            valueOfCurrentField : 
            ensureMinusAtStart(valueOfCurrentField);

I would be inclined to retain an addMinusAtStart() function such that you have something like this (C++ kind of thing) :

std::string addMinusAtStart(std::string input) 
{
    const std::string minus { "-" } ;
    return minus + inputn
} 

std::string ensureMinusAtStart(std::string input) 
{
    const char minus { '-' };
    return ((input[0] == minus) ? input : addMinusAtStart(input));
}

Just a thought though.

Paul Frischknecht • Apr 23 '23

having learned more about the importance of idempotency (aka desired state pattern) in (distributed) information systems, I use "ensure" all the time now. For example instead of delete(x), we might even write ensureDoesntExist(x).

John McCabe • Apr 30 '23

You need to review your use of if (!valueOfOtherField) if you're targeting clarity. There's no evidence in your code that valueOfOtherField is a boolean type, but (based on C-type-derived languages) the ! operator takes a boolean as input and produces a boolean output.

It looks like you're relying on either an overload of the boolean ! operator, or an implicit cast of valueOfOtherField to a boolean type. Either case is not clear. I have no idea of the type returned by row.doc[otherField] so I would hope that a conditional that used that returned value would be a proper value comparison retuning a boolean (e.g., where the return type us a string, if (valueOfOtherField.isEmpty()).

Brian Kirkpatrick • Apr 25 '23

Naming event listeners in particular, which can be asynchronously managed and therefore trickier to debug within context, is a great exercise. "on[Before|After][state][change]" is a good template here.

Samuel Braun • Apr 26 '23

Great, haven't thought of that one 👍 Thanks for sharing

Brian Kirkpatrick • Apr 27 '23

Good references/examples in the careful thought put into the VS Code extensions API:

vscode-docs.readthedocs.io/en/stab...

Peter Franken • Apr 24 '23

German "Gründlichkeit" at its finest. Very good!

Using logical scheme-based, objective descriptions saves lots of time and effort all around. This is especially helpful in large or long-lived projects, but, honestly, once you get used to naming things like this, you wouldn't have it any other way even in small one-off personal projects, either.

Rense Bakker • Apr 20 '23

Love the intro, more true words were never spoken xD

Adarsh Goyal • Apr 26 '23

how to name a array which will hold two different data let say town data and city data based on condition.

I have named it cityTownData is there any better way to do that

Samuel Braun • Apr 26 '23 • Edited

I did something similar a few weeks ago and needed to change it back. If you can, make them two seperate arrays as this becomes easier to scale and work with in the future. But if not, you could name it cityAndTownData to avoid confusion that "city" is just a descriptor for "town" and "cityTown" is one thing. The condition you can add at the end like this: cityAndTownDataWithLargePopulation or even better cityAndTownArrayWithLargePopulation or citiesAndTownsWithLargePopulation. "data" is too general and could be anything, so replacing it with "array" you give developers a better idea of the type. So final answer would be: citiesAndTownsWithLargePopulation

Adarsh Goyal • Apr 26 '23

as it will be either city or town data so can i make it cityOrTownArray or should i keep them seprate ?

Samuel Braun • Apr 26 '23 • Edited

Don't overengineer your variables and spend too much time thinking about one. The core purpose of good naming is so your code can be easily read by others and yourself without feeling stupid. If you feel stupid reading other peoples code its most likely their fault. Just check your entire function and ask yourself the question. Is the code as a whole clear and understandable? If yes youre fine.

PS: If cities and towns are two different things in your code, seperate them. If they are pretty much the same, just use one word, or a generalization word like "settlement".