Best Practices Exist for a Reason
by Tom Dale
If you’ve ever used node.js, you’ve probably also used Isaac Schlueter’s npm, the node package manager. By maintaining a central repository to which authors can quickly publish their JavaScript modules, npm has made it easy to get started building node apps and its popularity has exploded over the past year. Unfortunately, two months ago, the hashed passwords of all npm accounts were leaked. npm uses CouchDB for its backend, and the default security model is to grant administrator access to all databases, but only when connections originate from the same machine. It appears that in this case, the CouchDB server was made accessible to the world over HTTP with the default access settings left in place.
In retrospect, it’s obviously a dumb mistake, but the same kind of dumb mistake you or I or anyone ten times smarter than us could make; whether because we’re sick or tired or under pressure or simply because we’re using a new system that we’ve never used before.
The community’s reaction to the security leak was relatively forgiving, and rightly so. After all, npm is a community project that was created and is maintained for free, and we all benefit from the enormous amount of time and energy that Isaac and the other npm contributors have generously donated.
And yet, npm is no longer just a hobby project. Thousands of people rely on it to provide services to themselves, their friends, and to paying customers. Additionally, when it comes to security, there can be repercussions far beyond the original breach. Anyone who created an npm account and used the same password for another web service is potentially at risk.
So this is the eternal balancing act that open source maintainers (and, indeed, many startups) must face: limited time and resources for building, securing and maintaining systems that will be used by hundreds, thousands, or even millions of people.
Which is why I have been so saddened and, yes, angry, about the recent trend in the JavaScript community; to throw away the best practices we have spent a long time honing in what, to my eyes, is an act of machismo; a revolt against good engineering practices for the sake of revolting rather than to make the world a better place.
As a community we’ve advocated for these things precisely because most comers to JavaScript are not us, not as invested in the language and the ecosystem as us; but rather have been thrown at some problem because all of a sudden it’s 2012 and not writing JavaScript is no longer an option. They are not JavaScript developers per se; they are Java developers or Ruby developers or .NET developers or any of the thousands of possible kinds of developers who are now thrust into this unfamiliar world where JavaScript is the substrate that holds the web together.
Here’s the thing about best practices: at the point at which you become sufficiently experienced, you understand why they are good and so can choose to not use them as the situation allows. Your understanding of the language or the ecosystem or the particular problem at hand has allowed you to view the problem from the same vantage point of the people that came up with those best practices; and so you are free to discard them if the situation merits.
But until your understanding has crystallized, not following those best practices can cost you hours of wasted time tracking down bugs that didn’t have to otherwise exist. But writing code before you have an expert-level understanding is okay. It’s okay because it is reality and there is nothing you can do to change the fact that people with a very tenuous grasp of these technologies are being thrown at hard problems that they will solve one way or another.
Which is why I have to admit that my blood boiled when I read Isaac’s post about automatic semicolon insertion. I don’t want to re-litigate the semicolon debate because I think we were all tired of it before it even began. What I want to highlight is a general attitude that I find very disappointing:
I am sorry that, instead of educating you, the leaders in this language community have given you lies and fear.
By couching it in these terms, it implies that anyone who follows best practices has given in to “lies and fear!” Who wants to be swayed by that?
A more generous interpretation is that the leaders Isaac accuses of spreading lies and fear know that the reality is that you have a month to ship a JavaScript app, and asking you to understand the ECMAScript spec is not reasonable. (Because it’s not just automatic semicolon insertion, right? It’s this binding and anonymous functions and a million other features of JavaScript that confuse newcomers.)
We can’t front-load complexity and let people sort it out. That way lies madness. We must distill the rules down so that people can be effective, and help them along their journey towards JavaScript mastery. It’s a learning curve, not a learning cliff.
So I have to vehemently disagree with this statement in Isaac’s post:
If you don’t understand how statements in JavaScript are terminated, then you just don’t know JavaScript very well, and shouldn’t write JavaScript programs professionally without supervision…
I find this staggeringly condescending, but maybe it’s just my reading of it. But even if my reading is wrong, it rejects reality. Isaac knows this because the npm team deployed a misconfigured CouchDB instance to production and it’s not their fault. To suggest they needed “supervision” is absurd. They were not expert-level CouchDB users but they had a job to do so they picked the tool and went to town. This is a CouchDB failing; because the best practices were not made clear enough or the default settings were not strict enough.
So let’s learn from our mistakes and realize that the bulk of JavaScript developers are not experts. Let’s stop tearing down the hard work our predecessors have done to shepherd JavaScript from a toy language to the language that is revolutionizing how the web applications are built. Let’s embrace good engineering practices and have the sense to know when to ignore them, and not abandon them altogether to prove how smart we are. We’re all in this together.
The thing that makes me laugh about his post is that he shows an example where he places a semicolon in FRONT of a statement rather than before after the previous one.
So you can’t be bothered to put one where it “belongs” but you can put one at the beginning of a statement?
It just comes down to ambiguity. Take ColdFusion for example…it has 9 potential scopes in which it can store variables. The documentation is clear on the order in which the server will look for a variable if you do not prepend it with a scope.
ARGUMENTS.foo URL.foo etc.
If you don’t specify a scope then the server has to go looking for the variable, potentially through 9 different areas, and potentially getting the incorrect variable along the way. But if you’re simply explicit in your scoping you save time and possible error.
I see the semicolon argument like that. Yes, JavaScript has the ASI rules, just like ColdFusion has rules about scoping. But why not just be explicit and save the engine time and energy?
Thanks for taking the time to write this post. The phrase “best practices” grates on me a bit, but the reality is that anything the community can do to lower the barrier of entry for “non-JavaScript per se” developers is a Good Thing™.
Condescensions that claim newcomers should have to learn or do things the hard way is just going to turn people away from the community, encouraging them to keep writing ad hoc, unconventional JavaScript.
While the reason you give for always terminating statements with semicolons is a good one, there is another reason. That other reason is arguably more important because it affects everybody rather than just those unfortunate enough to have to read tricksy code.
A widely deployed library that depends on semicolon insertion in this way might break the proposed use of ! as an eventual-send operator. It makes me sad that a genuinely significant syntax innovation like that might get blocked by a backwards step like omission of semicolons in JavaScript. Syntax really does matter. But the battle to get statement termination right was lost years ago in the glorious Netscape muddle. The existence of the proposed ECMAScript eventual-send extension demonstrates that that battle really was lost — rather than being lost only for “people who shouldn’t write JavaScript without supervision”. Perhaps if the eventual-send operator does not happen, people will end up using inferior concurrency mechanisms to the one outlined in the ! proposal. That makes me suspect that the net contribution of twitter bootstrap to the world will be negative, which is also sad.
http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
Just to be clear(er): I’m a full-time long-serving Pythonista who believes that semicolons are the spawn of the devil. But that is less important than having a good and popular concurrency mechanism.
The issue with best-practice is a community one. Sure best practice guidelines (not rules) can exist, and they may be helpful for many novices, but the flipside is that people seem to forget that these guidelines can and should be excepted for advanced users, until you end up with literally “eval=evil” (2 legs bad, 4 legs good anyone?).
There are a few points where I think you’ve misunderstood me.
First of all, “supervision” is not intended to be derogatory. I just mean you ought to check your work with someone else, preferably someone with more experience than you have.
The concept of a “statement” is actually a pretty core concept in JavaScript, and not a particularly difficult one to master. I explain it fully in that blog post. That’s why it boggles my mind that so many self-proclaimed JavaScript experts seem perfectly content to teach the intricacies of this-binding and prototypes, and yet when it comes to statement termination, they clam up, claim it’s too hard for newcomers, and insist on solving this problem by imposing C style and pretending that white space isn’t significant (even though it still is, and still bites in restricted productions!)
Second, I don’t think that I ought to use CouchDB without supervision. That’s why it’s hosted on IrisCouch, and Jason Smith, who is a CouchDB committer, helps maintain it. He helped a lot to get the required features into CouchDB to enable the security we now enjoy. I have a lot of supervision in that area. Actually, I even make sure that my JavaScript commits to Node.js are reviewed by other committers, because supervision is a great thing. Experts are human, too.
As far as my condescending attitude regarding semicolons and JavaScript leaders: if a person can’t be bothered to learn the language, then they’re not an expert, and should not be in the habit of dispensing advice. That’s not to say they’re not welcome, or shouldn’t experiment, or can’t write useful programs, of course. They can even write very interesting and useful programs, and release them into production. Just don’t spread falsehoods, that’s all.
Here’s a few best practices: Have some rough idea of what you know, and don’t claim to know more than that. When in unfamiliar territory, do your best to learn, test assumptions, seek help, and be humble.
I have absolutely zero sympathy for the feelings of anyone who lies to newcomers, or pretends to be a JavaScript expert when he doesn’t actually know what a statement is. It’s not a hard language to master. But it’s much harder to master than it ought to be, in large part because of patently false information being dispensed by negligent teachers.
THIS is one of the worst problems in JavaScript. Not that a few random heretics like me don’t follow Best Practices, but that the Best Practices are being set by people who refuse to preach the truth about the practice. There is no justification for willfully lying; either they are lying about semicolons, or they’re lying about being experts. I’m not sure which is worse.
I don’t know fellas…
If the browser’s choices are: 1. Force feed your code missing syntax 2. FAIL
Then I believe you owe us a better explanation than, “It’s a matter of personal preference.”
Why not just use CoffeeScript at that point?
Then you can dispense with both semi-colons and braces. In return, you gain high fidelity and reliable JavaScript.
Reference: https://github.com/isaacs/npm/blob/master/lib/npm.js
I whole-heartedly agree with you, Tom. The fact of the matter is, there are a lot of people using JavaScript to solve problems without having a good understanding of the language. This isn’t a problem unique to JavaScript, it’s true for all programming languages: the majority of the developers qualify as beginner- or intermediate-level developers. There are very few who understand the intricacies of the language in which they work. Most developers are just looking for the quickest solution to the given problem so they can move on and meet their deadlines.
Best practices exist not for the senior- and expert-level developers of the world. They exist for everyone else, to benefit from the experience of those who came before them so they can achieve their goals faster and without hitting major snags. Let’s face it, most developers don’t want or need a deep understanding of the language. They just need to get their job done, that’s it.
I support the use of semicolons and will continue to recommend to anyone who listens that they be used. This isn’t a matter of preference, it’s a matter of seeing too many errors over the years caused by misunderstanding line termination and automatic semicolon insertion over the years.
The truth is, it is easier to explain semicolon usage than it is to explain ASI. In all of my years of teaching and talking about JavaScript, I’ve never had one person express disappointment that I didn’t spend time on ASI. In the best case, no one needs to worry about it, in the worst case they figure out that adding a semicolon solves the problem.
“They can even write very interesting and useful programs, and release them into production. Just don’t spread falsehoods, that’s all.”
Amen to this. I also don’t interpret the original remark as condescending, but rather as an overdue truth.
The real issue is that there is a huge chunk of the web industry that is entirely self-taught from crappy second hand tutorials. How many CSS designers have actually read the spec and understand the cascade? How many programmers whine about CSS “making no sense” without having done the same?
JavaScript is in the same boat. The language got its reputation not from its own merits or defects, but from an entire generation coding in it without a decent background or understanding. It’s high time we called everyone out on this.
With regard to the semicolon debate you are loathe to rehash: I think the material of the debate is that one part of the community seems to think it can dictate its own best practices to individuals who clearly don’t subscribe to them. I put semi-colons in. If I didn’t, I would be pretty mad if somebody told me I had to. The fact is, I put semicolons in because I like to, sometimes restack code on one line, and because it reduces syntax errors in my PHP because I forget them in the PHP less-often when I put them in the Javascript. If you object to the invective, just consider that the author is hurt by the community, and, while, admittedly, responding emotionally, failing to validate those emotions is destructive to the community.
It seems a lot of people are missing the point of Isaacs post.
The idea is not “always use semicolons” or “never use semicolons”.
The idea is also not to insult anyone.
The idea is “if you are in a position to recommend practices to another person, then do so without falsehoods”. It’s that simple.
For example, the whole thing that brought up the debate is people recommending a practice (e.g. semicolon usage – or the lack thereof) while providing misinformation from misunderstanding, naivety, ignorance or bias.
Sure it is perfectly okay to be naive as a new programmer, it is to be expected. No one is arguing against that. Sure new programmers will make mistakes. No one is arguing against that.
But, if you are to provide advice to someone, then that places you with a certain responsibility, a responsibility to always ensure that what you are preaching is factually correct.
A violation of this was Isaacs example of “Always use semicolons as ASI is unreliable.” which he proves, with evidence, is bullshit.
Whereas if it were rephrased to something like “Writing ASI code requires an understanding of javascript statements. This understanding is not apparent in a lot of beginners, as such requiring the use of semicolons can be considered safest. However, if your contributors do understand (or are willing to learn) javascript statements, then practicing semicolon omission can to be equally rewarding. However, there is no absolute best way, the best way is dependent on your project. Pick what you feel is right for your project. If you are unsure, then you can read up some more about requiring semicolons here, or omitting semicolons here. Thanks.”
Which is not what a lot of people who provide advice do. In order to improve the world, misinformation (what isaacs referred to as lies and fear) needs to be addressed, and using the suggestion of only providing educated advice backed by facts and always allowing the option of choice, is the proposed way to help that.
Ben,
Actually, in the article cited, I mention a few great reasons to terminate every statement with semicolons. One was consistency with other C-style and sh-style languages (such as PHP and Java). When I was writing a lot of PHP, I even experimented with putting $ in front of JS variables for a similar reason, and it’s just as harmless (and at times helpful) as excessive semicolons. Other great reasons for excessive semicolons include politics, aesthetics, and tooling.
Less valid reasons include appeasement of the Easter Bunny, safety from ASI attacks, and terrorists.
Whatever you do, do it for and because of and in pursuit of Truth. That transcends code style. It’s a life Best Practice.
Nicholas,
“There are very few who understand the intricacies of the language in which they work.”
I would not call “what is a statement” an intricacy. It’s a hello-world-level principle. If you learn any other language, it’s usually among the first subjects covered. It was literally the first thing taught on my first day of C class in college.
Also, that’s bullshit. Anyone calling themselves a JavaScript professional who hasn’t ever cracked the ES spec is a fraud. No other serious language community would allow such irresponsibility, and it gives our entire craft a bad name.
“I support the use of semicolons and will continue to recommend to anyone who listens that they be used.”
I encourage the use of semicolons to prefix statements which would otherwise continue the line above (eg, statements beginning in ( or [), in for(;;) loops, empty blocks, and whenever multiple statements appear on the same line.
No one that I’m aware of honestly suggests that semicolons should never be used. In fact, in npm-style, the prefixing ; is required even when not strictly necessary, so that moving code around doesn’t change semantics of the line above. The goal is ergonomic error reduction.
“In all of my years of teaching and talking about JavaScript, I’ve never had one person express disappointment that I didn’t spend time on ASI.”
Haha! Of course they didn’t. How would they know that there was such a thing to express disappointment about, if you didn’t cover it?
Again, just to be clear, I’m not saying that people shouldn’t use semicolons. I’m just saying that they shouldn’t lie about them, and shouldn’t claim to be JavaScript experts if they don’t know what a JavaScript statement is.
“If you object to the invective, just consider that the author is hurt by the community, and, while, admittedly, responding emotionally, failing to validate those emotions is destructive to the community.”
In my experience, the opposite is true. Validating every single emotional argument regardless of merit results in your community taking themselves too seriously, and giving the whiny people importance over the smart ones. Sometimes you need someone at the top to just say: “This is not a real argument. End of story.”
I don’t, by all means, think of me as a javascript expert, but I have shipped quite a good amount of it to production. I even have an npm package, featured in javascript weekly.
I do not understand ASI.
And I don’t want to.
Why? Well I guess that, facing a new javascript problem I can either:
1) Use semicolons, stop thinking about it and get shit done.
2) Spend time reading about line termination, ASI, etc. Then spend time explaining anyone that has to review/read my code about it. And, eventually, get shit done.
So far, I always find myself choosing option 1.
Feel free to call me amateur. I don’t mind at all.
As you mention, javascript lies at the intersection of myriad developer communities, so even the term “best practices” means very different things depending on who you ask. For example, for the unixy among us, we take the idea of single responsibility very seriously, which can lead to a fear of some of the behemoth frameworks. For the ruby developers, we believe that code should be fun to write and want to minimize syntactic sugar, so we might use a preprocessor (coffeescript). And then you get the choice of whether to interact with js in an OO, functional, or evented manner (yes, we do all of these constantly, but I’m thinking about the developer mindset which influences design decisions).
The fact that javascript is such a playground for these best-practices is what makes it an interesting community.
The attitude you address here, to revolt in a manner which does not ensure greater good, is all too prevalent today.
Innovation is a risky game, which is why you do it 10% of the time, and not 100%.
Andy Matthews wrote:
“”"The thing that makes me laugh about his post is that he shows an example where he places a semicolon in FRONT of a statement rather than before after the previous one.
So you can’t be bothered to put one where it “belongs” but you can put one at the beginning of a statement? “”"
Believe it or not this is a practice dating back to the punched card, making list items in your deck somewhat easier to delete without wasting cards. Or some such, maybe I have misunderstood your description of the technique.
Tom, can’t agree more on this post.
The ASI issue is getting more and more funny now..even the language CREATOR told people not to rely on ASI, and people are still debating..how stubborn it is?
Btw, would be interesting if you can get Yehuda to say something on this…
“Also, that’s bullshit. Anyone calling themselves a JavaScript professional who hasn’t ever cracked the ES spec is a fraud. No other serious language community would allow such irresponsibility, and it gives our entire craft a bad name.”
JavaScript is in a fairly unique position where many developers that don’t self identify as “JavaScript professionals” find themselves needing to write JavaScript.
HTML and CSS occupy a similar position, because many times, a dev needs through modify front-end code someone else made, or needs to throw up something quick.
Sure, I would expect any developer who calls themselves a JavaScript developer to have read the spec. Especially people who may be writing JavaScript for node.js.
But the fact remains that there are many devs who are required due to circumstances to modify/write front-end code — including JavaScript, CSS, HTML — without having the time to read a spec or gain a thorough understanding.
Chances are everyone reading this knows someone who has done it, or has done it before.
I have been writing JavaScript for 16 years, and I have never been bitten by white-space in a restricted production. I use semicolons after every line, because it’s a C-like language, and that is the best practice. Why would you do anything else? Anything else simply comes from a prideful, stubborn, rebellious attitude. Yes, I appreciate beauty in code. Which is why I like CoffeeScript. ASI is not beautiful. It was a bad idea—as can be seen by the amount of confusion and controversy it causes.
@Isaac Z. Schlueter
First of all, “supervision” is not intended to be derogatory. I just mean you ought to check your work with someone else, preferably someone with more experience than you have.
Yes it was intended to be derogatory –and you even admitted to that saying “this is the part where I insult you”.
The concept of a “statement” is actually a pretty core concept in JavaScript, and not a particularly difficult one to master.
The concept of best practices is even simpler.
As far as my condescending attitude regarding semicolons and JavaScript leaders: if a person can’t be bothered to learn the language, then they’re not an expert, and should not be in the habit of dispensing advice.
On the other hand, Brendan Eich and Douglas Cockford both agree that ASI is a bad thing, and they have far more expertise in the language than you have. So maybe it’s you that didn’t bother to learn the language and who shouldn’t dispense advice.
It’s like some idiot abusing some C side effect that even it’s inventors abhor and arguing with Thompson and Kernighan that he is correct because compilers understand it just fine.
I have absolutely zero sympathy for the feelings of anyone who lies to newcomers, or pretends to be a JavaScript expert when he doesn’t actually know what a statement is.
It’s you who doesn’t know what ASI is. ASI is not a syntax feature, it’s a ERROR correction feature. Eich:
The moral of this story: ASI is (formally speaking) a syntactic error correction procedure. If you start to code as if it were a universal significant-newline rule, you will get into trouble.
@foljs
Thanks for summing up a proper response to Isaac.
I read the Isaac article, and my thoughts were essentially that here is an idiot that is guarding his walled garden, after the walls have long ago crumbled.
To me, best practices should conform to good code that is easy and unambiguous, at least due to formatting. CoffeeScript is actually a horrible deviation. I would much rather have semi-colons than forced significant whitespace. But that is an entirely separate issue, and worthy of a blog in and of itself.
Vote up for semicolons. Code is being created not for machines, but for humans. The code should be written in the style that won’t disappoint the reader.
Another reason for using semicolons (for me) in additional benefits, such as semicov test coverage tool, which uses semicolons in code to be able to mark “covered” lines in code.
If people are going to argue for not using semi-colons then I say we should start arguing to drop other best practices like using eval() more frequently or omitting var statements.
I mean why not? Wouldn’t all the same arguments apply?
When I began to read this post, I thought it was written in a reasonable, considered, and non-offensive tone. So what happened in the comment stream? All this “idiot” name calling is off-putting and immature. That’s not name calling. I believe anyone reading a blog post like this is an intelligent human being worthy of respect. Yet none of us is perfect, and we all can and do fall short of the mark from time to time. So let’s keep the conversation going with a more constructive and respectful tone.
@Isaac:
“it boggles my mind that so many self-proclaimed JavaScript experts seem perfectly content to teach the intricacies of this-binding and prototypes, and yet when it comes to statement termination, they clam up, claim it’s too hard for newcomers.”
I don’t know that it’s really too hard for newcomers so much, and if that’s the genuine claim, it’s certainly suspect. But I think the argument might instead be that for the most part, it’s very easy to state that by and large when writing JS you’re free to ignore whitespace and assume statements are terminated semi-colon, and then move onto more interesting things. It’s not entirely true, and in particular I’d warn a newbie about some dangers that can happen with common idioms involving
return, but you can more or less take it as true and go for years (with or without supervision) without encountering an edge case.By contrast, the other areas you mentioned involving this binding and prototypes are necessary to study if you’re going to use the object-oriented features of JavaScript at all.
It’s pretty easy to see why the emphasis might fall on one and not the other.
True engineer respect the language, and its best practices. It is very simple to us: Use semicolon in JS. If it bothers that much then do CoffeeScript.
IMHO there are three types of people on this topic: language maintainers, celebrities, and engineers. Most people are engineers who follow best practices.
It’s rare to see a post about someone else’s mistake being written in such a considerate manner.
The culture of Ego and Superiority is a little out of control with so many wanting to appear by way of making others appear less.
We all started out not knowing how things work, and as technology progresses we continually find ourselves in unfamiliar territory. Why not, as you say, work toward making it clearer and safer for those beginning instead of insisting on perfection from the start?
Am I the only one who noticed that this blog about “best practices” is so skinny it only takes up 25% on my monitor?
If you do not teach the rules of ASI, that means your student will have a nightmarish time debugging the extremely confusing error that happens as a result. At least if you understand the problem, you have a chance in hell of thinking about it when you hit it, and if you do enough javascript you WILL hit a point where you have to debug it.
For those who claim NPM style is about ego, it is not. It is about recognizing that there is a easy to make and hard to detect problem in the language with regards to semi colons and commas, and is designed to make that problem hard to make and easy to detect. If you use NPM style, chances are you will not ever be bitten by semicolon or comma issues. If you don’t use NPM style, chances are you will. The cost of NPM style is learning. That is pretty much all there is to say on the matter.
Lastly, it is strange that nobody seems to care about comma first, but everyone freaks out over semicolon first. That leads me to think that the majority of people complaining a) do not fully understand what they are railing against, and b) are taking the words of brandon eich (who says that npm seems to work really well for good devs, just isn’t a good idea for newbies) and doug crockford (who also recommends never using the “new” keyword) rather then using their own minds.
At the end of the day, if you want to use semis, thats fine, I don’t care as long as you understand the choice you are making. Just don’t call me a hipster for taking extra measures to avoid two of the nastier pitfalls of the language.
This Isaac guy is the funniest thing I’ve come across since FSJ. FUD is good, if it stops people from writing stupid code until they get up to speed with a new language. More importantly, swinging your dick does not make you an expert, nor does knowledge of syntax. Unless you think that ‘the interpreter doesn’t puke’ is equivalent to good code. There is nothing in his offensive diatribe that actual suggests expertise beyond having actually read the specification. Being a condescending asshole is not negated by saying ‘I’m not being a condescending asshole’ however often you say it.
Snark,
Just because you read what Issac wrote as condescending does not mean Issac was feeling condescending when he wrote it. It is more difficult to reflect ones mental state when one writes English than it is to write JavaScript. For one thing, neither English nor our mental states have a readable spec.
Yours, Tom
The baser concept of best practices can be appreciated, however, the implementation is a farce. The idea of making the code’s concepts and implementation accesible to the maintainer is commendable but what best practices has evolved into bullying based on punctuation.
Can we please pick another name? Perhaps, “Generally Recommended Practices”, or “Generally Accepted Practices”, or something. Using the word “Best” implies there are no better practices… we might as well just stop trying to improve the craft, because we already discovered the best.
I come from the Perl community which has gone through its own evolution over the last 20 years about best practices.
Those in the non-semicolon camp seem to feel that if you don’t understand a language, you shouldn’t be using it. That’s just doesn’t work in the real world. I have to track down bugs in Python, Ruby, Perl, JavaScript, PowerShell, and several other languages. I have to fix CSS issues. In some of those languages, I know the deep dark secrets and incantations. In others, I am a competent developer, but I don’t understand the underlying implementation. And in the last group, I’m just trying to hack my way through code and syntax. Yet, when a problem occurs, my company depends upon me to find the problem and fix it.
My main concern is readability and maintenance. It’s nice you can write some hot code that experts like you can wow over. However, three months from now, a junior level programmer will have to make changes to your code and fix the issues that arise.
There’s a difference between doing advanced coding and using a semantic trick that few people who actually use the language understand. I expect an expert in a language to write code that’s efficient, checks for various issues, AND is easy for others who have to maintain it to understand.
The question isn’t whether semicolons are necessary or not. The question is what are you doing by eliminating semicolons. Are you writing a more efficient program? Is your program more easily understood? Will the lack of semicolons improve maintenance? Or are you just making the statement “I am an expert JavaScript programmer and you’re not!”
You are absolutely right. In it something is and it is excellent idea. I support you. . http://cheap-viagra-generic.com/#6523 – buy cheap viagra. to watch this cheap viagra 50 mg .