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

A made-up name is better than no name

mbuffett.com

Post reply on HN
Print view View original

11–20 of 86 posts

Re: A made-up name is better than no name

#11

Post by marcusbuffett »

efitz wrote: post #8

I really don’t like this idea if you are sharing this code base with anyone else. I work in one of the magnificent seven and the culture here is codename crazy. Everything has code names, of course: every project, every release of every project, every component or subservice of every project, every internal tool, and often minor features that address some one-off problem in any of the above. I am sure that these name…

Oh god yeah I’ve been in this situation too. Working at Apple it was like “is everyone in this meeting cleared for Tigris?” And you’d be like “I don’t know, what the hell is Tigris”, and then it turns out after you check your clearances it’s just iOS 13, which is obviously no mystery that after 12 there will be a 13. Just call it that!

Nothing was named according to what it did either, I think our deploy tool was Carnival? Just codenames everywhere

Re: A made-up name is better than no name

#12

Post by Daneel_ »

Not my preference, even for personal projects. How many times have you come back to an old project and thought “what the heck is this?”. I know it’s a lot for me.

Over the years I’ve learnt to prioritise readability and to never abbreviate. Tab completion makes it a non-issue.

Re: A made-up name is better than no name

#13

Post by p1necone »

mouse_ wrote: post #2

This works great if you're absolutely certain no other poor sap is going to have to work with your code. I do this myself for personal scripts! Otherwise, please prioritize readability.

I think needing to work out what it is by asking someone or reading documentation or whatever is a feature, not a bug here.

If you instead used a word that kinda described what it is without being able to explain specifics people might make assumptions. If they have to go "what the hell is a kep" and then ask you then you can be sure they'll find out about the implementation that's slightly different from other keps, or the weird bug that happens when you do y, or the handy library for doing kep things or whatever before they waste time going down the wrong path.

Obviously this sort of thing should be done sparingly, otherwise you end up with a completely incomprehensible codebase - but for specific things are are genuinely novel I think it could help with overall grokability rather than hinder it.

Re: A made-up name is better than no name

#14

Post by euoia »

marcusbuffett wrote: post #11
efitz wrote: post #8

I really don’t like this idea if you are sharing this code base with anyone else. I work in one of the magnificent seven and the culture here is codename crazy. Everything has code names, of course: every project, every release of every project, every component or subservice of every project, every internal tool, and often minor features that address some one-off problem in any of the above. I am sure that these name…

Oh god yeah I’ve been in this situation too. Working at Apple it was like “is everyone in this meeting cleared for Tigris?” And you’d be like “I don’t know, what the hell is Tigris”, and then it turns out after you check your clearances it’s just iOS 13, which is obviously no mystery that after 12 there will be a 13. Just call it that! Nothing was named according to what it did either, I think our deploy tool was Car…

In general I completely agree that code name overload is dreadful. But I think in this case, where this pair is so fundamental and used so frequently in the codebase, I think I would probably permit it. Beware codename creep.

Re: A made-up name is better than no name

#15

Post by Sweepi »

serbuvlad wrote: post #9

If it occurs often enough, yes! The human brain finds unexpected or weird words a lot more memorable than expected words. grep is better than find "find-regular-expression" awk is better than "execute-command-on-regular-expression" perl has nothing to do with pearls If it's a common command, concept, function, etc. that appears in may places, give it an odd name! Document it thoroughly! And don't go overboard. When e…

I regularly cannot remember if its "grep" or "greb". Never had this issue with Windows' "findstr".

Re: A made-up name is better than no name

#16

Post by deathanatos »

… a company I once worked at named everything after characters from a certain TV show. Effectively the same as a made up name. Let's just say one of the character's name was … a tough one to pronounce. And it caused endless "what's a … Kep?" type questions.

The CTO at some point later on decreed "enough; descriptive names, not made up things" … and the experience was such that I agreed with the decree, and I've sort of felt that way ever since. I've given a few names sparingly to a few things, but mostly a.) they have some connection to the named thing and b.) I reach for it when the purpose isn't clear yet and thus "descriptive" can be hard to come by.

You could have named it a "PoMo" (portmanteau of position-move), if you're tired of typing.

I'm also a bit surprised since the examples are Rust? Some of the naming is sort of "Hungarian notation"-esque. Why not let the type carry that information, and strike it from the name?

Re: A made-up name is better than no name

#18

Post by ketralnis »

serbuvlad wrote: post #9

If it occurs often enough, yes! The human brain finds unexpected or weird words a lot more memorable than expected words. grep is better than find "find-regular-expression" awk is better than "execute-command-on-regular-expression" perl has nothing to do with pearls If it's a common command, concept, function, etc. that appears in may places, give it an odd name! Document it thoroughly! And don't go overboard. When e…

I have a lot of conversations like "There's a technique called 'secure computation', which confusingly is not just computation that is secure", "They're building affordable housing, which confusingly is not housing that is affordable", "I was on a cross-country flight, which confusingly is not a flight that crosses the country". Using a different word entirely can avoid that problem
Post reply on HN