So using @users can lead to more code that is less like English if you use elements of the array more than the array itself.

I have been guilty of taking this concept of "how you will use it" to the extreme of naming collective variables with an 's' if I primarily expect to act on the list as a whole (or iterating over it), but naming without an 's' when I expect to reference individual elements a lot.

Fortunately, I'm usually coding alone. :-)

Makeshifts last the longest.

I'm afraid that, for now at least, I will continue to use

MuchEasierToTypeLongNames rather than

a_pain_in_the_arse_to_type_long_names.

Maybe I have simply been using the former so long that I don't have any difficulty to parsing them, though I think the exaggerated length is a part of the problem.

isaThing(); as opposed to

is_a_thing(); or

$dataFile = './data'; 
$logFile = './log';
[download]

versus

$data_file = './data'; 
$log_file = './log';
[download]

or even

$AoA = [[],[],[]]; versus

$a_o_a = [[],[],[]];

all seem perfectly acceptable choices to my eyes, but more importantly, my fingers. Interupting the flow of typing the name in order to hit shift-- is just to darn awkward I find.

Maybe once we get full ucs support in Perl, we'll be able to rewire our editors so that the space bar produces the utf equivalent of   (I tried to google it, but its not an easy thing to search for :), then we could have variable names like

$much easier to read long variable++;

Though I guess during the transition, this could be fraught with problems.

---

Nah! Your thinking of Simon Templar, originally played by Roger Moore and later by Ian Ogilvy

I suppose it's my typing style then. I'm not a touch typist although I can keep up with anyone who's not seriously trained in touch typing. (I don't look at the keyboard f.ex.)

At any rate I will continue to use underscores unless the   is somehow visualized. Cause how do you want to distinguish a list function chain like @this from a spacified long funcname like @this? (View source and you'll see I typed the latter with  s.)

It can't be the reaching for Shift that breaks your flow - you need to reach for that one for the caps too. So it's the awkward position of the underscore. Obviously the real solution then is to use any kind of real editor and map the underscore to an additional key. Assuming you have mapped Ctrl to Where God Intended It To Be (who ever needs Caps Lock?), Ctrl-Space should work beautifully.

Yes, it does lengthen identifiers - but I'd rather type long identifiers. The other option would be to squint my eyes at the embedded caps until I decide to turn up the font size.. eh..

Makeshifts last the longest.

I have to admit that ReallyHardToReadStyleForLongNames or much_easier_to_read_style_even_for_long_names - indeed anything much bigger than slightly_long_name - are on my personal list of Code Smells.

A variable name that's that long tends to indicate to me that there is some piece of abstraction that I'm missing.

(oh yes, I prefer "_" too :-)

True enough, and I generally don't tend to have more than two underscores in identifiers either. But should the name get long, as it sometimes does, it remains readable, though granted it doesn't happen often.

Makeshifts last the longest.