[xigma]

> It costs almost nothing more to write "event" instead of "ev" or "removeElement" instead of "remEl", but it makes the code much more readable.

No, it doesn't. Unless you're an absolute beginner, it takes you a couple of seconds to realize that in this codebase, "ev" (or "evt" or even "e") means "event". The same goes for "remEl". If that's consistent, then it's not a big deal at all.

Having less characters makes code more readable (or rather "scannable") as well, it's just another tradeoff.

[krapp]

>Having less characters makes code more readable (or rather "scannable") as well, it's just another tradeoff.

Only to a point, otherwise minified js would be more legible than plain source. It takes "a couple of seconds" to scan the codebase and find out what el or ev refer to, but it would take zero seconds if they were just called "event" or "element."[0] There's no gain in readability from shaving off one or two characters in that case. It just "feels" more efficient because it resembles the common style of lower level code.

[0]Assuming those aren't reserved words in javascript, I don't know.

[xigma]

Of course, up to a point. The same goes for very long but extremely descriptive variable names. Hence, it is a tradeoff.

[dvlsg]

You are allowed to use both event and element, as they aren't strictly reserved keywords.

I think it's generally frowned upon, though. For example, I believe "event" is defined as a global in browsers (on window, perhaps?), so you run the risk of shadowed variables and accidentally referring to the wrong thing.

[thinkingemote]

Having anything take a couple of seconds more to read something is by definition making something less readable.

Okay so perhaps a couple of seconds doesn't matter. How many seconds does?

[sidlls]

There's an objective definition for readable?

[xigma]

426.

[mattlondon]

Less characters really only makes sense in some scenarios, e.g. "unimportant" variables (for loops, temporary storage inside a procedure). Verbose 'variablesToKeepTrackOfPositionInThisLoop' is obviously pointless when 'i' will do.

However renaming "important" things to make it quicker to read or type is, in my experience, a mistake if your code base is more than just a handful of files. Descriptive names make it much easier to understand the code which is more important in my experience. As the number of code files gets beyond a few files any benefits you get are rapidly lost because now you need to keep all that knowledge in your head and start having to jump around between 5, 10, 20 or more files to work out what everything is let alone what it is doing. This is why naming stuff in code is so important (and sometimes so hard).

Golang has a good philosophy on this front: https://github.com/golang/go/wiki/CodeReviewComments#variabl... tl-dr: the further from its declaration that a name is used, the more descriptive it should be.

This sort of attitude about brevity & speed appears to be a common problem with some developers I come across - they are absolutely obsessed with "productivity" when it comes to writing code. They've just got to have their 97 plugins/extensions to their editor and they simply must have their finely-honed emacs keybindings. If you are focusing on just churning out code as fast as humanly possible (i.e. "productivity"), then your job as a programmer can probably be safely replaced with a couple of shell-scripts.

I've never been in a situation where the limiting factor in programming has been how fast I can read it or write it - the limiting factor has always been understanding the problem at hand, and designing a solution that solves the problem and is maintainable.

[xigma]

The point I'm making is not "use short variables everywhere", it's that in this case, the verbose alternative is not "much more readable".

Abbreviating "element" to "el" or using "attr" instead of "attribute" (etc.) can significantly reduce noise in web client code. Everybody either knows what it means, or they shouldn't be editing the code in the first place.

[spiralx]

I prefer "elem" as then it's easier to distinguish from "event" than it is for "el" and "ev".

[mixedCase]

> Verbose 'variablesToKeepTrackOfPositionInThisLoop' is obviously pointless when 'i' will do

Based on a Fortran convention, IIRC. Within a web setting, "el" and "ev" are extremely conventional.

[firethief]

> tl-dr: the further from its declaration that a name is used, the more descriptive it should be.

Interestingly, this results in more or less the opposite of entropy coding

[markbnj]

> Having less characters makes code more readable (or rather "scannable") as well, it's just another tradeoff.

It might, in a specific circumstance, while in another circumstance it might make the code significantly less readable. That is an indication that number of characters is probably not a good metric for adjusting readability.

[zrobotics]

Couldn't agree more, sometimes too long makes things so much worse. I don't know why this is more common in Java code bases, but I've definitely seen function calls that take 6+ lines (have to maintain that 80 column limit) due to horrible naming. By the time I finish reading that, I've already forgotten what the base class is even called.

However, I've also seen large classes with members like "stN" for "set N". WTF is N, and why can't we just type set, that one char doesn't save anybody any time at all. Or nested loops with i & j reversed, just to make it especially painful.

[h1d]

Unless you're a machine, don't know what to tell you.