Moinsen.
Ich wollte mal fragen, ob es einen Geschwindigkeitsverlust gibt, wenn ich meinen PHP Code in Klassen verpacke und dann in einer einzigen Datei speichere. Eigentlich müsste der Server ja nur das raussuchen, was er braucht, aber wenn viele Leute darauf zugreifen und ich das auf verschiedenen Seite habe, dann müsste der ja schon einiges zu tun haben...

Das hab ich mich auch schonmal gefragt. Aber weißt du was? Mach dir darüber einfach keine Gedanken.
ALLE professionellen Webprogrammierfirmen werden vermutlich ein Projekt mittlerweile so in Klassen aufteilen, dass es einem schwindlig davon wird... so wird's ja den Leuten auch beigebracht. So modular wie nur irgendwie möglich programmieren.
Ich bin da nicht so ein Fan von, ich ziehe oft einen klaren "C-Style" einem "C++-Style" vor, der vor Klassen nur so wimmelt. Entsprechend ist das auch auf PHP übertragbar.
Ich denke, man sollte es folgendermaßen machen: So programmieren, dass die Funktionen und Klassen klar abgegrenzte Programm-/Scriptbereiche erledigen, dabei aber die Verhältnismäßigkeit wahren. Was nutzt es einem, wenn man ein Script hat das super modular aufgebaut ist, aber man das ganze als linearen Code auch in der Hälfte der Zeilen hätte schreiben können?
Was ich damit sagen will: es ist egal, wie du's schreibst, natürlich sind manche Sachen schneller, manche Sachen langsamer. Klassen sind eher langsam - aber alles bewegt sich allenfalls im Bereich von 1/100tel-Sekunden. Da sollte es dir eher wert sein, einen klar strukturierten Code zu haben (d.h. ohne übertriebene Klassen, ohne Spaghetti-Code), dann hast du nämlich die Zeitersparnis beim Editieren des Codes =)

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

Alles will ich ja auch nicht in Klassen haben, nur das, was für mich sinnvoll erscheint, deswegen werde ich auch nicht aus einer Funktion eine Klasse machen, das wäre sinnlos, aber wenn es mehrere Funktionen sind, die alle miteinander was zu tun haben, dann sind Klassen besser.
Wenn ich zum Beispiel einen simplen Counter hab, dann kann ich einfach "$counter->visitstotal()" schreiben. Damit seh ich auch schneller, womit welche Funktionen was zu tun haben. Spaghetti-Code wird das ja auch nicht soooo stark. Irgendwo müssen die Funktionen ja untergebracht werden. Wenn ich die jetzt da hinschreiben würde, wo ich die im Code haben will, wird das alles glaub ich schlimmer, vor allen Dingen, wenn die lang sind...

Und was wär mit counter_visitstotal($counter)? =)

georg-wicherski@pixel-house.net | http://www.pixel-house.net/ - Coding Resource| http://www.google.de/

Der klare C-Stil ist aber im Gegensatz zum klaren C++-Stil um Lichtjahre unterlegen. Anscheinend habe die meisten von euch noch immer nicht kapiert, wieso der imperative-strukturierte Stil keine Zukunft mehr hat...

Der Mensch denkt in Objekten, egal wie, wo und wann! Ein Computer "denkt" dagegen in Daten und Funktionen, die diese Daten in irgendeiner Weise ver- oder bearbeiten. Diese maschinelle Denkweise ist für den Menschen unnatürlichen Ursprungs und zwingt ihn zu einer ihm normalerweise vollkommen unbekannten und unproduktiven Denkweise. Existiert dagegen eine Möglichkeit, das menschlich-objektorientierte Denkverhalten auf Maschinen zu übertragen, so erleichtert das die konzeptionelle Arbeit erheblich! Die Maschine sorgt dann selbst dafür, daß die menschliche Objektabstraktion in eine für die Maschine verständliche Daten-Funktionen Abstraktion konvertiert wird.

