Hacker News new | past | comments | ask | show | jobs | submit login

Can't leave any room for ambiguity!

Apple-style function/method naming may be verbose but at least the names usually have good explanatory value and aren't just meaningless verbosity.




And in the 21st century, everybody's using tab to autocomplete that string anyway.


The problem is when you have multiple very long identifiers that differ only in a few characters. When scanning through code, it's much easier to see the difference between a saaainheafh and a saaainheafi than it is a shouldSuppressAutocorrectionAndAutocaptializationInHiddenEditableAreasForHost and a shouldSuppressAutocorrectionAndAutocaptializationInHiddenEditableAreasForInput.

Also, autocomplete doesn't work when you're reading and not writing, or just using a text editor or reading/annotating a printout (yes, I still do that.) IMHO writing code that almost completely relies on special tools to handle it is a bad trend.


I'm surprised that I strongly disagree. My eyes glaze right past the difference between the fh and the fi in that example.

They also glaze past the end of the mega-strings, but I usually solve that problem by either actually ctrl-F finding for the string (which will highlight it) or by finding an examplar and selecting it (which will highlight all instances of the same symbol in the languages and IDEs I use).

I'm a firm believer that "code isn't just text" (in fact, most of my frustration with code is tools that treat it so... The set of strings that aren't valid programs is vastly larger than the set that are, so why should I be treating programs as if they're mere strings? It'll lead me to create non-compilable artifacts). So I try to avoid being in situations where the only tools I have to work with to understand code are a text editor or an annotated printout (I don't doubt that's done in places, but I've gone my whole career managing to avoid it so far).


> My eyes glaze right past the difference between the fh and the fi in that example.

Same here. The difference isn't significant enough for my eyes to latch onto.

If I had to come up with short readable function names, I would still use whole words, but would 1) cut the number of words down to the bare minimum 2) make each name as unique as practically possible.


This is a large open source project used by billions of people with many contributors. saaainheafh just doesn’t cut it.


This weird abbreviation fetish was a big turnoff when I just got into programming (about 15 years ago when it was a lot more common). It’s just nonsensical and off putting.


You should try to change your perspective: Source code is its own language, and much like with natural languages, to get good at programming you should learn the language of the source code and not try to dumb-down by constantly trying to translate back to English.


It can be a time saver and helpful when you’re writing it. But hurts even yourself a year or two later. Others with no previous code base experience have it 10x worse.


I think this is an extreme case where no matter what you do the difference is non-obvious. It's a very similar name with a small difference.




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: