AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Tutorials Code Smells

Code Smells

Ein Tutorial von Coffeecoder · begonnen am 5. Mai 2011 · letzter Beitrag vom 11. Jan 2012
Antwort Antwort
Seite 3 von 4     123 4   
Benutzerbild von Coffeecoder
Coffeecoder
Registriert seit: 27. Apr 2011
Hallo DP-Mitglieder,

Ich habe ein kleinen Kurs über das Thema "Code Smells" für euch vorbereitet.
Das Ziel dieses Kurses ist das Verstehen was "Code Smells" sind. Denn jeder Programmierer hat (unbewusst) solche in seinem Code.

Theorie:

Das Wort "Code Smells" was übersetzt "(schlechter) Geruch" heißt,
stammt von Kent Beck und wurde durch das Buch Refactoring von Martin Fowler verbreitet.

Code Smells ist ein schlecht strukturierter Programmcode.
Der Code ist für den oder einen anderen Programmierer schwer zu verstehen.

Bei Verbesserungen oder Erweiterungen kommen neue Fehler dazu.
"Code Smells" wird erst erkannt bei einer Überarbeitung des Programmcodes.


Welche "Code Smells" existieren?

Es gibt eine Unmenge von schlecht-struktierter Programmcode-Beispiele.
Hier einige Beispiele die sich auf die objektorientierte Programmierung (Java, Delphi, ...) beziehen:
  1. Code-Vermehrung: Der identische Code taucht im Programm an mehreren Stellen auf.
  2. Langer Code in Methode: Der Programmcode in einer Funktion, Prozedur ist zu lang.
  3. Lange Parameterliste: einige übergebene Parameter die unnötig sind.
  4. Nichtaussagender Name: Aussagekräftige Name erfüllen das Verständnis des Codes oder Inhalt einer Variable.
  5. Toter Code: Ein Programmcode welches nicht mehr gebraucht wird.
Quelle : http://de.wikipedia.org/wiki/Code_smells

Natürlich gibt es noch mehrere Arten und interessante Bücher die das Thema detaillierter
beschreiben wie z.B das Buch : "Clean Code - Refactoring, Patterns, Testen und Techniken für sauberen Code" von Robert C. Martin.

Beispiele/Tipps:
  1. "Code-Smell"
    Delphi-Quellcode:
    procedure anpassenChart;
    begin
                    with Chart1 do
                    begin
                           Legend.visible := false;
                           View3D := false;
                           Title.Text.Clear;
                           Title.Text.Add('Chart');
                    end;

                    with Chart2 do
                    begin
                           Legend.visible := false;
                           View3D := false;
                           Title.Text.Clear;
                           Title.Text.Add('Chart');
                    end;

                    with Chart3 do
                    begin
                           Legend.visible := false;
                           View3D := false;
                           Title.Text.Clear;
                           Title.Text.Add('Chart');
                    end;
    end;
    Es ist nicht falsch, der Code funktionniert ja. Aber was ist schlecht daran?
    Ganz einfach: Es sollen jetzt doch Legende visible sein. Was macht man?
    Legend.visible := true setzen und Copy-Paste.
    Das ist anfällig für Fehler, einmal nicht aufgepasst und schon ein Legend.visible := false vergessen zu überschreiben.

    So macht man es besser:
    Delphi-Quellcode:
    procedure anpassenChart(ch : TChart);
    Begin
                    with ch do
                    begin
                          Legend.visible := false;
                          View3D := false;
                          Title.Text.Clear;
                          Title.Text.Add('Chart');
                    end;
    end;
    Aufruf:
    Delphi-Quellcode:
    ...
    var i : integer;
    begin
            for i := 1 to 3 do anpassenChart('Chart'+IntToStr(i));
    end;
  2. und
  3. Beide Punkten sind verwandt, denn es geht ja um Methoden (Funktion, Prozedur).
    Hier zeige ich kein Beispiel, aber ein paar Tipps:
    1. Kurze Parameterliste, welche für eine einzige Aufgabe gebraucht werden.
    2. Es sollen nicht mehr als 20 Programmzeilen in einer Methode stehen.
    3. Eine Methode soll nur eine Aufgabe erfüllen. (eine Funktion die den Flächeninhalt eines Kreises berechnet, soll nicht noch den Umfang berechnen, dies sollte in einer separaten Funktion untergebracht werden.)
  4. Ich komme sofort zu einem Beispiel:

    Schlechter Name:

    Delphi-Quellcode:
    var
         d : integer;
    begin
           ...
           if d ...
    end;
    Was will die Variable d uns sagen? Nicht viel!

    Besser:

    Delphi-Quellcode:
    ...
    var
         TageSeitErstellung : integer;

    begin
          ...
          if TageSeitErstellung ....

    end;
    Hier sagt die Variable TageSeitErstellung uns der Zweck dieser Variable aus. Man weiss sofort, der Inhalt ist die Anzahl Tage seit der Erstellung von ...

    Noch ein typisches Beispiel mit dem Typ boolean:

    Delphi-Quellcode:
    var
          Daten : boolean;
    Daten sagt wieder nichts aus. Man kann es so verstehen:
    1. DatenGeLoescht
    2. DatenVorhanden
    3. DatenGesendet
    4. DatenVerarbeitet
    5. DatenKorrupt
    6. ...

  5. Toter Code ist :
    1. Ein auskommentierter Code
    2. Ein Codestück welches immer übersprungen wird. Hier ist die if-Anweisung überflüssig:
      Delphi-Quellcode:
      var
        N : int;

      begin
              N := 0;
              ...
              if N = 3 then
              begin
                   ....
              end;
              ...
      end;

