$(document).on 'click', (ev) ->
    if $('.container').has(ev.target).length == 0
      # ...

Dies ist beispielsweise hilfreich um ein Popup oder Dropdown-Menü schließen möchte, wenn der Nutzer „irgendwo“ außer auf das Widget selbst klickt.

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 }

Die Node-Applikation

Die einzurichtende Node-App ist nichts besonderes: Ein Express-Webserver aus Javascript und Coffescript. Getestet wird das Ganze mit Jasmine-Node, der Node-Variante des beliebten Testframeworks.

Der Javascript-Task-Runner Grunt

Die Grundlage für die Übersetzung und Echtzeitfunktionen bietet das Javascript-Build-Tool Grunt. Wie man ein Projekt damit anlegt ist auf der Seite Getting Started recht gut beschrieben (genau genommen finde ich die Beschreibung gar nicht so doll, habe aber keine Lust es besser zu machen).

Von Haus aus kann Grunt in etwa gar nichts, alles ist streng modular und muss manuell hinzugefügt werden. Ich brauche die folgenden Plugins:

grunt-contrib-copy

Mit Copy verschiebe ich reine Javascript-Dateien und andere Resourcen vom Source- ins Buildverzeichnis.

grunt-contrib-coffee

Mit der Coffee-Task schiebe ich Coffee-Dateien vom Source- ins Buildverzeichnis. Statt sie nur zu kopieren, werden sie dabei auch direkt in Javascript umgewandelt.

grunt-contrib-jasmine-node

Dieser Task dient dazu, nach dem Build auch Jasmine-Node-Unittests ausführen zu können (nicht mit grunt-contrib-jasmine für Frontend-Tests zu verwechseln). Tatsächlich nutze ich dieses Plugin nicht direkt, da ich eine Modifikation benötige (mehr dazu gleich).

grunt-contrib-watch

Dieses Modul überwacht ein angegebenes Verzeichnis auf Änderungen und startet jeweils eine spezifizierte Task. In meinem Fall ist das der Build (Copy und Coffee) sowie die Unittests.

Im Wesentlichen war es das auch schon: Die App wird bei jedem Speichern gebaut und automatisch getestet. Nur doof, dass man für die Ergebnisse ins Terminal gucken muss.

Testergebnisse als Desktop-Benachrichtigung

Hier konnte ich keinen wirklich eleganten Ansatz finden, der folgende Weg macht aber was wir wollen. Statt grant-contib-jasmine-node zu verwenden, kopieren wir uns die Task-Registrierung direkt in unser Gruntfile. Hier modifizieren wir die folgende Zeile:

var write = function(data) { process.stdout.write(data.toString()); }

Bevor die Write-Funktion die Nachricht in den Stdout schreibt, müssen wir analysieren, ob es sich um unsere Unittest-Ergebnisse handelt. Sieht die Nachricht etwa wie „x tests, y assertions, z failures“ aus, können wir Test- und Fehlerzahl direkt herausholen.

Nun, da wir unsere Ergebnisse extrahiert haben, müssen wir sie auf dem Desktop ausgeben. Ich nutze hierfür Notify-Send, welches Ubuntus Notify-Send-Benachrichtigungen bedient. Ggf. muss das Paket erst installiert werden. Für proprietäre Systeme gibt es andere Lösungen, die vergleichbar funktionieren.