Programmierrichtlinen (Uni-Paderborn)

Walli schrieb:

Redhead schrieb:

Walli schrieb:

Um es kurz zu machen: Wenn man vernünftig programmiert, dann muss man nicht kennzeichnen. Man kann, wenn man es toll findet, aber einen Mehrwert gibt es IMHO dadurch nicht.

Verbesserte "Lesbarkeit" des Quellcodes stellt für mich einen Mehrwert dar.

Wo ist er denn deiner Meinung nach besser lesbar? Wenn man die Funktionen übersichtlich hält und Variablen sinnvoll benennt, dann erkennt man normalerweise sofort was offensichtlich ein Member ist und was nicht. Ich sehe da kein Problem.

Woran erkennt man das denn bei dir. Ich würde gern mal ein Beispiel dazu sehen.
Aber bitte keinen 5- oder 10-Zeiler, oder wie von Artchi so einen genialen Einzeiler.

life schrieb:

btw.: du musst schon damit rechnen veräppelt zu werden, wenn du immer so übertreibst (Funktion maximal 2 Zeilen). Vielleicht mal bischen auf dem Boden der Tatsachen bleiben, dann haste auch nicht solche Probleme..

Ich habe doch gar keine Probleme. Die Übertreibungen bringen genau auf den Punkt, was es zu sagen gibt. Irgendwo hab ich es ausgeschrieben, dass bei kürzeren Funktionen automatisch die Tendenz besteht, die Variablen am Anfang zu definieren. Das kann jetzt jeder glauben oder nicht. Aber natürlich kann man das auch veranschaulichen. Mach eine Funktion bestehend aus zwei Anweisungen, da muss die Variablendefinition die erste sein. Für etwas längere Funktion gilt das noch fast genauso.

Da du ja anscheinend die Übertreibung als solche erkannt hast, hättest du sie nicht veräppeln brauchen sondern stattdessen überlegen können, wo der wahre Kern liegt. Du hast doch nicht wirklich angenommen, dass ich strikt gegen jede Funktion bin, die länger ist als 2 Zeilen.

Artchi

DEvent schrieb:

das ist eher bei zweideutigkeit:
class Blaaa
{
    int foo;
    void machirgendwas(int foo)
    {
        foo = foo;
    }
}
in Eclipse gibts eine Compiler-Warnung und der Code wird Gelb unterstrichen. Keine Ahnung was eine C++ IDE da macht.
Aber ein Präfix für Attribute ist total altmodisch , weil die modernen IDEs Klassenatribute anders Färben als lokale Variablen.

Naja, was hat die Zweideutischkeit mit Kennzeichnung zu tun? Dein Beispiel ist eher ein Programmierfehler bzw. wohl ungewollt?

class Blaaa
{
    int foo;
    void machirgendwas(int foo)
    {
        this->foo = foo;  // Zweideutischkeit nicht mehr möglich
    }
}

Warum ich immernoch Membervariablen kennzeichnen muß, ist mir immer noch nicht klar.

life

Optimizer schrieb:

life schrieb:

btw.: du musst schon damit rechnen veräppelt zu werden, wenn du immer so übertreibst (Funktion maximal 2 Zeilen). Vielleicht mal bischen auf dem Boden der Tatsachen bleiben, dann haste auch nicht solche Probleme..

Ich habe doch gar keine Probleme. Die Übertreibungen bringen genau auf den Punkt, was es zu sagen gibt. Irgendwo hab ich es ausgeschrieben, dass bei kürzeren Funktionen automatisch die Tendenz besteht, die Variablen am Anfang zu definieren. Das kann jetzt jeder glauben oder nicht. Aber natürlich kann man das auch veranschaulichen. Mach eine Funktion bestehend aus zwei Anweisungen, da muss die Variablendefinition die erste sein. Für etwas längere Funktion gilt das noch fast genauso.

Da du ja anscheinend die Übertreibung als solche erkannt hast, hättest du sie nicht veräppeln brauchen sondern stattdessen überlegen können, wo der wahre Kern liegt. Du hast doch nicht wirklich angenommen, dass ich strikt gegen jede Funktion bin, die länger ist als 2 Zeilen.

hättest du aufmerksam gelesen, wäre dir aufgefallen, dass ich dir schon attestiert habe, dass es einen wahren kern hat, obgleich es übertrieben war.

Artchi

Redhead schrieb:

Wenn du generell Programmierrichtlinien "dieser Art" für Unsinn hälst solltest
du mal darüber nachdenken, das es nicht darum geht dem Compiler einen Gefallen
zu tun. Dem ist es egal ob dein Variablen X, rewrerwe oder KarlEgon heissen.
Es geht darum MENSCHEN die den Quellcode lesen (müssen) die Arbeit zu erleichtern.

Und wenn du mal Projekte zu warten gehabt hättest die ein paar Jahre alt und nicht
10 sondern tausend Klassen enthalten, dann würdest du dich nicht nur
hin und wieder über ein paar (sinnvolle) Kommentare sondern auch über jede
sonstige Unterstützung freuen, und die "Kennzeichnung von Membervariablen"
gehört nach meiner Erfahrung dazu.