C ist imperativ-strukturiert, orientiert sich banal an der maschinellen Denkweise. C++ ist (semi)-objektorientiert und orientiert sich an der menschlich-abstraktiven Denkweise. Da der Mensch letztendlich das Programm entwirft und implementiert, ist er nach allgemeiner Auffassung mit objektorientierten Sprachen besser bedient als mit imperativ-strukturierten Sprachen. Und das ist kein Joke, daß ist Tatsache! Neben der damals fehlenden Codewiederverwendbarkeit war auch das oben beschriebene Problem eines der Hauptauslöser für die Softwarekrise.

Die Verwendung von Klassen als Datenstruktur für Objekte in PHP ist meiner Meinung nach für die Bündelung und Isolierung voneinander unabhängiger Programmelemente der erste Schritt zu effektiver PHP-Programmierung. Da die PHP-Klassen aber im Prinzip nichts anderes Darstellen als ein verkrüppelter Abklatsch der C++ Klassen (die haben mehr mit Strukturen gemeinsam als mit Klassen), ist das PHP-Klassenkonzept erstmals nur eine Bereinigung von wildem Code.

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

Zitat:

Kriz postete
Der klare C-Stil ist aber im Gegensatz zum klaren C++-Stil um Lichtjahre unterlegen. Anscheinend habe die meisten von euch noch immer nicht kapiert, wieso der imperative-strukturierte Stil keine Zukunft mehr hat...

Der Witz ist nur, daß die ach so vehementen Prediger von C++ keinen klaren C++-Stil verwenden :P
Das liegt aber primär daran, daß C++ nicht mehr so einfach wie C ist. Die Syntax von Templates ist zum Beispiel einfach klobig, und typedefs sind da normal keine gute Idee.
Wobei klarer Stil auch zum großen Teil eine Frage des Designs ist, und es gibt nun mal einfach kein gutes Design, nur schlechtes und sehr schlechtes ;)

Zitat:

Der Mensch denkt in Objekten, egal wie, wo und wann! Ein Computer "denkt" dagegen in Daten und Funktionen, die diese Daten in irgendeiner Weise ver- oder bearbeiten. Diese maschinelle Denkweise ist für den Menschen unnatürlichen Ursprungs und zwingt ihn zu einer ihm normalerweise vollkommen unbekannten und unproduktiven Denkweise. Existiert dagegen eine Möglichkeit, das menschlich-objektorientierte Denkverhalten auf Maschinen zu übertragen, so erleichtert das die konzeptionelle Arbeit erheblich! Die Maschine sorgt dann selbst dafür, daß die menschliche Objektabstraktion in eine für die Maschine verständliche Daten-Funktionen Abstraktion konvertiert wird.

Einspruch! Ich bin wahrscheinlich eine extreme Rarität in der Hinsicht, aber wenn man programmiert seit man denken kann, dann kann man dem Computer "nachfühlen" und kann eben doch in Funktionen und Daten denken...
Wenn ich es mir recht überlege ist das übrigens genau der Grund weshalb ich programmiere. Wenn ich nicht nachvollziehen könnte, was der Computer tut, wäre das Programmieren für mich ziemlich witzlos. Ein Grund mehr, akademische OO-Programmiersprachen nicht zu verwenden.

Zitat:

C ist imperativ-strukturiert, orientiert sich banal an der maschinellen Denkweise. C++ ist (semi)-objektorientiert und orientiert sich an der menschlich-abstraktiven Denkweise. Da der Mensch letztendlich das Programm entwirft und implementiert, ist er nach allgemeiner Auffassung mit objektorientierten Sprachen besser bedient als mit imperativ-strukturierten Sprachen. Und das ist kein Joke, daß ist Tatsache! Neben der damals fehlenden Codewiederverwendbarkeit war auch das oben beschriebene Problem eines der Hauptauslöser für die Softwarekrise.

Was für eine Softwarekrise? Meinst du die, die dadurch ausgelöst wurde, daß sämtliche Aktien auf dem Neuen Markt überbewertet waren? Das hatte wohl eher nichts mit den verwendeten Programmiersprachen oder dem Unwissen der Programmierer zu tun, sondern mit dem Unwissen und der Naivität der Anleger, Händler & co...

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Zitat:

Wenn ich nicht nachvollziehen könnte, was der Computer tut, wäre das Programmieren für mich ziemlich witzlos.