Schlusswort:

Kennt man einige Code-Smells, so kann man diese vermeiden, damit der Programmcode nicht "schlecht riecht".

Ich hoffe ich könnte euch ein bisschen über dieses interessante Thema erzählen.
Bitte um konstruktive Kritik.

Danke bis Bald.

Mfg Coffeecoder
Coffeecoder

Geändert von Coffeecoder ( 6. Mai 2011 um 18:43 Uhr) Grund: Ich wurde gebeten, noch einige Beispiele und Tipps zu den Punkten zu zeigen.
 
Benutzerbild von bernau
bernau

 
Delphi 11 Alexandria
 
#21
  Alt 11. Jan 2012, 09:34
Delphi-Quellcode:
procedure anpassenChart(pchart : TChart);
Begin
    ....
end;
Der Präfix P erweckt aber eher den Eindruck, es handle sich um einen Zeiger auf ein TChart. Wieso nicht einfach Chart, AChart oder meinetwegen TheChart?
Daran habe ich auch zuerst gedacht. Aber letztendlich ist es ein Zeiger auf ein Objekt vom Type TChart. Sieht trotzdem schrecklich aus
  Mit Zitat antworten Zitat
Klaus01

 
Delphi 10.4 Sydney
 
#22
  Alt 11. Jan 2012, 09:56

Daran habe ich auch zuerst gedacht. Aber letztendlich ist es ein Zeiger auf ein Objekt vom Type TChart. Sieht trotzdem schrecklich aus
Wenn man das dann zuende denkt- dan wäre ja jede Klasseninstanz auch schlichtweg "nur" ein Pointer.

Grüße
Klaus
Klaus
  Mit Zitat antworten Zitat
Benutzerbild von bernau
bernau

 
Delphi 11 Alexandria
 
#23
  Alt 11. Jan 2012, 10:03

Daran habe ich auch zuerst gedacht. Aber letztendlich ist es ein Zeiger auf ein Objekt vom Type TChart. Sieht trotzdem schrecklich aus
Wenn man das dann zuende denkt- dan wäre ja jede Klasseninstanz auch schlichtweg "nur" ein Pointer.

Grüße
Klaus
Ja. Ist es.
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

 
Delphi 11 Alexandria
 
#24
  Alt 11. Jan 2012, 10:05
