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 }

Auf der Projektseite werden drei zentrale Dokumente bereitgestellt, die durch GitHub versioniert werden und verschiedenartige Vorgaben liefern.

PSR-0: Autoloading Standard

Dieses Dokument beschreibt, wie Namespaces und Klassennamen zu wählen sind. Anhand dieser Vorgaben lässt sich ein Autoloader definieren, der automatisch alle benötigten Klassen nachlädt.

PSR-1: Basic Coding Standard

In diesem Schriftstück finden sich die grundlegenden Coding-Standards. Eine Datei muss UTF-8-kodiert sein, PHP-Bereiche werden durch <?php oder <?= eingeleitet. Für zentrale Konzepte gibt es hier Vorgaben zur Schreibweise:

ClassName
CONSTANT_NAME
methodName

Zudem wird festgelegt, dass eine Datei entweder Symbole (wie Klassen, Funktionen) definiert oder Seiteneffekte (Ausgaben erzeugen u. ä.) hat – niemals jedoch beides.

PSR-2: Coding Style Guide

PSR-2 geht ins Formatierungsdetail und hält fest beispielsweise fest, wie Klammern auszurichten sind:

ClassName
{
    function methodName()
    {
        if (true) {
            functionName();
        } else {
            functionName($arg1, $arg2);
        }
    }
}

Zudem wird genau beschrieben, was etwa passiert, wenn z.B. eine Methodendefinition die maximale Zeilenlänge von 120 überschreitet.

ClassName
{
    function tooLongMethodName(
        $one,
        $argument,
        $per,
        $line
    ) {
        // ...
    }
}

Klar formuliert und umfangreich

Die von mir angesprochenen Details sind lediglich Ausschnitte. Das Projekt scheint noch in Bewegung zu sein, dennoch wirken die Vorgaben sehr durchdacht und auch für die meisten Spezialfälle gerüstet. Durch die vielen Beispiele lässt sich der Stil auch ohne langes Lesen einfach adaptieren. Jeder PHP-Entwickler sollte mal einen Blick darauf werfen.

Auch beruflich bin ich angehalten, geschweifte Klammern folgendermaßen zu schreiben:

if (condition)
{
    // some code
}

Das ist für mich ungewohnt gewesen, aber auch kein Problem. Nach einiger Zeit gewöhnt man sich daran und findet es auch bald ansprechend. Der Mensch ist eben ein Gewohnheitstier.

Viele Empfehlungen verderben den Code-Brei

Unschön werden solche Vorgaben jedoch, wenn Programmiersprache oder Framework etwas anderes empfehlen. Dies fällt mir bei Java auf: Von Anfang an gab es hier konkrete Empfehlungen, wie Code auszusehen hat. Infolgedessen geben die meisten Projekte und Code-Schnipsel im Netz ein konsistentes Bild ab. Und auch ich schreibe Java-Code seit jeher so, wie Sun es mich gelehrt hat.

Fordert nun ein Unternehmen davon abzuweichen, so ist das mindestens ärgerlich. Oft wird hier versucht, ein sprachenübergreifend einheitliches Code-Bild zu erreichen. Diese Idee mag zunächst verlockend sein, ich halte sie aber schon aus genanntem Grund für grundlegend falsch. Will man Guidelines zum Coding-Style festlegen, sollte man sich zunächst im gegebenen Ökosystem umsehen.

Fehlerverursachende Konventionen

Kritisch wird es, wenn die Sprache sich bei bestimmten Coding-Konventionen nicht mehr so verhält, wie sie soll. Python etwa ist bekannt dafür, dass die Einrückung zur Bedeutung des Codes gehört. Doch es gibt auch versteckte Beispiele.

Betrachten wir folgenden Javascript-Code. Zwei Funktionen, die vermeintlich dasselbe machen: Ein Objekt zurückgeben. Das Ergebnis überrascht dann aber doch:

function returnObjA() {
  return {
    name: 'a'
  };
}

function returnObjB()
{
  return
  {
    name: 'b'
  };
}

console.log(typeof returnObjA());  // "object"
console.log(typeof returnObjB());  // "undefined"

Schuld daran ist Javascripts gutmütiger Umgang mit Programmierern, die gern mal ein Semikolon vergessen. Javascript versucht dann das Ende eines Ausdrucks zu erraten, was bei der zweiten Funktionen zu folgender Ergänzung führt:

function returnObjB()
{
  return;     // Ausdrucksende unerwartet erraten
  {
    name: 'b'
  };          // Unreferenzierte Objekterzeugung
}

Empfehlen lassen statt Empfehlungen geben

Schlussendlich ist die Wahl des Coding-Styles nicht unbedingt nur eine Geschmacksfrage. Eine Orientierung an größeren Frameworks oder der Programmiersprache selbst verbessern das Gesamtbild des Ökosystems sowie des Projektes selbst. Zudem kann ein kurzer Blick auf Beispiele in die Spezifikation einer Sprache unangenehme Seiteneffekte verhindern.

Zend Framework

if ($foo == $bar) {
	// ...
} else {
	// ...
}

call($foo, $bar)

function myFunction($arg1, $arg2 = '')
{
	// ...
}

class SuperClass
{
	function __construct()
	{
		// ...
	}
}

Pear

if ($foo == $bar) {
    // ...
} else {
    // ...
}

call($foo, $bar);

function myFunction($arg1, $arg2 = '')
{
    // ...
}

class Super_Class
{
    // ...
}

Code-Igniter

if ($foo == $bar)
{
	// ...
}
else
{
	// ...
}

call($foo, $bar)

function my_function($arg1, $arg2 = "")
{
	// ...
}

class Super_class {

	function __construct()
	{

	}
}