nicht angemeldet
Hallo,
Übrigens zur Erklärung: Ich stehe JSLint so kritisch gegenüber,
- weil ich JavaScript relativ gut kann und er mich mit den dämlichen starren Regeln hauptsächlich nervt, meine Produktivität einschränkt und mich zu schlechter lesbaren und wartbaren Code zwingt, anstatt mich auf wirkliche Fehler in meinem Code hinzuweisen. Siehe beispielsweise Type Coercion.
http://webreflection.blogspot.com/2010/10/javascript-coercion-demystified.html und dort die Antwort von "galambalazs":
"Art, style and the case of Real Programmers
While I think the technical content of this article is really valuable, I tend not to understand all the fuss about being hard on ourselves with coercion. I know it's all about Crockford and his recommendations.
There are several points of this argument which I want to highlight. First off, nobody forces you to use JSLint, and noone ever said that it's more than a person’s opinion. I think we have misunderstandings about the language on a much larger scale than slight differences of opinion about JSLint can ever come into play.
JSLint is not a syntax checker, it’s a Code Quality tool, and as such it evangelizes Crockford’s opinion on how one can write code that is more readable, maintainable and understandable to more people with less skill.
„Programs must be written for people to read, and only incidentally for machines to execute."
- Abelson & Sussman, SICP, preface to the first edition
When you do Software Development you should always aim at readable code, because we vary in skills, talents and attitude to a language so there has to be some kind of convention of what we use. It’s especially true for high level languages. I would also like to quote Crockford on this:
„The less we have to agree on, the more likely we can cooperate.”
Code Quality is all about these two things. There is hardly any situation where coercion is algorithmically indispensable. The ones you’ve mentioned like null and undefined are just a matter of taste. The key to understand is that the amount of time writing the code is
negligible compared to the time spent understanding other people’s code.
Excluding „bad parts”, „evil parts” is not about mystifying the language, or mystifying ourselves. Sometimes I feel people think of this question as if Crockford had thought „it’s not for the masses, these things can only be understood by me”. And here come the smart challengers who prove to understand deep things about the language.
Crockford has always been clear on this. He wants to keep the language simple to understand, simple to work with. This can be achieved by ignoring language constructs or style of programming that is error prone or hard to understand/debug.
04 December, 2010 15:53"
Gruß
jobo