Es heißt ja nicht, dass wenn man objektorientiert Programmiert, dass man das nicht versteht (siehe Java ;) ). Aber warum sollte man sich daran gewöhnen, wie der Computer das macht? Letztendlich ist es jedem selbst überlassen, wie man am besten programmiert. Ich hab auch verschiedenes probiert und mir gefällt die OOP am besten.

Prefect, mit dieser Einstellung solltest du folgendes niemals studieren: Informatik und all seine Ableger...

Ich programmiere auch schon allerlei seit ich 9 bin, vom allerersten Einzeiler in BASIC bis hin zu kompletten C++ DBV-Systemen (wobei mein erster Versuch 1996 in C++ auf mich heute wirkt wie ein zu Code gewordener Witz =). Ich habe auch die imperative wie auch die objektorientierte Variante erlernt, also weiß ich definitiv, wovon ich rede! Und die Industrie steht nicht mehr auf so auf C wie noch vor 15-20 Jahren.

Zum Thema Softwarekrise: Damit ist nicht der Aktieneinbruch am NEMAX gemeint, sondern der kolossale Einbruch in den 70er Jahren bei der SW-Entwicklung. Die geforderten Resultate waren mit den typisch imperativ-struktuierten Sprachmodellen nicht mehr so zu realisieren, wie ein Projektplan das am Anfang mal vorgesehen hatte. Zu komplex, zu umständlich, zu teuer und zu zeitfressend waren die SW-Projekte mit C, ADA, Fortran, Cobol und wie sie alle heißen geworden. Es gab nicht minder wenige Projekte, die wegen Erschöpfung und Sprengung des Budgets eingestampft werden mußten, nur weil der Zeitrahmen zur Realisierung durch eine imperative Struktur (trotz Libraries usw.) zu kostenintensiv geworden war.

Oder meinst du, objektorientierte Sprachen sind nur entstanden, weil jemand gerade mal etwas Zeit hatte, "mal was anderes" auszuprobieren? Laß dir mal von einem alten Informatiker sagen, daß C heutzutage in der Industrie nur noch aus historisch-kompatibilitären Gründen verwendet wird. Neuentwicklungen laufen zu 95% nur noch in C++, Java, Delphi oder anderen OOLs ab.

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

RockingRolli: Klar. Ich habe ja auch nur von mir geredet. Das der (Haupt-)Anreiz für andere Leute woanders liegt ist mir schon klar.
Ich programmiere übrigens ständig in C++. Die Sprache ist eine gelungene Mischung, bei der mir auch noch klar sein kann, was eigentlich vor sich geht.

Kriz: Fällt dir eigentlich auf, daß du mir Meinungen in den Mund legst, die ich nicht vertrete?
Nachdem du das mit der Softwarekrise aufgeklärt hast bleiben noch zwei Punkte: ich habe bei C++-Verfechtern nur selten klaren C++-stil gesehen und ich kann durchaus in Funktionen denken, zumindest meiner Einschätzung nach. Das hat _nichts_ damit zu tun, ob in der Industrie C verwendet wird oder nicht.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

also zurück zur ursprünglichen Frage:
Ob sich Klassen lohnen musst du dir immer so überlegen:
Habe ich mehrere Objekte auf der Seite, die die gleiche Arbeit verrichten?