Somit wäre dann aber ein PObject ein Pointer auf einen Pointer. Unschön, wenn nicht irgendwie beabsichtigt.
Detlef
  Mit Zitat antworten Zitat
Benutzerbild von bernau
bernau

 
Delphi 11 Alexandria
 
#25
  Alt 11. Jan 2012, 10:11
Somit wäre dann aber ein PObject ein Pointer auf einen Pointer. Unschön, wenn nicht irgendwie beabsichtigt.
So kann man es aus sehen. Das wäre sogar die richtige Interpretation. Daher auf keinen Fall ein p als Präfix für ein instanziertes Objekt. Verwirrt nur.
  Mit Zitat antworten Zitat
Benutzerbild von Coffeecoder
Coffeecoder

 
Delphi 6 Enterprise
 
#26
  Alt 11. Jan 2012, 10:21
Somit wäre dann aber ein PObject ein Pointer auf einen Pointer. Unschön, wenn nicht irgendwie beabsichtigt.
So kann man es aus sehen. Das wäre sogar die richtige Interpretation. Daher auf keinen Fall ein p als Präfix für ein instanziertes Objekt. Verwirrt nur.
Ich ändere dies in der neuen Version zu "achart".
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

 
Delphi 12 Athens
 
#27
  Alt 11. Jan 2012, 10:38
Für mich sind Parameter mit Präfix einfach nur häßlich.

Typen mit T, Pointertypen mit P, Interfacetypen mit I, sowie Fields/Felder mit F, sind ja vollkommen OK,
aber Property- und Parameternamen auch noch verschandeln?



Aber wenn man schon soeinen Scheiß macht, dann sollte man das dann auch komplett durchzuiehen.

Globale Variablen mit G, Lokale mit L, die Parameter/Argumente mit A, Constanten mit C und für die Property oder die Klassenvariablen (Class Var) fällt uns bestimmt auch noch was ein.
Eventuell noch die nicht ganz "globalen" Variablen innerhalb der Implementation noch mit einem V davor

Und zum Schluß überall noch den kranken ungarischen Dreck davor.



Am Ende überlegt man sich das nameXCamelCase dann nochmal, findet es nun ebenfalls Scheiße und wechselt zu KA_WIE_DAS_HEISST.









Wer unbedingt will, kann intern ja eine Umleitung einrichten.
Delphi-Quellcode:
procedure MeineProzedur(MeinParameter: MeinTyp);
var
  Argument_MeinParameter: MeinTyp absolute MeinParameter;
begin
  if Argument_MeinParameter = 0815 then

end;

Geändert von himitsu (11. Jan 2012 um 10:44 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Coffeecoder
Coffeecoder

 
Delphi 6 Enterprise
 
#28
  Alt 11. Jan 2012, 10:42
Es sind noch immer (nur) Konventionen
[OT] In Java macht folgendes mit den Parameterübergabe:
Code:
...

public void setName(String name) {
       this.name = name;
}
Ohne Präfix
[/OT]
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

 
Delphi 12 Athens
 
#29
  Alt 11. Jan 2012, 10:46
[OT] Das mach ich in Delphi genauso.
  Mit Zitat antworten Zitat
Benutzerbild von bernau
bernau

 
Delphi 11 Alexandria
 
#30
  Alt 11. Jan 2012, 10:47
Du wirst lachen, aber lokale Variablen fangen bei mir tatsächlich mit (einem kleinen) L an. Wobei das nich ganz optimal ist, da man das "l" mit einer "1" (in Worten "Eins") verwechseln kann. Gibt auch einige Styleguides die das bemängeln. Da bei mir aber keine Variable mit einer Ziffer anfängt, kann ich das verschmerzen. Parameter/Argumente bekommen immer ein kleines "a". Hat den Vorteil, daß ich immer sehe, welche Variable lokal ist und welche von aussen kommt.
  Mit Zitat antworten Zitat
Themen-Optionen Tutorial durchsuchen
Tutorial durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:47 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz