Hallo,

Der letzte Satz erklärt wohl alles.

Erklärt aber nicht, warum das inkonistent ist, oder?

[script lang=javascript]
var testFn = function () {
    var dom = (function () {
        var ready = function (e) {
            //do something
        };
        return {
            contentLoaded: function (e) {
                if (dom.isReady) {
                    return;
                }
                dom.isReady = true;
                ready(e);
            },
            isReady: false
        };
    }());
};
// 2 Fehler
var dom = (function () {
    var ready = function (e) {
        //do something
    };
    return {
        contentLoaded: function (e) {
            if (dom.isReady) {
                return;
            }
            dom.isReady = true;
            ready(e);
        },
        isReady: false
    };
}());
// Fehlerfrei
[/code]

aus http://tech.groups.yahoo.com/group/jslint_com/message/2021

Gruß

jobo

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:

There are some cases where it is troublesome to use a variable while it is
being initialized, such as

var x = x + 1;

Der Fall ist ziemlich konstruiert, wieso sollte man auf diese Idee kommen und was sollte man als Ergebnis erwarten?

Man kann schon in der Deklaration auf den Variablenwert zugreifen, er ist dann undefined. Es kommt natürlich NaN heraus, wenn man undefined + 1 rechnet. Okay, das ist Quatsch. Aber dieses Pattern ist eigentlich in Ordnung:

var foo = foo || [1,2,3];

Wenn schon eine Variable foo existiert, dann nimmt er diese, sofern der Wert truthy ist. Dann wird die Redeklaration ignoriert.

Andernfalls legt er eine Variable an. Dann hat wegen dem Hoisting von Variable Declarations die Variable auf jeden Fall den Wert undefined, also nimmt er [1,2,3].

Das Pattern ist zwar nicht so häufig, aber »troublesome« ist es nun nicht per se.

Mathias

Hallo,

Ich dachte eigentlich, das Programm verstehen zu wollen, als eine Paradebeispiel für JS-Programmierung und eines, dass sogar JSLint fehlerfrei passiert (http://forum.de.selfhtml.org/my/?t=204981&m=1389023).

Und was lernen wir daraus? Selbst Crockford schreibt guten und völlig fehlerfreien Code, der TROTZDEM nicht JSLint passiert.

q.e.d.

Aber JSLint passiert JSLint. Und JSLint wird wohl guter Code sein. Insofern gibt es auch guten Code, der JSLint passiert (;-).

Gruß

jobo

Hallo Mathias,

Die [Probleme] kann man im Bugtracker von JSHint nachlesen.

Immerhin aber von JSLint abgeleitet:

Ja, klar. Sonst hätte ich es in dem Kontext nicht erwähnt.

aber was ist der Bugtracker von JSHint?

https://github.com/jshint/jshint/issues

Übrigens zur Erklärung: Ich stehe JSLint so kritisch gegenüber,

• weil ich JavaScript relativ gut kann

weiß ich

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.

naja, das kann man sicher so oder so sehen (;-).

• weil ich viel CoffeeScript schreibe und damit ohnehin viele Fallstricke von JavaScript umgangen werden. Der generierte JS-Code ist m.W. auch JSLint-konform.

(;-)

• Viele verbleibende Fallstricke durch den ES5 Strict Mode abgedeckt werden, welchen ich für sämtlichen Code anschalte (und in entsprechenden Browsern teste).

ja, den habe ich bei Crockfords jslint zum ersten mal gesehen.

JSHint ist daher schon ein Schritt in die richtige Richtung. Allerdings habe ich das letztens ausprobiert und nur festgestellt, dass er (genauso wie JSLint) Function Expressions, Function Declarations und Hoisting nicht korrekt versteht.

Hoisting heißt (http://net.tutsplus.com/tutorials/javascript-ajax/quick-tip-javascript-hoisting-explained/), dass ich lieber die variable am Anfang deklariere, weil sonst murx passiert, s. Link. Was ja wieder JSLint-konform wäre.

Ich glaube, das ist mittlerweile zumindest teilweise gefixt. Allerdings weicht das natürlich auch die Crockfordschen Regeln auf. Der verbietet die Nutzung von Function Declarations und deren Hoisting einfach und propagiert immer Function Expressions à la var f; f = function () {}; anstatt function f () {}.

Letzteres ist ja auch nicht zu unterscheiden von einer named function expression, wie ich auf der von dir verlinkten seite las.

Ich kann schon verstehen, dass nicht jeder den Crockford-strict-mode mag. Ich verstehe aber durchaus, dass der Code dadurch nicht massiv schlechter wird. Vielleicht etwas anders. Einem Anfänger wie mir hilft das durchaus. Das Konstrukt

  
var myFun = function innerName() {  
    ...  
    if(notFinished) {  
         innerrName();  
    }  
    ...  
}  

ist mir erst durch JSLint aufgestoßen (natürlich kombiniert dann mit der Diskussion hier und u.U. bei der jslint_com.yahoogroup...).

Gruß Robert aka

jobo

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