Mike hat es dir sehr gut versucht zu erklären. Node ist kein Javascript, es nutzt nur Javascript. Große Teile eines Guides für Node betreffen nicht Javascript. Warum soll in einem JS-Guide etwas über Require stehen? Ich kann dich nicht zwingen dies zu akzeptieren, zumal du ja nicht mal den Argumenten (wie denen von Mike folgst). Unter argumentlose Kommmentare q.e.d zu schreiben macht die Sache etwas unsachlich. Die Bayernfan-Sache war ein Witz, kein belastbarer Vergleich.

Bitte habe Verständnis, dass ich den Titel nicht ändern möchte, nur weil ein Einzelner ihn für merkwürdig hält.

@Georf: Du hast meinen Einwand zumind. wahrgenommen. Es sollte keinen node coding style geben. Es ist JS. Punkt.

@Sebastian: Lese deine Aussage doch mal andersrum. Fans sind jetzt also keine Bayern-Fans? Ahh? Merkste was?
Wenn Fan = JavaScript und BayernFan = Node, dann ist JavaScript Style Guide auch … ?

q.e.d.

Du verzettelst dich doch nur noch. Node ist nicht Javascript, die Suchenden irren hier keineswegs und require ist kein Funktionsaufruf, sondern eine Funktion, die an verschiedenen Stellen mit unterschiedlichen Pfadangaben genutzt werden kann. Für eine konsistente Nutzung ist ein Style-Guide unerlässlich und in einen für JS gehört das schlichtweg nicht rein.

Syntax und Semantik sind zwei unterschiedliche Sachen, gehören aber beide in einen vollständigen Style-Guide. Und ob jemand einen unvollständigen Guide hat oder gar keinen und einfach nur schlampig programmiert lässt sich von außen wohl nur schwer erkennen.

Spezialisierungen sind eben „merkwürdig“. Sei froh, somit gibt es auch keine Bayernfans mehr. Das sind jetzt Fußballfans. Oder Sportfans? Oder Fans? Oder Menschen?

Nur weil viele danach suchen, ist es nicht richtig. Und wenn du dir die Antworten auf der von dir verlinkten Seite mal anschaust, siehst du, dass dort viele JavaScript im Allgemeinen sprechen …

Wieso sollte ein „Coding Style“ für JavaScript nicht für node.js funktionieren? Node IST JavaScript. require ist nur ein Funktionsaufruf … usw.

—

Natürlich hat das damit etwas zu tun. Deine ganzen anderen Punkte betreffen lediglich das „Layout“ des Codes, das Aussehen … wie gut der Code lesbar ist usw. Die unterschiedlichen Vergleichsoperatoren haben aber eine andere Semantik. Das ist von der Wertigkeit etwas ganz anderes …
Ob ich ein Semicolon am Zeilenende schreibe oder nicht verändert nicht die Bedeutung des Codes. == bzw. === schon.
Dein Beispiel ist ja richtig, aber es ist kein Beispiel für inkonsequente Nutzung eines Vergleichsoperators bzw. für inkonsequenten Style. Es ist ein Beispiel wo jemand schlampig programmiert hat und kein jshint über den Code hat laufen lassen..

Von Node-Coding-Style zu reden ist üblich, viele suchen danach. So wie ich. Deine andere Bemerkung verstehe ich nicht ganz: Ein Coding-Style ist etwas ganz anderes (oder besser: viel spezielleres) als einer für Javascript. Hier stellen sich viele zusätzliche Fragen (require, Verwendung von Modulen, Pfadangaben, DI…). Ich Suche nach einer speziellen Lösung, nicht nach einer allgemeinen.

Den Unterschied zwischen == und === habe ich als bekannt vorausgesetzt. Das hat auch nichts damit zu tun, ob man sie konsequent verwendet (siehe mein Beispiel).

Und zu kritisieren, dass die Vergleichsoperationen nicht konsequent einheitlich genutzt werden ist auch fraglich. Die beiden Operatoren == und === haben einfach eine unterschiedliche Bedeutung. Man kann deshalb nicht pauschal sagen, dass es inkonsequent ist beide zu Nutzen.

var x = 0;
x == ‚0‘ // true
x === ‚0‘ // false

Von Mozilla gab es kürzlich eine neue Version von asm.js, einer Teilmenge von Javascript. Das soll dann nach dem einmaligen Parsen circa die Hälfte der Perfocmance von nativem Code haben. Dafür muss man dann zum Beispiel Integer und Floats als solche Kennzeichnen. Da das JS-kompatibel bleiben soll, sieht das aber ziemlich doof aus:

Integer: var age = x|0;
Double: var size = +y;

Von Google gibt es Native Client, aber das hat glaube ich nichts mehr mit Javascript zu tun.

Wofür brauchst du denn mehr JS-Optimierung?