Node-Coding-Style: Vergleich zwischen Node FS und NPM

Noch immer führt die Suche nach einem Coding-Style für Node.js ins Leere. Da man sich für ein gleichmäßiges Code-Bild auch ohne offizielle Vorgabe Richtlinien schaffen muss, habe ich hier einen Vergleich zweier wesentlicher Module vorgenommen: Nodes integriertes FS und das unangefochtene Paketwerkzeug NPM.

Ich betrachte für mich derzeit relevante Punkte, wie etwa:

  • Einrückung
  • if-Statements
  • Stringausdrücke
  • Variablendeklaration
  • Semikolons

Mein Fazit: Den einen Node-Coding-Style gibt es nicht. Selbst die beiden Kernmodule weisen elementare Unterschiede auf. Den eigenen Stil muss man sich nach wie vor selbst zusammensuchen.

Eine Alternative: In Coffeescript ist der Code-Style Teil der Syntax, was konsistenten Code begünstigt.

Gemeinsamkeiten

Code-Einrückung

Zwei Leerzeichen:

Node FS

function read() {
  if (size === 0) {
    buffer = new Buffer(8192);
    fs.read(fd, buffer, 0, 8192, -1, afterRead);
  } else {
    fs.read(fd, buffer, pos, size - pos, -1, afterRead);
  }
}

Einzeilige If-Bedingungen

Meist einzeilig, aber nicht konsequent. In Verbindung mit else immer geklammert und mehrzeilig.

Node FS

if (er) return callback(er);
if (bytesRead === 0) {
  return close();
}

Argumentlisten

Keine Leerzeichen zwischen Klammer und Argument, Argumente durch Komma und Leerzeichen getrennt:

NPM

cb(null, made)

Strict-Mode

Keines der beiden Module verwendet den Strict-Mode von ECMA-Script 5.

Unterschiede

Variablen deklarieren

Node FS

var binding = process.binding('fs');
var constants = process.binding('constants');
var fs = exports;

NPM

var EventEmitter = require("events").EventEmitter
  , npm = module.exports = new EventEmitter
  , config = require("./config.js")

Verwendung von Semikolons

Node FS

Übliche, konsequente Verwendung des Semikolons am Ende eines Ausdrucks:

var kMinPoolSpace = 128;

return function(err) {
  if (err) {
    throw err;
  }
};

fs.Stats.prototype._checkModeProperty = function(property) {
  return ((this.mode & constants.S_IFMT) === property);
};

NPM

Soweit möglich konsequenter Verzicht auf Semikolons:

var cmd = require(__dirname+"/"+a+".js")

function defaultCb (er, data) {
  if (er) console.error(er.stack || er.message)
  else console.log(data)
}

npm.deref = function (c) {
  // ...
  var a = abbrevs[c]
  if (aliases[a]) a = aliases[a]
  return a
}

Stringausdrücke

Einfache Anführungszeichen, Leerzeichen zwischen String und Operator:

Node FS

'Unknown file open flag: ' + flag

NPM

Doppelte Anführungszeichen, keine Leerzeichen zwischen String und Operator:

"npm requires node version: "+j.engines.node

Vergleichsoperatoren: == gegen ===

Node FS

Kein konsequent beachteter Stil:

typeof data == 'string'
typeof arg1 === 'string'

NPM

typeof cli === "function"

Objektliterale

Node FS

Meist einzeilig:

options = { encoding: 'utf8', mode: 438 /*=0666*/, flag: 'a' };

NPM

Wie Variablendeklaration mehrzeilig mit vorgestelltem Komma:

npm.modes = { exec: 0777 & (~umask)
 , file: 0666 & (~umask)
 , umask: umask }

11 Kommentare

  1. Gibt es da bei Javascript eigentlich auch mittlerweile Kommentare für den Compiler, damit er was optimieren kann oder so?

    Hast du da schon mal was gehört?

  2. 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?

  3. Ich brauche das nicht direkt. Ich dachte nur, dass man das bestimmt in Zukunft braucht, wenn wir unsere Betriebssysteme in Javascript schreiben 🙂

  4. Von einem „Node-Coding-Style“ zu reden ist merkwürdig. Node ist ein Framework bzw. eine Laufzeitumgebung für JavaScript. Wenn, dann ist es ein JavaScript-Coding-Style.

    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

  5. 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).

  6. 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..

  7. Nur mal so eine Frage: Wie soll man denn den von node.js verwendeten Javascript-Coding-Style nennen, wenn nicht Node-Coding-Style?

  8. 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?

  9. 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.

  10. @Mike: Sorry, bei „Node ist nicht Javascript“ hab ich aufgehört zu lesen.

    @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.

  11. 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.

Kommentare sind geschlossen.