Sauberes Programmieren

freedy · Beiträge: 403 Erhaltene Danke: 1 Winows 7 Delphi XE

Hallo Forum!

Ich habe zwar schon probiert, einen Artikel über die Suche zu finden, hab aber leider keine Treffer erzielt.

Ich verwende Funktionen, die Variablen übergeben bekommen. Nehmen wir einfach mal an, die Funktion xy bekommt drei Variablen:

xy(a, b, c);

Mit den Werten a und c muss ich auch sonst umgehen. Die Variable b hingegen ist nur ein Dummy, damit ich die Funktion bzw. Prozedur ausführen kann.

Natürlich meldet Delphi beim Compilieren:
[Hinweis] dateiname.pas(218): Auf 'b' zugewiesener Wert wird niemals benutzt

Wie löst ihr solche Probleme?
freedy

PS: Die Prozedur xy() kann ich leider nicht umschreiben, weil b manchmal auch nicht als Dummy fungiert.

MrSaint · Verfasst: Mo 25.10.04 13:30

Also wenn du den Parameter "b" auch nur manchmal brauchst, kannst du daran nix optimieren... Lass den Compiler einfach meckern, das geht net besser...

MrSaint

_________________
"people knew how to write small, efficient programs [...], a skill that has subsequently been lost"
Andrew S. Tanenbaum - Modern Operating Systems

jasocul · Verfasst: Mo 25.10.04 13:42

Diese Compiler-Meldungen kannst du in die Tonne treten.
Sobald du mit Try-Except-Blöcken arbeitest, fängt der Compiler noch mehr an rumzuspinnen. Bemängelt dann Variablen, die gar nicht benutzt werden, obwohl das einfach falsch ist.

freedy · Beiträge: 403 Erhaltene Danke: 1 Winows 7 Delphi XE

Aber macht das Sinn, alles in die Tonne zu kloppen? Hm... *grübel*
Wir versuchen halt, unser Projekt möglichst sauber und nach Delphi-StyleGuide zu proggen.
D.h. für uns:
- keine Hinweise
- keine Warnungen
- keine Fehler (klar, sonst würd's ja nicht zu compilieren sein)

Gruß
freedy

jasocul · Verfasst: Mo 25.10.04 14:26

Es spricht nichts dagegen, die Hinweise zu prüfen. Nur stimmen die halt nicht immer.
Ansonsten kann ich nur empfehlen, die Prozeduren so zu halten, dass du von vornherein den Überblick behältst.

Stübi · Verfasst: Mo 25.10.04 14:30

Bei uns gilt auch ganz klar die Regel Keine Hinweise und Warnungen, jedoch ist das Firmenintern und ich darf auch nur Englische coments geben :cry:

Wie du das für die handhaben willst musste selbst wissen.

Gruss Stübi

_________________
Neun von zehn Stimmen in meinen Kopf sagen, dass ich nicht verrückt sei. Die zehnte summt die Tetrismelodie.

Motzi · Verfasst: Mo 25.10.04 14:45

Also in 98% aller Fälle sind Warnungen und Hinweise durchaus gerechtfertigt. Sollte es dennoch mal passieren, dass der Compiler einen Fehler/eine Warnung ausgibt obwohl man genau weiß, dass diese an dieser Stelle überflüssig ist, so kann man die Hinweise und Warnungen per Compiler-Schaltern an diesen Stellen deaktivieren. Siehe dazu in der OH unter $HINTS bzw $WARNINGS

_________________
gringo pussy cats - eef i see you i will pull your tail out by eets roots!

jasocul · Verfasst: Mo 25.10.04 14:46

Ich geb euch jetzt mal ein Beispiel:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:

  try
    Screen.Cursor := crHourGlass;
    sl := TStringList.Create;
...
  finally
    Screen.Cursor := crDefault;
    sl.Free;
  end;

Da bekomme ich eine Warnung, dass die Variable sl nicht initialiert wurde.
Soll ich sowas ernst nehmen???

Motzi · Verfasst: Mo 25.10.04 14:49

Das hat einen ganz einfachen Grund... was passiert, wenn VOR der Zeile:

markieren

Delphi-Quelltext

1:	sl := TStringList.Create;

eine Exception auftritt? Richtig, er geht weiter in den finally-Teil und in diesem Fall wäre sl definitiv nicht initialisiert. Daher erzeugt man normalerweise zuerst das Objekt und öffnet erst dann den try-finally Block.

_________________
gringo pussy cats - eef i see you i will pull your tail out by eets roots!

.Chef · Beiträge: 1112

Ich versuch ja auch immer, alles ohne Meldungen hinzukriegen. Aber zum Beispiel habe ich öfters "Combining signed and unsigned values. Widened both operants." (oder so). Unter einigem Aufwand würde man diese Meldungen zwar wegkriegen, aber der Übersichtlichkeit des Codes ist nicht geholfen, wenn man z.B. um jedes Length() noch ein Cardinal() schreibt.

Gruß,
Jörg

_________________
Die Antworten auf die 5 häufigsten Fragen:
1. Copy(), Pos(), Length() --- 2. DoubleBuffered:=True; --- 3. Application.ProcessMessages bzw. TThread --- 4. ShellExecute() --- 5. Keine Vergleiche von Real-Typen mit "="!

heinze · Beiträge: 112 XP D4 Prof

Mal kleiner Anfängeridee

markieren

Quelltext

1:
2:
3:

b:=b+1-1;
//oder am schlus der function 
b:=0;

_________________
Für Fehler haftet die Tastatur bzw Für Gramatik ist meine legasthenie zu verklagen sonstige Verbesserungsvorschläge meiner Text bitte per pn an mich

freedy · Beiträge: 403 Erhaltene Danke: 1 Winows 7 Delphi XE

jasocul hat folgendes geschrieben:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:

  try
    Screen.Cursor := crHourGlass;
    sl := TStringList.Create;
...
  finally
    Screen.Cursor := crDefault;
    sl.Free;
  end;

deshalb würde ich das auch so schreiben:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

  sl := TStringList.Create;
  try
    Screen.Cursor := crHourGlass;
  
...
  finally
    Screen.Cursor := crDefault;
    sl.Free;
  end;

Er erreicht auf jeden Fall den finally-Block. Von daher gibt es auch keine Fehlermeldung.

jasocul · Verfasst: Mo 25.10.04 14:58

Es sei denn, ich bekomme einen Fehler bei Create.

jojo-sp · Verfasst: Mo 25.10.04 15:08

Das läuft auf ein Zeit paradoxon hinaus, man kann die Vergangenheit nicht verändern! :-)

