old style vs. new style

[Der Martin]

Mahlzeit,

Bei zeitunkritischen Programmteilen steht Lesbarkeit und Wartbarkeit in Vordergrund. Der ursprüngliche Programmierer kann bei späteren Änderungen längst nicht mehr da sein.

macht ja nichts - dann ist ein anderer da, der aber auch Fachmann ist und mit dem Code zurechtkommt. Wenn nicht, soll er sich bitte einarbeiten.

Wer sagt, dass der dritte nichts mit dem Projekt zu tun hat? Nur eben gerade nicht mit der Implementierung der beiden Module.

Dann hat er aber an genau der Stelle, nämlich an der Schnittstelle dieser beiden Module, nichts verloren und soll sich raushalten. Das sollen bitte nur diejenigen, die an der Stelle überhaupt mitwirken, unter sich ausmachen. Die Aussage gilt entsprechend, wenn an einer Schnittstelle nicht nur zwei, sondern mehr Module zusammentreffen.

und sie werden dann so definiert, dass die Module auf beiden Seiten der Schnittstelle so effizient wie möglich implementiert werden können.
Nein, das kann nicht Sinn des Schnittstellendesigns sein (jedenfalls nicht der vordringlichste).

Dir scheint nicht bewusst zu sein, dass die Welt nicht nur aus Hochleistungscomputern besteht. Im Gegenteil: Der Anteil an Microcontrollern und Embedded-PCs ist wesentlich höher als der von Desktop-PCs und noch leistungsfähigeren Maschinen. Was in der µC-Welt notwendige Pflicht ist -nämlich das bewusste Haushalten mit den verfügbaren Ressourcen- ist im PC-Bereich auch nicht falsch, wenn auch vielleicht unkonventionell.

An erster Stelle der Prioritäten steht für mich immer die Leistungsfähigkeit des fertigen Produkts.
Von der du gar nichts hast, wenn notwendige Änderungen später kaum zu machen sind.

Warum? Hast du ein Problem, zielgerichtet und kompakt formulierten Programmcode nachzuvollziehen? Saubere Dokumentation vorausgesetzt, versteht sich. Daran hapert's leider oft.

(und wenn man fähig ist, hardwarenah zu denken) C-Code in vielen Fällen umso besser lesbar und verständlich ist, je "optimierter" er ist.
Das kann nicht dein Ernst sein.

Mein voller Ernst. Als Beispiel eine generische Funktion, die für ihre Aufgabe einen Speicherbereich als Puffer braucht, der optional von der aufrufenden Funktion vorgegeben werden kann. Im Erfolgsfall möge die Funktion einen Zeiger auf den Puffer zurückgeben, sonst NULL:

Beispiel 1:
  BYTE *DoSomething(BYTE *UserBuffer, WORD size)
   { BYTE *buffer;
     if (UserBuffer!=NULL)
      { buffer = UserBuffer;
      }
     else
      { buffer = malloc(size);
      }
     if (buffer==NULL)
      { return (NULL);
      }
     // weitere Verarbeitung
     return (buffer);
   }

Beispiel 2:
  BYTE *DoSomething(BYTE *UserBuffer, WORD size)
   { BYTE *buffer;
     if (buffer=(UserBuffer ? UserBuffer : malloc(size)))
      { // weitere Verarbeitung
      }
     return (buffer);
   }

Ich weiß ja nicht, wie es dir geht - aber für mich ist die zweite Variante wesentlich klarer und besser lesbar. Bei der ersten geht wegen der vielen Einzelschritte leicht der Zusammenhang und damit der Überblick verloren.
Und ich bin mir mit meinen Kollegen über diesen kompakten Stil ziemlich einig. Die beiden Neuen, die im Lauf der Jahre dazukamen, fanden es zwar anfangs etwas schwer, sich an den "harten" Stil zu gewöhnen; mittlerweile vertreten sie ihn aber ebenso überzeugt wie ich, weil sie gemerkt haben, dass man sich dabei leichter auf das Wesentliche konzentrieren kann.

Schönen Tag noch,
 Martin