Wenn ja, dann lohnt es sich zum Beispiel aus dem (Text-)Counter ein Objekt zu machen, weil man mehrere einfach nur ein weiteres Objekt der Klasse Counter erstellen muss, was alle funktionen selber mitbringt und nur initialisiert werden muss. Bei Grafikcountern wäre das natürlich wieder anders, weil, du ja wohl sehr selten in ein Bild zwei Counter unterbringst.
Genauso verhält es sich auch mit TemplateKlassen. Normalerweise benutzt man halt mehrere Templates: frame.html, head.html, forumrow.html etc. Da lohnt es sich dann, jeweils Objekte zu erstellen, die man mit einem Aufruf initialisiert und jeweils mit eingebauten Funktionen automatisch Stringersetzung vornimmt. (Dabei ist allerdings die Templateklasse vom THWBoard nicht gerade ein Paradebeispiel, weil dort die Variablen per eval() geparst werden, besser wäre ein str_replace, weil dann auch gleichzeitig die Sicherheit erhöht werden würde, aber das ist Almkuh's Sache)

Fazit: Verrichten mehrere "Objekte" auf einer Seite die gleiche Arbeit, lohnt es sich in PHP Klassen zu verwenden.

@Prefect: Ich will dir keine Meinung aufbinden, ich will du nur mal zeigen, was Realität ist draußen in der Welt. Auch ich kann (wenn ich will) in Funktionen und Daten denken , schließlich haben wir beide (!) damals so angefangen Programmieren zu lernen. Aber es ist viel leichter, umkomplizierter (in einer gewissen Weise) und schneller in Objekten zu denken als in Daten und Funktionen. Das fast 75% aller Welt-Programmiersprachen imperativ-strukturiert arbeiten, erfordert beinahe fast schon die Fähigkeit, auch wie eine Maschine zu denken. Aber laß nochmal 10 Jahre ins Land gehen, evtl. auch 15 und keine Sau wird sich mehr ernsthaft mit imperativ-strukturierten Sprachen anfreunden, wenn er nicht gerade wissenschaftlich mit C unter *nix/Linux/Solaris arbeiten muß. Aber ich denke, auch dort wird irgendwann in nicht allzuferner Zukunft das GNU-Doktrin zur bevorzugten Benutzung von C bei Anwendungen gebrochen werden. Auch ein Richard M. Stallman kann nicht Tendenzen unbegrenzt beeinflussen.

@Apfelkorn (hicks): Wie ich schon sagte, Klassen in PHP lohnen vorerst nur zur Entrümpelung von gleichartigen Prozessen innerhalb eines Skripts. Natürlich kann man mit PHP Klassen bereits nützliche Objekte schaffen. Ich verweise da mal auf meine GermanDate-Klasse, die je nach $PHP_OS ("Linux" oder "Win32") die durch setlocale() beeinflussten Lokaleinstellungen des Systems korrekt auf eine deutsche Datumsausgabe projeziert. Ich hatte anfänglich das Problem, daß setlocale() von Linux und Win32 anders interpretiert wird, sprich es eine Inkompatibilität zwischen zwei versionsgleichen PHP-Interpretern gibt. Meine GermanDate Klasse behob dieses nervige Problem elegant und sparte redundantes Coden.

@Rest der Welt: Nein, Prefect und ich unterhalten uns ganz "normal" wie immer (hehehe) =)

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

Kriz & Prefect: ist ja alles schön und gut. Nur was dem einen schmeckt, muss nicht das Leibgericht des anderen sein.
Ich für meinen Teil hab es gerne, wenn man nicht übermäßig mit Klassen um sich schmeißt. Warum? Weil teilweise 10 Zeilen Code mehr sagen als ein Klassenaufruf. Manchmal ist es aber auch genau andersrum. Ein praktisches Beispiel: Während ich früher meine PHP-Datenbankansteuerung ganz normal mit Funktionen gemacht habe, bin ich jetzt auf eine Klasse umgestiegen. Da hab ich einfach alles drin und brauch nur noch eine Klasse zu instanzieren, um direkt verbunden zu sein und loslegen zu können, inklusive vollautomatischem Error-Handling. Das ist einfach praktisch. Und ich kann die Klasse als eigene Datei anlegen und überall (d.h. verschiedene Projekte) verwenden.
Es ging ja aber nun darum, ob Klassen langsamer sind, nicht ob sie laut Informatik-Studium überlegen sind.
Und ich sag einfach mal: ja, sie sind langsamer. Bei compilierten Sprachen wie C/C++ mag der Unterschied gering sein. Bei PHP - also einer Scriptssprache (obwohl auch PHP mittlerweile vor der Ausführung compiliert wird) hat es sicher größere Auswirkungen.
Dennoch ist halt der private Codestil (ob nun gut oder schlecht spielt keine Rolle, Hauptsache man steigt durch) in diesem Fall entscheidender als die Geschwindigkeit bei der Ausführung. Was nutzt einem ein kilometerlanger C-Style-Code, wenn man nicht mehr durchblickt? Was nutzt einem ein Klassen-Chaos, wenn man nicht mehr durchblickt? Die gesunde Mischung ist hier angesagt, wie die für den einzelnen aussieht, darf man ja wohl noch selbst entscheiden.

