Em 04-07-2010 16:34, Paul Campbell escreveu:
Michael,
I recently read Crockford's book "The Good Parts" and I absolutely
share your opinions about bowing down to the master! That said, I
think that his arguments simply make a lot of sense more than anything
else, and it's useful to have a prescribed style at least to _start_
with, rather than picking and choosing at will.
Roderigo,
I've been hacking a bunch of javascript lately, and thought I'd reply
to some of your admirably empassioned comments!
Regarding Crockford code writing rules, I've heard about him but have never
been interested on reading his tips at all... I don't like the idea of
following some rules without understanding the reasoning. Since I never had
problem in organizing my js, I didn't find the need for looking for some
guides on this topic.
Crockford's rules are backed by pretty strong logic. I'd recommend
reading "The Good Parts" ... he has some compelling arguments.
I'll take a look when I have some free time.
My personal opinion on organization of js that we should have some
consistency. Unlike Rails, where I always feel I know where to put my
code, with js it often feels like I'm guessing.
For example, once you know the caveats of not using the semi-colons, I don't
see any problems in using that feature. Actually, I dislike using
semi-colons since the code is cleaner for my taste when not using
semi-colons, unless you have multiple statements in the same line. Yes this
can make sense, for instance:
One of the arguments for consistent semi-coloning is that in some
cases, non properly ended statements will break js minifier tools.
Given the huge surge in gzipping and minifying JS for performance, and
the hassle of trying to find the missing semi-colon, I've tended
toward including the little shits.
As I said, once you know the reasoning you can follow his suggestions.
It just happens that we don't use minifiers at our company since
Javascript is cacheable and there is no such "one-time users" thing with
our products. The overhead is also negligible for not using any JS
minifier. I mean, even if the JS code is reduced to 1/3 that would mean
just some hundred of KB that won't make any difference in our clients
and the content is cached after the first access. The client load is not
that big to justify server Internet band economy.
Anyway, you are always free to choose which minifier method to apply to
you code, so you can use a more conservative approach rather than an
aggressive one. Code readability is much more important in my opinion
than worrying about minifier tools, but each case needs particular
considerations. I also don't mind seeing the semicolons in the code, but
just don't bother to put them on code I write myself.
var r=[]; for (var i in ary) r.push(ary[i]*2)
I also don't like the idea of using some tool for formatting code. For
instance, the above code would be indented in Netbeans, probably as:
I think Michael was referring to JSLint (http://jslint.com/) ... it's
not a formatting tool, it's a _correctness_ tool, based on c++ lint,
from back in the day.
Yes, I know, I wasn't refering to JSLint when I wrote the above
statement. I just took the chance to comment on this subject too. I was
also a C++ developer a long time ago :)
var r=[];
for (var i in ary) {
r.push(ary[i]*2);
}
Some people may argument that this is much cleaner/better than it was. I
don't think so. Why? Because I think that some simple idea should read as a
single statement. 4 lines for doing that little job is too much for me. The
problem is that some scripts may have thousands of lines. If you waste space
like the code above, it becomes difficult to read other's code and get the
idea without having to scroll lots of pages to finish reading some function,
for instance.
I would argue that if you want to read this as a single statement, you
should abstract it into a function. For me, the overhead of parsing
out the single statement far exceeds the convenience of having it on a
single line.
Yes, this is really a matter of taste. It is trivial to me to parse this
single statement, just like reading an english sentence and I actually
need more time for parsing multiple lines. So this is no overhead to me.
But, unfortunately, we developers have different tastes for source
formatting :) This is a simple matter of coding style.
Another common code writing mistake I see on people's code:
function x() {
if (! exception_condition) {
// several lines of code
}
}
This is much better written as:
function x() {
if (exception_condition) return;
// same lines of code without unnecessary nested statements
}
Nice tip.
About defining all variables at the beggining of some function is not a
great thing at my opinion. It is much better to have a fluid source code
where you are only concerned about some variable when you are reading the
related code. Also, I always avoid declaring variables unnecessarily. That
is because there is no standard way for giving it a scope. For instance,
when you are reading code like this:
function x() {
var x = ... // something meaninful
// we are using the value of x here
// ...
// here follow several other lines where x is no more relevant
// how can the reader know that? He will be worried what else can be
affected if he refactors the above x related code.
}
I see assigning variables up top as something similar in concept to
attr_accessor in Ruby. ... I think if you keep functions short, than
the issue of relevance shouldn't really creep in.
The biggest problem of Javascript in my opinion is the lack of a
"require" statement. In Ruby, we usually write one or a few small
classes per file and they don't get big. Code is well organized in
different files. So, defining the attributes in the top is a good
practice. In Javascript, we can have thousand lines of code in a single
file unless we use some methods provided by some Javascript frameworks
for managing Javascript dependencies with multiple files in a consistent
way. jQuery still don't have such a feature and I don't like the idea of
mixing different JS frameworks, so I avoid this approach for now...
Being object oriented, we barely see big methods in Ruby. They are
usually split in various small methods. This is more difficult to
achieve in Javascript without compromising code readability. Thus,
functions tend to get big and declaring the variables in the top of each
function can make it more difficult to read the function's code.
Anyway, unlike object attributes, variables in Ruby are not explicitly
declared at all. So this would be the case in Javascript using the
approach I suggest, except that we must declare the variables otherwise
they would become global.
There are several situations where variable declarations are unnecessary.
For instance, using jQuery:
var el = $('<div/>')
var body = $('body')
body.append(el)
This could be written using no variable as:
$('<div/>').appendTo('body')
I think this is just an example of a smart refactoring.
Or even as:
$('<div/>').text('content').appendTo('body').click(function(){alert('clicked:
' + $(this).text())})
or
$('<div>content</div>').click(function(){alert('clicked: ' +
$(this).text())}).appendTo('body')
I usually use this approach whenever possible. I think it is much clear for
other developers trying to understand what the code does. When there is some
declared variable, you have no idea when and what it will be used for.
Also, I don't like to see 80 characters only page delimiter because most
screens nowaday are wide and have small height. This mean we should avoid
several lines of code in favor of lengthy lines. What I mean is that there
was some reasoning for using 80 characters delimiter in the past that is no
more valid nowadays. It is much better to get as much code as possible
without the need of scrolling, unless the code readability is affected,
which I don't think is the case in the above examples.
Here is where I disagree with you most. I don't think the 80 character
limit has anything to do with screen resolution.
Maybe it's because I don't really mind scrolling, but I'd much rather
scroll down than across, and I'd much rather read a number of short
statements down, than a long statement sideways.
Of course, there is a limit. I also don't like scrolling horizontally
(much worse than vertically). But I think 80 is too little for nowadays
standards.
I'm a huge fan of the jQuery style of chaining functions on new lines:
$('<div/>').text('content')
.appendTo('body')
.click(...)
This is exaclty the situation I hate because of the waste of screen space :)
I don't see any problems either with the ++ and -- operators, but of course
someone should understand how they work. And Javascript should be tested as
well, the language is not an exception. There are good frameworks for that,
as Selenium, for instance. So, why avoid the great features of the language?
These operators works exactly the same way as C, C++ and Java...
Javascript has some great unit testing frameworks too.
Sure, we have no excuse at all, have we? ;)
Well, actually I was wondering writing some post about this topic on my
site, but ended up never writing about it. Maybe, now that I have already
written part of the content in this email, I can put this on my site :) I
always wanted to write about this for some years now whenever I have to read
other's code in my company :)
Here I have only given JS examples, but there are other subjects in other
languages as well I would like to cover...
Sorry for the post-in-email-shape :) Too long for an e-mail, probably, but
please don't blame me. You have inspired me with this subject ;)
Very cool discussion to be having.
Yes, thank you for the comments! :)
Best regards,
Rodrigo.
—P
Thanks for reading until here, :)
Regards,
Rodrigo.
Em 04-07-2010 09:09, [email protected] escreveu:
Hi,
Yes, automatic semi. insertion is a feature - and a most horrible one!
I am unwilling to discuss it though: I must admit I completely and
uncritically submit to "higher authority" and Javascript-god Douglas
Crockford as far as code writing rules are concerned, since as far as
I'm concerned that guys simply is GOOD, or at least so much better
than ANY other voices I have heard so far (where Javascript is
concerned). I *highly* recommend the Crockford-videos on Yahoo's
developer theater for anyone writing Javascript. Okay, "uncritically"
is not quite right, to me his statements simply make sense. The only
exception I occasionally take is usage of the ++/-- operators,
although I limit myself to using them in the head of for-loops only.
When listening to Crockford one must not forget of course that his
advice is especially targeted at developers of mashup-able enterprise
large(r)-scale JS apps where *teams* rather than individuals have to
work with the code for a long time again and again, and not so much
for handfuls-of-lines-of-code for "beautifying" HTML pages.
However, since Rails is a framework IMHO those high and very strict
coding standards should apply to its JS code.
Yes, I'm willing to contribute and not just complain and I'll try to
do so - time permitting, which right now is a little scarce (I'm a
week behind schedule in a JS project and also just opened a restaurant
in Nuremberg, Germany, with an Italian cook/friend :-) ).
About redeclared variables:
1) see function handleMethod, variable field.
2) Further down in event handler document.on("submit",...) variable
"element" is declared twice.
Crockford gives a compelling case for putting all var-statements into
the TOP of the function instead of declaring them as they are used. I
forgot was the argument was, but it was very compelling. Crockford is
strong both in theory (computer science: programming languages) as
well as in practice. I may sound odd to freely admit I forgot the
argument and not to care, but I don't care - if you listen to the
Crockford videos you'll understand :-) Seriously, I'm not nearly as
good as this guy and since his videos are publicly available why
should I try to repeat his statements, which is all I can do?
Thanks for the github pointers to the prototype and jquery components,
I wasn't aware of them but only of the code bundled with rails
directly. Contributing to the Guides is on my TODO list... I wasn't so
much calling for other people's action but was/am much more interested
in finding background info - such as those github links. One usually
assumes much more intention than there is when one doesn't know all
the things that are NOT going on ;-)
Michael
On Jul 2, 1:31 pm, Rodrigo Rosenfeld Rosas<[email protected]> wrote:
Michael, please take a look at ECMAScript specification, section 7.9 -
"Automatic Semicolon Insertion":
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262...
This is not an error but a feature. The only case where this could lead
to some problem is code like this:
var l = variable.length
(function(){alert('a')})()
In this case, if we miss the semicolon, this would be interpreted as:
var l = variable.length(function(){alert('a')})()
You get the point. But this is only to mention that it is ok to not put
the semicolons at the end of the line. I barely put them when writing
Javascript...
About repeated variable names, I didn't find any case. Could you point
me one? Remember that you can define the same variable multiple times in
different scopes, such as functions. This is no problem.
But I'll take the chance to discuss another issue I've just opened
yesterday on Github:
http://github.com/rails/jquery-ujs/issues#issue/11
It would be great if the jQuery driver supported including the CSRF
token in all AJAX post calls, such as "$.load(url, {data: sample})".
What do you think?
Rodrigo.
--
You received this message because you are subscribed to the Google Groups "Ruby on
Rails: Core" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
