Quit reusing temporary variables
Closed this issue · 5 comments
Pros
- May run faster on modern type-analysing engines.
- Less boilerplate in compiler.
Cons
- Uglier compilation.
E.g.:
$ coco -bce 'a < f() < g() < b'
var ref$;
a < (ref$ = f()) && ref$ < (ref$ = g()) && ref$ < b;
would go back similar to:
$ coffee -bce 'a < f() < g() < b'
// Generated by CoffeeScript 1.4.0
var _ref, _ref1;
((a < (_ref1 = f()) && _ref1 < (_ref = g())) && _ref < b);
- Uglier compilation.
I don't think that's really true. The varlist will be at the top on one line, so for this it doesn't matter, and ref
or ref1
doesn't change much to my eyes
The longer the list the more it hurts eyes, especially when your editor wraps lines.
E.g. test/literal.co compilation would go from:
var i, ref$, a, b, obj, array, x, y, one, two, zero, n, m, count, list, key$, b
ase, c, num, share, e, fn, o, f, q, O, ref1$, u, ref2$, ref3$, x0$, res$, i$, l
en$, x1$, x2$, funs, x3$, x4$, this$ = this, toString$ = {}.toString, slice$ =
[].slice, join$ = [].join, replace$ = ''.replace, split$ = ''.split;
to:
var i, ref$, a, b, obj, ref1$, array, ref2$, ref3$, ref4$, x, y, one, two, zero
, n, m, count, list, key$, key1$, key2$, base, ref5$, ref6$, ref7$, c, num, sha
re, ref8$, e, fn, o, ref9$, ref10$, ref11$, ref12$, ref13$, f, ref14$, q, O, re
f15$, key3$, ref16$, key4$, u, ref17$, ref18$, ref19$, ref20$, ref21$, ref22$,
ref23$, ref24$, ref25$, ref26$, ref27$, ref28$, ref29$, ref30$, ref31$, ref32$,
ref33$, x0$, res$, i$, len$, x1$, x2$, funs, x3$, x4$, ref34$, ref35$, ref36$,
ref37$, ref38$, ref39$, ref40$, this$ = this, toString$ = {}.toString, slice$
= [].slice, join$ = [].join, replace$ = ''.replace, split$ = ''.split;
Though yes, it's only about the length of var
lines and variable names.
var eR, ref$, a, sum, i$, len$, n, result, o, points, I2, e, moe, obj, config, key, pick, t, i, ref1$, b, show, til, x$, y$, z$, z1$, slice$ = [].slice, join$ = [].join;
for me.
I don't really care about variable declarations in my compiled files - if I need to open one to debug, that's not gonna be a problem anyway, that's not code I read. If that can not only clean up the parser but also may improve speed I'm all for it - is variable declaration ugliness in compiled code an important factor ?
Code size does matter to JS files (for download speed, memory consumption etc.). Hopefully the increase will be negligible.
Unless you have a case like this one I don't think it adds much more bytes.
Long version is 623 chars long, short is 305 (and I think it's a rather controversial example since it tests bugs for these meaning many cases)