Anders sieht's natürlich aus, wenn man mal in ein Programmier-Team eingebunden wird. Dann ist natürlich absolute Vorraussetzung, dass mit Klassen und genau definierten Schnittstellen gearbeitet wird, damit das Zusammenspiel klappt.
[edit] Nur: in diesem Fall ist man auch nicht darauf angewiesen zu wissen, wie bestimmte Klassen funktionieren. Sie tun es einfach und gut ist. Ganz anders, wenn man allein an einem Projekt arbeitet. Da möchte man doch gerne den Überblick haben, wie der gesamte Code funktioniert (jedenfalls möchte ich das - ich verlasse mich nie auf ein "naja, die Klasse wird das schon irgendwie machen"). Und wenn man sich dann durch einen Haufen Klassen durchklicken muss, nur um kurz nachzuschauen, was ein Klassenaufruf eigentlich macht... viel Spaß. [/edit]

Im Informatikstudium mag man zwar die möglichst weitestgehende Abstraktion und Aufteilung eines Problems in Funktionen und Klassen lernen. Aber ehrlich gesagt - zu viel Abstraktion tötet die Lust am Programmieren. Da sollen wohl alle Programmierer auf eine Schiene gebracht werden. Tut mir leid, aber nicht mit mir (ich studier sowieso kein Informatik =) ). Der Codestil ist und bleibt so etwas wie eine Handschrift. Wenn man versucht, einen gewissen Codestil aufzudrängen, dann wird das nix... siehe Microsoft -> buggy Programme =)

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

Das hast du recht! Die Informatik bereitet dich auf die Industrie vor und da kann man mit seiner "Handschrift" nur böse Blicke des Chefs ernten. Privat ist es natürlich dahingestellt, wie man seinen Code gestaltet. Aber stilistisch sauber aufgesetzter Code liest sich nunmal leichter als wirres Durcheinander, weshalb man bereits im Studium sowas eingetrichtert bekommt. Und ich habe das niemals als Nachteil empfinden müssen, eher als Vorteil.

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

C++ ist prinzipiell erst einmal nicht langsamer als C. Wenn man konzeptionell gleichen Code einmal unter C und einmal unter C++ schreibt ändert sich an der Geschwindigkeit erst einmal nichts - auch wenn man unter C++ Klassen verwendet.
Beispiel:

Quellcode:
struct something {
    int a;
};

void print_something(struct something *s)
{
    printf("%i\n", s->a);
}

....
struct something s;
print_something(&s);


und

Quellcode:
class something {
public:
    int a;
    void print() { printf("%i\n", a); }
};

...
something s;
s.print();


Beide Codeschnipsel sind im Prinzip gleich schnell, da sie den gleichen Code darstellen, nur anders formuliert. Allerdings läßt sich ein C++-Compiler eher dazu ermuntern, den this-Pointer in einem Register statt auf dem Stack zu übergeben. Von daher könnte die C++-Version etwas schneller sein.

virtual-Funktionen sind natürlich langsamer als normale Funktionsaufrufe, aber sie entsprechen ja konzeptionell Funktionspointern, und die sind wiederum gleich schnell.

In manchen Fällen (z.B. Templates) kann C++-Code auch dadurch schneller werden, daß der Compiler inline-freudiger wird.

Konzeptionell gleicher Code ist unter C++ wohl fast immer schneller oder zumindest gleich schnell. Allerdings ermuntert C++ viele dazu, ineffizienten Code zu schreiben, und das ist nicht zu unterschätzen...

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

hm ich find klassen in php nicht wirklich toll. (mehr sag ich jetzt dazu bewusst nicht =)

@apfel: str_replaces bei templates sind _wesentlich_ langsamer als eval(). das sicherheitsproblem kann man auch anderweitig, an der wurzel in den griff kriegen (register_globals).

@dp: allerdings wird es wohl ne ganze Zeit dauern, bis sich register_globals = off durchsetzt - es gibt einfach zu viele Scripts, die darauf aufbauen. Und wenn man sich dann so einen Pfusch wie bei phpmyadmin anguckt, wo einfach alle Variablen manuell übernommen werden (aber ohne Check, ob sie wirklich benötigt werden)... naja.

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

