Präfix oder Suffix - Wie haltet Ihr es mit der Namensgebung?

[Dejan Vu]

Richtig. Deswegen fallen einem ja auch die Finger nicht ab, wenn man eine Methode 'auseinander faltet', also aus Performancegründen alle Vorsätze über den Haufen wirft oder sich partout nicht an die Empfehlungen des Clean Code hält. Das ist ja kein Dogma.

Es soll auch erfolgreiche Delphi-Entwickler geben, die seit Jahrzehnten in altbewährten Mustern (so gar nicht 'clean') programmieren und ihre Familie und die ihrer Angestellten gut ernähren können. Dem Akademiker und Clean-Code-Fetischisten will das zwar nicht in den Kram passen, aber so isses nun mal.

Mir ging es nur darum, aufzuzeigen, das man eigentlich überhaupt keine Präfixe oder Suffixe benötigt und diese (außer eben bei Konventionen) ein Anzeichen sein könnten, seinen Code-Stil zu verbessern oder zu verändern. Aber wer mit Präfixen glücklich ist, soll das mal so beibehalten. Hauptsache, man findet sich im Code zurecht.

Bei uns wird jedenfalls mit SOLID und Clean Code programmiert.

[Mavarik]

Zitat von Dejan Vu:

Aber wer mit Präfixen glücklich ist, soll das mal so beibehalten. Hauptsache, man findet sich im Code zurecht.

Für mich ist die "richtige" Variable Benennung ein Schritt zum besser lesbaren Code... Egal wie Du das Kind jetzt nennen willst...

[EDIT]Geiler blogpost zu diesem Thema[/EDIT]

Und das Ziel sollte doch nicht nur sein, dass man(n) "sich" im Code zurecht findet, sondern auch alle anderen...

Kleines Beispiel - ab von der Norm:

Delphi-Quellcode:

if bla > 2 then  // normaler if
  begin
  end;

if bla < 0       // if mit else Teil   
  then begin

// Ganz viel Code (mehr als 7 Zeilen)






       end
  else begin // Ich wusste das es Dich gib als ich das if gelesen habe....
         
       end;

[DeddyH]

Ich fänd

Delphi-Quellcode:

if bla < 0 then
  BehandleNegativ
else
  BehandleNullOderPositiv;

lesbarer, aber was weiß denn ich?

[mquadrat]

Zitat von Mavarik:

Delphi-Quellcode:

if bla > 2 then  // normaler if
  begin
  end;

if bla < 0       // if mit else Teil   
  then begin
// Ganz viel Code (mehr als 7 Zeilen)
       end
  else begin // Ich wusste das es Dich gib als ich das if gelesen habe....
         
       end;

Ist das tatsächlich so gemeint, dass man an der Position des then erkennen können soll, ob da noch ein else folgt oder nicht? Wenn ja, dann halte ich das für eine ganz schlechte Idee. Da drückt einer mal Auto-Format und schon ist das weg.

[Mavarik]

Zitat von DeddyH:

Ich fänd

Delphi-Quellcode:

if bla < 0 then
  BehandleNegativ
else
  BehandleNullOderPositiv;

lesbarer, aber was weiß denn ich?

Klar und dann muss ich an 2 Stellen nachsehen was der Code eigentlich macht...

Abgesehen davon ist es in real live dann eher

Delphi-Quellcode:

if bla < 0 then
  BehandleNegativ(bla,Text,nochwas,true,index,undnochmehr)
else
  BehandleNullOderPositiv(bla,Text,nochwas,true,index,undnochmehr);

Macht alles nur unleserlich... Man verliert total den Zusammenhang...

Zitat von mquadrat:

Ist das tatsächlich so gemeint, dass man an der Position des then erkennen können soll, ob da noch ein else folgt oder nicht? Wenn ja, dann halte ich das für eine ganz schlechte Idee. Da drückt einer mal Auto-Format und schon ist das weg.

Super Idee, oder?

Gibt es einen der so formatiert wie die Auto-Format Routine?
Klar, wenn die richtig funktionieren würde vielleicht...

[BUG]

Zitat von Mavarik:

Abgesehen davon ist es in real live dann eher

Delphi-Quellcode:

if bla < 0 then
  BehandleNegativ(bla,Text,nochwas,true,index,undnochmehr)
else
  BehandleNullOderPositiv(bla,Text,nochwas,true,index,undnochmehr);

Sagen wir es so ... Clean Code ist ein Gesamtkonzept. Man kann nicht ein Konzept rausgreifen und erwarten das es Code jetzt sofort besser lesbar macht.

