Comment by ttiurani | Hacker News Reader

Comment by ttiurani | Hacker News Reader

With naming what IMO matters more than choosing one name, is choosing a name that is consistent with other similar names in the codebase. A new developer will learn your project's specific convention in a few minutes, but will be completely lost if the convention is routinely violated here and there. This is especially important with what verbs to use in methods, and how to name interfaces/classes in a way that respects both the business domain and the techical use.

I've seen way too many times how much confusion is created and time wasted when a developer not too familiar with the project comes up with a brand new verb for a common action, and couples it with a new synonym for an existing business domain entity – or worse still, uses the same name previously meant for a completely different domain entity.

The unfortunate burden with this is that a new developer might be right that their name is better for their use case, which then leads to laboursome debates about which is more important: consistency or slightly crisper name for the one use case.

You have to be careful with your definitions. Don’t use different definitions of the same verb/noun in different places. You get one. If you need another definition elsewhere, use a synonym.

It is not beneath you to hit thesaurus.com while picking a name.

A thesaurus is one of my favorite dev tools.

100%. I use RhymeZone and Wordnik more than I care to admit during development work.

Naming gets far worse than that. I've worked on code where the naming was not just unhelpful, it was outright misleading. One of the worst I remember was a project which unsurprisingly was named after a game of thrones character. As I never watched game of thrones it took me about two weeks before I could even remember the stupid name, during which time I was also dumbfounded as to how the program worked until I realised the naming in the code was equally bad, completely misleading. Then there's the place where the stg1 environment was actually the dev0 environment...

> I've worked on code where the naming was not just unhelpful, it was outright misleading.

It's one way to achieve job security for life though: https://github.com/Droogans/unmaintainable-code

One of the best coding interviews I had was an paired debugging session and the problem boiled down to a poorly named parameter at the beginning.

> Then there's the place where the stg1 environment was actually the dev0 environment...

Hey, think yourself lucky. It's only a pretty recent occurrence that my team has more than just the two "Prod" and "Non-Prod" environments...

Using the name “prod” for anything other than delivering code to external customers is one of my eternal pet peeves.

When I was working on a small game startup back 20 years ago, I renamed our all the high-level projects of our codebase into specifically-ancient Greek and then left a "glossary.txt" in the root directory so people could brush up on their language skills... this did not last for very long ;P.

One of the worst I remember was a project which unsurprisingly was named after a game of thrones character.

I remember the era when sys admins would name machines or environments after nerdy shit like Tatooine, Dagobah. And you had to memorise which was the test environment and which was the mail server.

Thankfully I have never seen that in code.

This goes double for APIs, and triple for externally facing APIs, where typically the people who are working with it aren't familiar with your code base or naming conventions.

That's why good API design is so hard. Every name you assign to something becomes a convention by default.

Couldn’t agree more with this. Consistency is key even if the convention used is awkward

Yes, convention is more important that the quality of the convention. The convention abnegates the need to think about things, and for a developer, thoughts are precious.

With a good convention, even more important, structure can be derived and deduced, without reading the documentation. I love it, when i begin to grasp the structure of a codebase, write a line and hit auto-complete and the codebase was reliable. Functionname exists and parameters expected are served up. The code just feels so much more discover-able in such moments.

Reply on news.ycombinator.com