Aber ich hab auch so ein paar nette hinweise. Ich habe die Variable Hres lokal initialisiert, sie wird aber als "[Warnung] MainUnit.pas(76): Variable 'HRes' wurde wahrscheinlich nicht Initialisiert" ausgespuckt.

_________________
Ist der Ruf erst ruiniert, lebts sich gänzlich ungeniert...
Wilhelm Busch (1832 - 1908)

uall@ogc · Verfasst: Mo 25.10.04 15:09

dann macht man da sauch so:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

 s1 := nil;
 try 
    Screen.Cursor := crHourGlass; 
    sl := TStringList.Create; 
... 
  finally 
    Screen.Cursor := crDefault; 
    if assigned(s1) then sl.Free; 
  end;

jasocul · Verfasst: Mo 25.10.04 15:12

Das wäre dann wirklich die sauberste Lösung.

freedy · Beiträge: 403 Erhaltene Danke: 1 Winows 7 Delphi XE

Die Lösung von uall@ogc ist auf jeden Fall kleverer als meine... dann werde ich wohl heute mal eine Extraschicht einlegen müssen. :wink:

Ich bin ja bisher immer davon ausgegangen, dass Fehler, die in einem Create passieren, dort auch abgefangen werden. Klar, meine Prozedur läuft dann auch schief. Macht also Sinn.

Gruß
freedy

Nagelbrett · Beiträge: 75

wobei man sich das if Assigned(sl) .. im finally dann auch sparen kann, da bei Aufruf von Free sowieso auf nil geprüft wird und es dann ja doppelt gemoppelt wäre

uall@ogc · Verfasst: Mo 25.10.04 15:48

hm jo

Motzi · Verfasst: Mo 25.10.04 19:39

3 Sachen: erstens überprüft Free (wie bereits erwähnt) intern sowieso ob der Self-Pointer nil ist, zweitens liefert ein Konstruktor sowieso nil zurück wenn eine Exception auftritt und 3tens was für ein Objekt willst du im finally-Teil freigeben wenn dieses gar nicht erst erstellt wurde weil eine Exception im Konstruktor aufgetreten ist?

Wenn es dir also darum geht auf Exceptions im Konstruktor zu reagieren müsste es so ausschaun:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:

  try
    aObject = TMyClass.Create(..);
    try
      ...
    finally
      aObject.Free;
    end;
  except
    .. // auf Exception von Konstruktor reagieren
  end;

_________________
gringo pussy cats - eef i see you i will pull your tail out by eets roots!

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme