12

I am from Java background and am new to JavaScript. I have noticed many JavaScript methods using single character parameter names, such as in the following example.

doSomething(a,b,c)

I don't like it, but a fellow JavaScript developer convinced me that this is done to reduce the file size, noting that JavaScript files have to be transferred to the browser.

Then I found myself talking to another developer. He showed me the way that Firefox will truncate variable names to load the page faster. Is this a standard practice for web browsers?

What are the best-practice naming conversions that should be followed when programming in JavaScript? Does identifier length matter, and if so, to what extent?

Craige
  • 3,791
  • 21
  • 30
ManuPK
  • 822
  • 1
  • 8
  • 16
  • 13
    I highly doubt browsers change variable names. In the presence of `eval`, it's not safe (yeah, `eval` is horrible, but it's part of the standard and you don't throw away standard compilance for an optimization) and it doesn't help the slightest bit in reducing traffic - you'd still send the full file. –  Mar 13 '12 at 14:09
  • 4
    I have often seen developers arguing about the advantages of short variable names. Don't listen to them. This is almost always an excuse for "I am too thumb to invent a good name" or "I am too lazy to type that many characters". – Doc Brown Mar 27 '12 at 15:47
  • @DocBrown: Even I did't like it. Since I am not a expert in JavaScript wanted know the best practice. – ManuPK Mar 27 '12 at 16:31
  • At the end of the day were talking about perhaps 50-100KB worth of additional data in order to use meaningful method names? If 100KB causes a speed problem then, its not worth trying to solve, because not a big enough pool of users will experience that problem. – Ramhound Oct 04 '12 at 14:05

6 Answers6

26

You will find that the developers themselves are not using short variable names. Whilst developing, they are using meaningful and detailed variable names.

Then, in the build/release process, the code they've written is ran through a minifier/obfuscator with the intention of minimizing the size of the file, as a best practise to speed up a website. This is an optional step if you care that much about performance. Most small websites don't do this.