Gaaanz ruhig brauner! Woher willst du wissen, ob und in welchen Projekten ich noch nicht gearbeitet habe? Hab zwei Jahre lang in einem Projekt mit 10 bis 15 Leuten gearbeitet, das Packet mit Java-Archiven ist knapp 100 MByte groß. Also nichts kleines. Ansonst belaufen sich die Projekte bei 3 bis 6 Leuten (schwankt immer, je nach Anforderungen zum aktuellen Zeitpunkt). Bin also kein Greenhorn nach 7 Jahren Berufserfahrung.

Hab auch 1 Jahr das Spiel Heroes of Might & Magic III von PC auf Dreamcast portiert. Hab den Code auch ohne Namenskonventionen verstanden.

Und nein, in keinem Projekt haben wir bisher solche Namenskonventionen gehabt und auch nicht gebraucht. Auch wenn immer Leute von "Aussen" uns solche Konventionen aufzwingen wollen.

Hi Artchi,

Es gilt ja bekanntlich

Geht nicht, gibts nicht.

Ich bezweifle nicht das du deine und andere Quellcodes auch ohne solche
Restriktionen "geregelt" bekommst. Meine Erfahrung zeigt das die Einhaltung
von gewissen Regeln mir das Lesen fremder Quellcodes oft erleichtert hat.
Meine Kollegen, auch in früheren Firmen, sind/waren meist sehr begeistert wenn
spezielle Kollegen ihren "privaten" Coding Styles gepflegt haben, unabhängig
vom Ergebnis ihrer Programmierung.
Und daher gehöre ich, wenn Projektleiter bin, zu denen die auf Einhaltung der
von dir ungeliebten Richtlinien bestehen.

DEvent

Naja, was hat die Zweideutischkeit mit Kennzeichnung zu tun? Dein Beispiel ist eher ein Programmierfehler bzw. wohl ungewollt?

naja stell dir vor, du arbeitest seit 12 Stunden, bis Nachst um 4 Uhr, uns machst sowas ( mein Beispiel ). Jetzt stellen wir uns vor, dieser armer Programmierer hat die billigste IDE die es gibt. Dem Compiler ist es scheiss egal ob der Programmierer so ein scheiss macht wie foo = foo.
Was kommt? der armer und überarbeiter Programmierer sucht noch die ganze Nacht bis zum Morgengrauen nach einem Fehler.
Mit Zweideutigkeit meinte ich, das es nicht ersichtlich ist ob foo eine Membervariable ist oder nicht.
Und jetzt sag blos, du weist Membervariablen immer mit this->xxxx zu.
PS: das mit den Unterschrichten ist brutal, schonmal den STL-Code gelesen?

Wo ist er denn deiner Meinung nach besser lesbar? Wenn man die Funktionen übersichtlich hält und Variablen sinnvoll benennt, dann erkennt man normalerweise sofort was offensichtlich ein Member ist und was nicht. Ich sehe da kein Problem.

otze

Ponto schrieb:

otze schrieb:

hats in C++ auch nicht. Die Compiler sind da schon intelligent genug

Das glaube ich nicht:

class Obj {
public:
   Obj() { sock.open("127.0.0.1"); }
   ~Obj() { sock.close(); }
   void write(char const * str) { sock.write(str); }
private:
   SocketObj sock;
};

void func(int value) {
  Obj ob;

  if (value > 10) return;
  
  ob.write(value);
}

ich wette einfach mal mit dir, dass die compiler erkennen können, dass "ob" nichts mit "value" zu tun hat, und so die beiden zeilen getauscht werden können.

Helium schrieb:

Dann ist dein Compiler kaputt. Er sollte schon das machen, was du ihm sagst.

bei non pods stimm ich dir zu. bei pods trau ich den compilern aber alles zu

Walli

DEvent schrieb:

Naja, was hat die Zweideutischkeit mit Kennzeichnung zu tun? Dein Beispiel ist eher ein Programmierfehler bzw. wohl ungewollt?

naja stell dir vor, du arbeitest seit 12 Stunden, bis Nachst um 4 Uhr, uns machst sowas ( mein Beispiel ). Jetzt stellen wir uns vor, dieser armer Programmierer hat die billigste IDE die es gibt. Dem Compiler ist es scheiss egal ob der Programmierer so ein scheiss macht wie foo = foo.

Dazu kommt erschwerend hinzu, dass es draußen regnet und die Lochkarten gerade aufgebraucht sind.

Redhead schrieb:

Woran erkennt man das denn bei dir. Ich würde gern mal ein Beispiel dazu sehen.
Aber bitte keinen 5- oder 10-Zeiler, oder wie von Artchi so einen genialen Einzeiler.

Mehr als 10 Zeilen wirst du bei mir im nicht-GUI-Code eher selten antreffen (Leerzeilen und eventuelle Kommentare nicht mitgezählt).

Ponto

otze schrieb:

ich wette einfach mal mit dir, dass die compiler erkennen können, dass "ob" nichts mit "value" zu tun hat, und so die beiden zeilen getauscht werden können.

Der Compiler darf auf keinen Fall den Aufbau der Socketverbindung unterschlagen. Das hat ja sichtbare Auswirkungen. Hier kann nur der Mensch entscheiden, ob das in jedem Fall gemacht werden soll, oder nicht. Meistens ist eine Verbindung, die sofort wieder geschlossen wird, sinnlos.