naja, ich finds auch ziemlich asslig jetzt einfach mal so tiefe änderungen vorzunehmen, aber wenn dann bitte richtig. dann soll es ab der nächsten php version eben garnicht mehr anders gehen. die jetztige situation ist äußerst beschissen, du musst so coden dass register_globals on und off sein kann, < php 4.1 muss auch noch gehen (von wegen $_REQUEST) und nebenbei muss das ganze auch noch sicher sein. klar, strato & co werden nicht von heute auf morgen umstellen, aber das ist nur eine frage der zeit. wenn man nicht gerade selbst nen server rumstehen hat, muss man eben auf das zurückgreifen was funktioniert.

die phpmyadmin lösung ist genauso pfusch wie beim thwboard, man kann halt nicht einfach mal an einem tag das ganze so umschreiben dass es mit register_globals off funktioniert. deswegen schätze ich auch, dass es bei phpmyadmin auch nur ne zwischenlösung ist.

ne funktion wie register_var() (builtin natürlich)wäre wünschenswert, aber das bringt auch nichts mehr, denn dann muss man 3 unterschiedliche konfigurationen beachten. imho alles ziemlicher screw was die da verzapft haben :\

Naja, die extract-Funktion ist ja ganz nützlich, nur ist leider das wirklich wichtige Flag erst vor kurzem hinzugekommen: EXTR_IF_EXISTS. Dann werden die Variablen nur übernommen, wenn sie bereits definiert wurden. Das macht Sinn...
Wo genau ist eigentlich der Unterschied zwischen $HTTP_GET_VARS und dem $_GET Zeugs?

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

$_GET ist "superglobal", d.h. du musst es nicht in funktionen global machen. ansonsten ist es das gleiche wie $HTTP_GET_VARS, nur mit dem unterschied dass $_GET php4.1+ ist.

wirklich nützlich ist sowieso nur $_REQUEST, da es _GET _PUT _POST etc kombiniert. sowas gab's in php < 4.1 nicht.

... aber da viele Webhoster noch auf 4.04 und so rumhocken (und grade mal wieder ein heftiges Sicherheitsloch in PHP 4.2.(x < 2) gefunden wurde), taugt das wohl noch nix.

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

@prefect: was isn eigentlich klarer c++-stil? (damit ich deine meinung verstehen kann)

Hmm. Klarer C++-Stil ist was sehr subjektives. Wenn ich ein Programm in klarem C++-Stil sehen würde könnte ich es dir sagen. Qt kommt dem Ziel wahrscheinlich bis jetzt am nächsten.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Hm, eine kleine Anekdote aus der Firma:

Ich schreibe Methoden, Funktionen oder generell alle Bezeichner sehr ausführlich aus: Ein simples strcpy wird bei mir tatsächlich zu einem StringCopy oder aus einem static const long unsvid; wird bei mir ein static const long m_sclUniqueSerialVersionID; usw. Außerdem klatsche ich gerne mal etwas mehr Kommentare in den Code als andere.

Darüber habe ich mir anfangs viel Gelächter anhören müssen, von wegen "Was machst du denn da? Romane schreiben? Wir entwickeln Software und keine Betriebsanleitungen!" und ähnliches mehr. Zur Info: Kommentare werden bei uns noch nicht sooo streng in die Ergebnisbewertung einbezogen als woanders. Tja, bis dann eines Tages eines von zwei Teilmodulen zurückkam mit der Bitte um Revision und Nacharbeit.

Das besagte Modul hatten meine Kollegen entwickelt und erwies sich als stlistisch absolut unlesbar, unverständlich und schwer verdaulich für Drittleser. Auf die Anfrage, wo denn das zweite Modul bliebe (an dem habe ich u.a. mitgewirkt),kam die lapidare Antwort des Kunden: "Wieso? Das zweite Modul ist im Gegensatz zum ersten ein Augenschmaus an Stil und Lesbarkeit. Alles ist sofort auf Anhieb verständlich und man weiß sofort, mit was man es zu tun hat. An dem zweiten Modul gibt es nichts auszusetzen..."

Seitdem ist es still aus dem Lästerlager geworden...

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

It was hard to code, it should be difficult to understand...

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

* no comment *

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)