gamera wrote:
On Jan 12, 2012, at 12:49 PM, Matthias Reuter wrote:
Guidelines are opinionated by design.
Those two in particular spread FUD.
Actually, I find both quite useful. Could you elaborate on what parts
are "FUD" and why?
just to name few:
- avoid ASI. why? better to understand how it works.
My main objective with codestyle is to avoid confusions wherever it is
possible. If I insert semicolons everytime, nothing can go wrong. If I
omit one, things can break. So I insert them and leave the removal of
optional semicolons to tools like closure compiler.
- avoid assignment in conditionals. why? because of the fear that a
developer can be confused?
Yes, exactly for that reason. If you read code like if (a = b) you have to
think twice (at least) if that was really meant to be if (a == b) or not.
Again, readability is the main objective.
- avoid comma operator. why? same as above.
- use always ===. why? and if i need coercion or to trigger valueOf?
I have worked in a team of developers with all (but me) a java background.
They always used == and never ===. When refactoring a part where ==
occurs, it is very difficult to find out whether an implicit coercion was
intended (and thus needed somewhere) or not. Therefore I always use ===
and if I want coercion, I either do it explicit (e.g. Number(foo)) or
write a comment.
- avoid ++/--. why? very useful unary operators.
- avoid bitwise operators. why? because js doesn't have integers, hence
they are slow? not true any more, since js engines optimize the code.
and i find bitwise math very powerful.
- … and so on...
Those guidelines are one by Google, and one by D.C. When you write code
that has to go in Google's codebase or in D.C.'s codebase, you
should/must follow their guidelines.
But the same cannot be considered universally valid. If you like them,
follow them. I don't like them and i use different guidelines for my
codebase. When someone will have to contribute to my code, they will
have to follow my guidelines.
I completely agree. Follow the guidelines. And feel free to argue over
rules which seem futile.
My advice is to study and understand how things works, instead of
following what "guru" says. It is about expressiveness.
I have made the experience that with Douglas Crockford it is like this: I
say "WTF?" and a year later I say "He was right". So I tend to follow that
guru, even though I might not (yet) fully understand the benefits.
It's a good thing to study and understand. Yet we cannot expect it from
everyone else. In my current project, we have four frontend developers. We
could need ten. We cannot fire "bad" developers who know too little and
refuse to study. Thus, we have to force them to follow the guidelines.
Since most of them can be checked by tools (JSLint for example), this is
the easier path.
If you fear that a future developer (or a future you) can be confused by
your code, just use comments to explain how your code works.
That is always a good idea.
Matt
--
Follow me on twitter.com/gweax
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
