views:

379

answers:

11

There is a discussion about JavaScript coding in my work group. Some people argues that we should use long-name for better readability; the others believes that short-name should be favored to same bits-on-wire.

Generally, it is about coding convention. One side believes that identifier such as "fAutoAdjustWidth" is OK, while others prefer to "fAtAjtW".

So, what's the better way? Should we sacrifice readability for performance or not?

+7  A: 

If you're worried about bits on the wire, you could always run a minifier on your code. Then you could develop with long names, and you could release with a much smaller file that has equivalent functionality. The Yahoo YUI Compressor looks like it does whitespace compression and token compression.

rampion
+17  A: 

Make it readable, and if you feel that the resulting JS file is to big, use one of many JS compactors before deploying the production version, while maintaining development version with long names.

BTW. if your really worried about bandwidth, use mod_deflate.

vartec
A: 

Use smaller names where it doesn't affect readability of your code. Bigger names are fine, but try only to use them where it really does make something easier for yourself and others to follow. Lastly (and as stated in other answers) minify your code, and / or turn on some kind of server compression mechanism such as apache's mod_gzip or mod_deflate to reduce the number of bits flowing through the wires.

With that said, I would prioritise readability over compactness of variable names.

karim79
+1  A: 

I would strongly advise against using short identifiers. Just reading your example shows how much more documentation is suddenly needed, when names like fAtAjtW are used. At some point it will get pretty much unmaintainable and this just for saving some bytes to transfer.

If the only reason for considering "short" names is to make the resulting script smaller and thus save some bandwidth, I would instead recommend using gzip compression, which will save you way more than a few bytes for an identifier.

Simon Lehmann
+1  A: 

Write the long names, sure not too long, but names which describe the variable, function well. And i think the only thing that you will need short names, it to make the file smaller, but that you can do by tools while uploading online.

Amr ElGarhy
+2  A: 

Do these same people advocate not writing comments in their code? Be entirely clear and descriptive with your variable names.

nickf
+1  A: 

Maybe the worry isn't about bits on the wire but the overhead of reading and re/over-viewing the code.

I tend to favor short names inside function and make function names as long as necessary, but as short as possible without loosing useful meaning.

No doubt it is a trade-off. It depends on whether you want your code to resemble natural language or be more implicit and compact.

Some prefix variable names to inject context information into them. I say, if that is necessary, the IDE should provide such injection capabilities as a visual overlay on the code via context symbolics.

The next version of Visual Studio will make such annotation gymnastics much easier via a fine-grained extensibility mechanism extended deep into the editor itself. I have not used Visual Studio for editing Javascript though.

I see now that your concern is indeed the space trade-off. This should never, ever, ever be an issue. Always always always favor readability over bits on the wire, esp. since compression exists, as noted by the other commentators.

The only thing I would add is the above, which is that sometimes comprehension is made easier with compact names over excessively long names. But it is harder to get short names right. Long names are much easier and faster to make right in my experience.

The reason for short names should never be data compression only cognitive efficiency. What works is individual.

Bent Rasmussen
+1  A: 

while others prefer to "fAtAjtW"

Even if "bits-on-wire" was an issue (which it's not), a naming convention like this will make the code completely unmaintainable after the first week of working on the project.

Reading the code will get to be near impossible, and when writing the code people will constantly have to think about things like "was 'fAutoAdjustWidth' abbreviated 'fAtAjtW' or was it 'fAutAtW'?". It's a huge mental tax to pay while writing code that will result in far lower productivity.

On top of that, the problem is exacerbated by the fact that in Javascript you will get a new variable for every mistyped name!

17 of 26
A: 

One side believes that identifier such as "fAutoAdjustWidth" is OK, while others prefer to "fAtAjtW".

‘fAtAjtW’ is an unreadable, untypeable horror. Seriously, anyone prefers that? Hilarious and impossible to remember — is it ‘AtAjt’, or ‘AutAdj’...?

‘autoAdjustWidth’ would be a suitable full attribute name. (I'm not convinced about the ‘f’ prefix notation at all, but that's another issue.) Sometimes you want a very short name for a short-lived variable (eg. a temporary in a small loop), in which case I'd personally go straight for ‘var aaw’ rather than the above nightmare.

As for performance, there will be no difference. JavaScript doesn't care how long you make variable names, and assuming you're deflating your scripts on the way to the browser the compression will remove any transfer advantage of the shorter names.

bobince
A: 

Use big variable names because they help the programmer.

To save bits over the wire, minify your Javascript before deploying it to the production server. Dean Edwards' packer has an option to compress variable names, which looks like the best of both worlds for you.

Josh Stodola
A: 

Whoever thinks "fAtAjtW" is preferable is using some sort of pharmacalogical method in their programnming. fAutoAdjustWidth is very fine and very prudent. Javascript libraries do not use names like fAtAjtW for a reason. If you are worried about the size then probably your worries are misplaced. However, I recommend using some sort of minifier. However, that said, don't use ridiculously long; probably anything over 25-30 chars is going a bit far.

BobbyShaftoe