[ParetoOptimal]

> thus being short brings no benefit if not "habit".

IPersonallyFind tonsOfCode likeThisReally hardToParse, especially when the least important parts have the longest names.

As a result code like that can be overwhelming and sometimes make me dread working with it.

[Falkon1313]

I find they also often indicate over-abstraction or over-complicated generic stuff that is often kind of irrelevant to the domain.

Equipment_Maintenance_Criteria isn't super short, but it appears to actually mean something. Definitely tells you more than just "Selection" would. But all too often it's called something like AbstractServiceFactoryBuilderManagerLocatorPlugin which really doesn't tell you anything at all and leaves you at the end knowing less than you did when you started reading it.

[tartoran]

Yes, long names can be taxing too if taken to extremes. I use descriptive names that spell out the domain or business logic so code becomes as close to self documenting as it gets. However, locally when I have to reference these multiple times I use a short alias, usually the acronyms of the long names so it’s the best of both worlds: don’t have to carry around the long names everywhere but still have a fallback on them when I forget what they represent.

[ipaddr]

do_you_prefer_underscores? iKindOfDo i_kind_of_do

[teddyh]

In Emacs: M-x glasses-mode