On Jan 12, 2012, at 1:43 PM, Matthias Reuter wrote: > 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.
Statements in javascript are terminated by newlines, except where it is ambiguous. If you omit to use semicolons **where semicolons are necessary**, thing will break, badly. But the rules of ASI are not so many/difficult to understand. So you can safely avoid using semicolons where not necessary, **if you like that coding style more** (i do). > >> - 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. if i read code like `if ( a = b )` i'm sure it is an error, because it is a nonsense. what about `if ( item = array.pop() )` ? Do you have to spend much time understanding that it is an assignment + boolean coercion? You can choose to be more or less explicit. Readability is subjective, ihmo. > >> - 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. They should learn javascript before writing in javascript. If i don't know very well language-x, before writing code in that language i ask for the supervision of an expert in that language, and i study the language better. >> - 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. D.C. deserves respect. But not everything he says is gold. I consider the bad parts of D.C. very bad. Good just for beginners. If you follow everything he says, you end up in using the 60% of a language that is not that rich in terms of features. > 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. The easier path is not necessarily the best one. > >> 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/jsmentors@jsmentors.com/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/jsmentors@googlegroups.com/ > > To unsubscribe from this group, send email to > jsmentors+unsubscr...@googlegroups.com > -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
