nicht angemeldet
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 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.
- 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).
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. 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 () {}. Mittlerweile hat JSHint soviele Konfigurationsoptionen, da müsste ich mir erst ein Set zusammenstellen, damit ich meinen Code testen kann. Ich bin skeptisch, ob dann noch wirkliche Fehler oder Best-Practise-Warnungen gefunden werden.
Mathias