Disclaimer
This post is a reply to
kangax question:
I’m sorry but why such vicious coding style?I'd like to explain my point of view about JavaScript code style so, if interested, please read until the end, thank you :)
Some Background
I study and use JavaScript since year 2000 and one of the most interesting thing about this language is that even if it is "that old" you never stop to learn something new (techniques, strategies, adapted patterns, etc).
At the same time, the "
biggest trouble" of this language is its weight in a page, which is the reason we all use minified and gzipped or packed versions of our application. Coming from a "
33Kb modem internet era" I always tried to pay attention about the size and I studied and created both a
JavaScript minifier and a
compressor.
Compressors Rules
Unless we are not using an "
incremental" compressor, as
GIF is, we should consider that
packer algorithm, as
gzip and
deflate, are
dictionary based compressors (
Huffman coding).
These techniques to minimize our scripts size give us best compression ratio if we use a reduced dictionary. In few words, if we have these two piece of codes:
// code A
function tS(obj){
return obj.toString();
};
// code B
function toString(obj){
return obj.toString();
};
even if the length of the
code A is
smaller, it will use
1 or more bytes than code B once compressed.
The reason is really simple. Try to imagine that both codes are converted in this way:
// code A
0 1(2){3 2.4();};[function,tS,obj,return,toString]
// code B
0 1(2){3 2.1();};[function,toString,obj,return]
Code B has a reduced dictionary, and reduced dictionary means best ratio. That's why when I introduced years ago the little
bytefx library I defined it "
packer friendly" (variables name are similar in the entire code).
How Compressors Changed My Way To Code in JavaScript
Accordingly, and probably against every common programming naming convention practice, those studies let me think that as long as a variable name is meaningful enough, it does not matter if it is perfectly clear to recognize or not, since in every case when we want to understand a code, we need to read it from the beginning to the end. Here there are a couple of example:
// (pseudo)compilable language practices
var splitted = "a.b.c".split(".");
function argsToArray(args){
return Array.prototype.slice.call(args);
};
// my code style
var split = "a.b.c".split(".");
function slice(arguments){
return Array.prototype.slice.call(arguments);
};
The split variable is meaningful enough, it is something that has been splitted via split method, and the same is for the slice function: I use it to call the slice Array method over a generic ArrayLike object, as the Object arguments is.
Confusion, Ambiguity, WTF About arguments? Not Really!
The reason I chose inside the slice function the variable name
arguments is simple: in that function
I do not need its own ArrayObject arguments, while I will use that function mainly with an ArrayObject arguments variable from other functions.
function doStuff(){
var Array = slice(arguments); // other stuff
};
How can be then that arguments variable considered ambiguous?
Moreover, that function "
will cost zero once compressed", because in every code I've seen so far the generic function arguments variable, plus the slice method from Array's prototype, are always part of the rest of the code. So, in terms of bytes, I have added a
useful function in only 8 extra bytes: (){();};
OMG! I even called a variable Array inside the doStuff function!!!
Yes I did indeed, and the reason is still the same: almost every library or piece of code use the Array keyword but if I do not need the global Array constructor in that scope, why should I leave such meaningful dictionary word untouched?
Moreover, the Array global constructor is used mainly because of its prototype, but once I have an Array variable called Array I can simply use directly its methods instead of the global one, considering those are exactly the same.
function doStuff(){
var Array = slice(arguments);
Array.push.apply(this, Array);
return this
};
Finally, the day we will need the native global constructor, String, Object, Array, Function, we can always use the safe window.Array or, if we decided to name a variable window inside a scope, the self.Array or the this.Array or the in line global scope resolution call:
var toString = function(){return this.Object.prototype.toString}();
Is It Just About Naming Convention?
I use different strategies to be sure my code will be the smallest possible. As example, and as showed above on toString assignment, if I need a runtime called function which returns a value and it is not that big function, I do not use parenthesis around.
If an assignment or a return is before an end bracket "}" I do nt usually put the semi colon at the end. For the interpreter,
it does not matter, because it transform in its own way the function.
alert(function(){return this.Object.prototype.toString});
// produced output
function(){
return this.Object.prototype.toString;
}
// indentation, plus semicolons where necessary
The rest is usually managed by the minifier, so the fact that a return"a" does not need a space between return and the String "a" is superfluous if we use, for example, a clever minifier as the
YUI Compressor is. The same is for loop with a single line to execute, I do not use brackets (I love Python indentation style).
for(var key in obj)
if(typeof obj[key] == "string")
obj[key] = parse(obj[key]);
My Style Cons
- tools like JSLint often fail to recognize my code as valid so I do not use JSLint (... but fortunately I do not need it, I now my code is beautiful :P)
- in a Team we should all respect Team code conventions, so my code style could not be the best choice if other programmers do not know JavaScript that much and/or use a specific/different code style
- if the development product will not use minifier + compressors my code style could produce bigger size instead of smaller (Object instead of obj or o)
- my code could require a better lecture than a quick one, but this is true for every library if we would like to understand properly a trick, the entire scope, an assignment, etc, etc ...
My Style Pros
- final size, minified and packed/gzipped, is most of the case reduced if compared with other "code scripters"
- more big is the library I would like to extend, less my implementation costs, thanks to a wide range of words to use (common like key, Object, arguments, Function, etc plus others)
- variable names are often more meaningful than other and instead of function(str, callback, obj){} I bet we cannot understand variables type with a function like function(String, Function, Object){}. So, if possible and when necessary, my code style is closer to strict programming language than every other, allowing me to save time writing directly String as variable name, instead of /* String */ str
Conclusion
I know for somebody my vicious style could be considered a non-sense or something too "extreme" or hard to maintain. But, on the other hand, I am not developing public libraries (I prefer to extend them rather than reinvent the wheel if it is not necesary at all) and my implementations, for me, are much more easy to understand/maintain than others since I often perform linear (sometime tricky) operations which make absolutely sense to me and in a single line when it is possible. You like it? You don't? It does not matter, at least now you know how much pervert a programmer mind could be for an "
out of the common rules language" as JavaScript is.
Enjoy my craziness :D
UpdateSince telling you I have studied these cases was not enough, here is a truly simple demonstration for the Anonymous user that left the comment:
<?php
$output = array();
for($i = 0; $i < 80; $i++)
$output[] = 'testMe';
$str = implode('.', $output);
echo 'WebReflection: '.strlen(gzcompress($str, 9)); // 21
echo '
';
$output = array();
for($i = 0; $i < 80; $i++)
$output[] = 'test'.str_pad($i + 1, 2, '0', STR_PAD_LEFT);
$str = implode('.', $output);
echo 'Anonymous: '.strlen(gzcompress($str, 9)); // 144
?>
21 bytes against 144 so please, if you think my point is wrong, demonstrate it :)