You, as a developer, should not care about the minification/ obfuscation process; write your code so that it is readable, meaningful, well documented and well structured. Then if you care so much about performance (optional, don't forget!), introduce a minifier/ obfuscator into your release process to minize the code (remove white space, new lines, comments etc) and to obfuscate it (e.g. shorten variable names). A good article which explains obfuscation vs minification can be found here.

Additionally, Desktop FireFox will not truncate variable names period. The truncation of variable names is there to speed up the page download. By the time FireFox gets the file, it has already been downloaded therefore there is no need to do so. Your friend may run a plugin which is doing this; in which case, tell him to uninstall it, because it's useless.

For completion, some (mobile) browsers have the option to use middle-man servers, which intercept the responses of resources you requested, and compress them for you (which could include the minification of JavaScript files). Note that the compression is done on the server (i.e. before you have downloaded the page), hence the potential benefit of downloading a smaller file, rather than in the browser once you have already downloaded the file (as suggested in the question). Such mobile browsers include Opera Mini, and newer versions of Google Chrome (on iOS at least; not sure about Android). For more info, see here.

Community
  • 1
Matt
  • 473
  • 3
  • 11
11

No, not all browsers will automactically shorten the JavaScript to help with performance.

However, in the case of JavaScript, you should not sacrifice code readability/maintainability for gains in processing speed or security because there are tools called obfuscators and other tools called shinkers (or compressors) which were designed for this purpose.

Remember, don't pre-optimize. If your page is loading quickly enough, and you don't have any overly-sensitive content in your JavaScript, don't worry about it. Name your variables with meaningful names. Code readability is highly important for maintainability and should rarely, if ever, be sacrificed.

If you'd like a reference to some good JavaScript coding conventions, I recommend using these.

CFL_Jeff
  • 3,517
  • 23
  • 33
2

Don't worry about the file size prematurely. While it is always a concern, readability and maintainability is more important.

With that said, you should probably be servining minified (e.g., via YUI Compressor) versions of your scripts anyway.

If you're interested in best practices for web development in general, I suggest reading What should every programmer know about web development?

Community
  • 1
Craige
  • 3,791
  • 21
  • 30
1

I worked in JavaScript for a very long time.

We had a naming standard that you had to use Hungarian Notation for all variables.

It seemed to work OK. I know that there are cases against using that, but it worked well for us. Especially when you have massive JavaScript files where you need to find stuff.

I would caution against prematurely optimizing. You are very likely to end up with messy code that doesn't really run much faster at all.

Alan Delimon
  • 440
  • 2
  • 6
  • 5
    Hungarian Notation? Thats old school. Hungarian Notation is an old development relique and in time its not recommended anymore. – Smokefoot Mar 13 '12 at 18:00
  • 2
    I tend to use it a little bit, but only for values that are wrapped by jquery, those I will start with a $. The problem with Hungarian notation is that people used to tell you type in terms of "int" vs "String" and not in terms of the sematics of a program – Zachary K Mar 13 '12 at 18:14
  • "Especially when you have massive JavaScript files where you need to find stuff." -- I hear you. But Hungarian notation is just a sticking plaster... it won't help in the long run, it will just confuse when you need to change the type of something but don't have the time to change all the variable prefixes. Automating all that is where GWT comes in to its own IMO. – funkybro Mar 14 '12 at 08:01
  • 1
    I don't necessarily buy using the notation as "breaking" the loosely typed aspects of the language. Sure, you would have to change the name when you are changing the type, but that would be a good thing to do anyway so you can *track* what you are doing. I know there are aspects of it that are ugly. But, if you've ever worked in a LARGE (I'm talking hundreds of thousands of lines of code) project in a loosely typed language, it can help you find your way faster in certain instances. Saying it's dated, etc really doesn't address the core issue the OP was trying to slove. – Alan Delimon Mar 14 '12 at 14:55
  • 1
    Hungarian notation is one of those things that people dismiss immediately without really understanding why. It's found it's way into the same category as `goto` where people mindlessly repeat the mantra *'dont use goto... don't use goto...'*. The reality is that it's just a tool in your toolkit. Like any tool it has situations where it's useful and situations where it's not so useful (or even harmful). It's like someone had a bad experience trying to saw a piece of wood with a hammer, and then proclaimed *'don't use hammers ever, saws a much better!'*. Sweeping generalizations are always wrong – MattDavey Oct 04 '12 at 09:46
1

Identifier length does not matter. As said by others, in production Minification can be used to reduce script download time. In fact, an acceptable coding/naming convention should be followed, especially because JavaScript is a quirky language and for so long JavaScript has been neglected as just a thing to get the job done. If you are looking for a place for naming convention, Google JavaScript Style Guide is a good place. It suggests,

  • functionNamesLikeThis, e.g., getCashbackData() {}
  • variableNamesLikeThis, e.g., var alertInterval = 10;
  • ClassNamesLikeThis, e.g., var CustomerOrder = { getOrderLines: function () {} }
  • EnumNamesLikeThis, e.g., var ColorOfChoice = { White: "#FFFFFF" }
  • methodNamesLikeThis, e.g., var CustomerOrder = { getOrderLine: function () {} }
  • SYMBOLIC_CONSTANTS_LIKE_THIS, e.g., var EPOCH_UNIX = "01011970"
theD
  • 2,883
  • 1
  • 16
  • 16
  • Do you have anything more to add then a bunch of links? I mean you don't even explain who Douglas Crockford is. – Ramhound Oct 04 '12 at 14:07
0

Infuriated by the "clean code developer" philosophy (and given you now know from above posts that with due to minifying the size of your variable names will have zero impact on performance) i could only advise:

  1. Find the best IDE for your personal development needs that has a decent auto-completion and intellisense features, such as aptana, netbeans, eclipse (all free) or any of the numerous commercial products (if i had a free-game, i'd look into JetBrains' products)

  2. Write your code in a manner that makes any commenting superfluous. That means, instead of writing

    getXy(e) { return [e.pageX, e.pageY ] }

    which could mean really anything (especially in a crazy loosely typed language like js ;) you make the code express itself

    getPageCoordinatesFromEvent(event) { 
    return [event.pageX, event.pageY ];
}

    In a good IDE, you would typically never type any variable name that long twice - seconds time you type a few letters and just press enter from the auto-completion. If you insist on typing every character yourself, a good IDE will anyway notice you of a typo anyway. This is just a very superficial example, therefore i strongly suggest (not as a form of criticism but as an honest recommendation) that you

  3. Get the books "Clean Code" by Robert C.Martin and or "Pragmatic Programmer" by Hunt/Thomas and never ask yourself this kind of questions again - you'll be much too busy working on a continuous integration server to automate the boring test-, & build parts of the development process (including minifying) and concentrate on the fun part, writing clearly understandable code that does great stuff!

P.S. If you need to get up to speed with developing state-of-the-art javascript code, take a peek at John "Mr. jQuery" Resig's book on "Pro Javascript Techniques" right after or together with the above .

Philzen
  • 101
  • 3