• Die Funktionen würden nicht so heißen, sondern das beschreiben, was sie machen (z.B. kämmeWookiee).
• Die vielen Parameter würde man vermeiden, z.B. durch Membervariablen.
• Im Ernst, so viele Parameter?

Es ist etwas gewöhnungsbedürftig, aber viele Algorithmen lassen sich gut als Klassen (evtl. Records in Delphi) ausdrücken.

Die absolute puren Lehre von Clean Code ist vielleicht nicht für alle Programmieraufgaben geeignet, aber für Anwendungslogik (was ist zu tun) ist es (imho) die richtige Richtung.

[Der schöne Günther]

Warum können wir uns in letzter Zeit so viel über Quellcode-Ästhetik streiten (nicht dass es schlecht wäre)? Wir sollten uns mal ein paar einfache Probe-Aufgaben ausdenken und dann schauen wer es am schönsten löst.

Der Sieger muss aber auch was gewinnen.

[Rollo62]

Will mal noch etwas in den Raum stellen.

Zitat:

Die Funktionen würden nicht so heißen, sondern das beschreiben, was sie machen (z.B. kämmeWookiee).

Ich benutze so eine Art umgekeht polnische Notation für meine Methodennamen,
also nicht kämmeWolle oder setzeDing.

Sondern so etwas:

Code:

Wolle_Schneiden()
Wolle_Kaemmen()
Wolle_Farbe_Get()

Das hört sich zwar womöglich unlogisch an, hilft aber die Methoden und Variablen sauber zu sortieren, so das oft schon im Namen eine Art "Klasse" entsteht.

Bin ich u.U. der Einzige der sowas macht ?

Und ich setze sehr lesbare, lange Namen ein die möglichst gut die Funktion beschreiben.
Mir graust es von den Verkürzlern, die so etwas in der Art produzieren:

Code:

vf:=dx+k*24modr;
Sx(vf, -k, -r);
vt:=vf+k; k:=23; dx:=k*17+vx;

Meinetwegen können die dafür einen Preis pro eingesparten Buchstaben bekommen, aber ich möchte mir sowetwas in einem halben Jahr nicht mehr durchsehen müssen.


Ich richte meinen Code an den ":=" aus, und schreibe mehrzeilige if conditions, alles damit aud einem Blick alles erfasst werden kann.
Seitdem es HD Monitore gibt muss man eigentlich keinen Bildschirmplatz mehr sparen.

Rollo

[jaenicke]

Zitat von Mavarik:

Gibt es einen der so formatiert wie die Auto-Format Routine?
Klar, wenn die richtig funktionieren würde vielleicht...

Ja, mich z.B., und ich habe damit auch wenige Probleme. Das ist in aktuellen Versionen eigentlich nur noch die Einrückung hier:

Delphi-Quellcode:

type
  TExample = class
  private
  var
    FTest: string;
  end;

Da fehlt mir die Einrückung ab var. Ich kann aber auch immer schreiben private var usw., dann gibt es das Problem nicht. Einmal private hielte ich aber für schöner.

Aber seit anonyme Methoden usw. korrekt formatiert werden nutze ich die automatische Formatierung sehr oft zumal ich meistens ohnehin schon genauso formatiere und nur wenig oder gar nichts noch geändert wird.

Zitat von Rollo62:

Sondern so etwas:

Code:

Wolle_Schneiden()
Wolle_Kaemmen()
Wolle_Farbe_Get()

Das hört sich zwar womöglich unlogisch an, hilft aber die Methoden und Variablen sauber zu sortieren, so das oft schon im Namen eine Art "Klasse" entsteht.

Dann mache ich daraus auch eine Klasse...

[TRomano]

Sicherlich gibt es Entwickler, die erfolgreich sind & ihre Familien ernähren können, aber dennoch in den prozeduralen Ursprüngen des Pascals hängen geblieben sind.
Und unter anderem auch deshalb sieht man auch heute noch Projekte, wo Prozeduren/Funktionen gern mal 500 Zeilen haben. Antwort des Entwicklers/Teamleiters: "Läuft doch !".
Aber es kostet GELD ! Ist schwer wartbar, andere Entwickler brauchen mehr Zeit, um sich da einzuarbeiten usw. Vielleicht könnten diese "erfolgreichen" Entwickler noch erfolgreicher sein ?
Mir ging es darum, dass jeder seiner persönlichen Vorlieben in der Notation hat. Nach ca. 20 Projekt-Jahren ist es aber auch so, dass es in den Projekten die verschiedensten Vorgaben gibt. Dann ist es natürlich schwer sich ständig umstellen zu müssen.