Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Names should be cute, not descriptive

ntietz.com

Post reply on HN
Print view View original

161–170 of 498 posts

Re: Names should be cute, not descriptive

#161

Post by reassembled »

What annoys me is when internal code names are used all over the place throughout the code base. Sure it might make it easier for those steeped in years of company culture to navigate the code, and provide a slightly more playful company culture, but it makes it an absolute nightmare for a beginner to find things.

Furthermore, I often see companies use trademarked words for internal code names, which could lead to problems if their usage is leaked outside the company. I can’t remember what it was but I recall reading that such use of trademarks for internal code names led to legal issues for a company.

Re: Names should be cute, not descriptive

#162

Post by nibbleshifter »

I've flipped between these two positions (descriptive and... not descriptive) names.

I settled on nondescript and just mash two random words together when making a new project.

~90% of my actual work projects are less than 10 files of source code anyway (not counting dependencies, readme, make file, requirements.txt, etc). The vast majority are one file Python or Bash scripts.

Re: Names should be cute, not descriptive

#163

Post by xcambar »

A company I have visited had, for some obscure reason, decided that teams should have their own fun/memorable names. Almost 2 years after implementation, every new hire's first comment was: "it's impossible to navigate the org with those names, we have no idea of what each team is doing".

I could live with funny+descriptive, but for all that is good, funny only just does not work.

Re: Names should be cute, not descriptive

#164

Post by nsonha »

Conan_Kudo wrote: post #150
nsonha wrote: post #126

Earlier quoted context omitted.

> memorable name is it ever a problem in software engineering, that you can't remember what that component's name is? I find it more of the problem when people make a good library that solves a problem with a predictable name, but then they give their library some other cute name, and maybe they don't do SEO well on package repositories (why would they, software engineers). So, when I look npm up for that problem, th…

> is it ever a problem in software engineering, that you can't remember what that component's name is? Yes. When the names are descriptive or bland, it's almost impossible to remember what it is .

Question wasn't if people forget names in software, it's whether forgetting names is a problem. Like I forget names of things in the codebase MULTIPLE times per day, but I don't, and am not aware of anyone naming variables, functions etc in order for them to be memorable (as opposed to descriptive). I neither need nor want to memorize those names, I have other things more interesting to fill up my memory with.

Re: Names should be cute, not descriptive

#165

Post by xeyownt »

afarrell wrote: post #156
bmitc wrote: post #128

I could not disagree more. > Trouble is, names are hard to change. No they’re not. People just aren’t determined or organized. > It's impossible to predict with certainty how your software's requirements will evolve over time. You don’t need to predict it. You evolve things as needed, including names of components of the system. The idea that you need to pick a generic name because you don’t want to specify exactly w…

Cute names are fun for the people creating them and writing code. They are stressful for the people trying to make sense of code and maintain a product under a deadline. The question is, which matters more: A. Having fun yourself over the course of a week. B. Getting a job done and helping your coworkers get their job done over the course of years.

I guess the point is to give cute names to things that will last years and have a large scope, not to every variable in your code.

Re: Names should be cute, not descriptive

#166

Post by jagged-chisel »

> Names are hard to change.

Brands are hard to change. Is your thing a brand for your company? Probably.

You need your "cute" name (branding, differentiation, trademark) and a descriptive name. "Marmaray" tells the reader nothing. "Marmaray Tunnel Service" is more informative. Of course, once your fellow conversants become accustomed to the vocabulary, "Marmaray" is going to save time during speaking. Until then, you're just going to have to be aware that you'll need to educate folks along the way.

I find it outright pretentious when I hear anyone using strings of "cute" names with no attempt at actually explaining the stack.

Re: Names should be cute, not descriptive

#168

Post by Pietertje »

bmitc wrote: post #128

I could not disagree more. > Trouble is, names are hard to change. No they’re not. People just aren’t determined or organized. > It's impossible to predict with certainty how your software's requirements will evolve over time. You don’t need to predict it. You evolve things as needed, including names of components of the system. The idea that you need to pick a generic name because you don’t want to specify exactly w…

I could not agree more... with you. On top of that, good luck onboarding new recruits or people that move departments.... Cute names are just like abbreviations, they are jargon and are an unnecessary hurdle to become effective.

Re: Names should be cute, not descriptive

#170

Post by fragmede »

andrelaszlo wrote: post #160
pmelendez wrote: post #146

Earlier quoted context omitted.

> You know what is fun when it comes to work? Things that work, are named appropriately, are understandable, and people not needing trivialities I don’t know I agree with this. Microsoft has taken the descriptive naming style all the way down to products. Not only names like Batch or Functions don’t add much value, but also it makes searching information about them much harder than “cute” names (such as Excel). I als…

Haha, I am not picking sides but I recently saw a suggestion to move a service's DNS records from Cloud DNS to Cloud DNS. One was GCP and the other some smaller provider. For the big cloud providers, I've definitely seen people struggle with the names. Is it Google Compute Engine or Google Cloud Engine? Which one is which of Google Cloud Run and Google Compute Engine? Amazon Route 53? Route 57? 35? I guess the bigger…

DNS runs on port 53, so it's easy to remember the name of AWS' DNS service.
Post reply on HN