Delphi-PRAXiS
Seite 4 von 5   « Erste     234 5      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Übergebenes nil erkennen? (https://www.delphipraxis.net/167926-uebergebenes-nil-erkennen.html)

Stevie 29. Apr 2012 02:16

AW: Übergebenes nil erkennen?
 
Zitat:

Zitat von MaBuSE (Beitrag 1163807)
Ich empfinde es auch als "Dokumentation" gut, wenn Variablen initialisert werden, und man sich nicht darauf verlässt, das es der Compiler schon richtig initalisieren wird. Das zeigt dass Du bewusst diesen Wert (in Deinem Fall nil) zugewiesen haben möchtest.

Dem muss ich widersprechen.

Für mich persönlich ist es sehr viel verwirrender, wenn ich sowas im Sourcecode sehe. Dann frag ich mich, ob hier entweder ein ahnungsloser am Werke war, oder ob es irgendein Problem gab, weswegen das gemacht wurde.

Genauso initialisier ich eine Variable nur dann, wenn deren Wert irgendwo benutzt wird, bevor ihr ein Ergebnis einer Operation zugewiesen wird. (Stichwort H2077 Value assigned to <variable> never used)

Furtbichler 29. Apr 2012 06:43

AW: Übergebenes nil erkennen?
 
Zitat:

Zitat von Stevie (Beitrag 1164108)
Für mich persönlich ist es sehr viel verwirrender, wenn ich sowas im Sourcecode sehe. Dann frag ich mich, ob hier entweder ein ahnungsloser am Werke war, oder ob es irgendein Problem gab, weswegen das gemacht wurde.

Beide Gedanken könntest Du dir abgewöhnen (und solltet Du vielleicht auch), denn nur weil der Code nicht deinem Geschmack entspricht, heißt das nicht, das ein Ahnungloser ab Werk war oder es ein Problem gab. Das ist so, als ob ein impressionistischer Künstler einem Expressionisten jegliche (handwerkliche) Fähigkeit abspricht. Etwas eng gefasst, die Sichtweise, wenn Du mich fragst.

Code soll selbstdokumentierend sein. Wenn Du eine Initialisierung nur für bestimmte Werte nicht vornimmst, dann musst Du das dem Leser erklären ("Im Falle von 0 macht das Delphi von ganz alleine"). Das wäre dann kein 'selbstdokumentierender' Code, sondern Code für Insider. Nicht gut, zumindest aus Sicht des Clean Code.

Ich muss allerdings zugeben, das hier für den Praktier ein Widerspruch zum "vermeide redundanten Code" oder einfach nur "quatsch nicht soviel" besteht.

Zitat:

Genauso initialisier ich eine Variable nur dann, wenn deren Wert irgendwo benutzt wird, bevor ihr ein Ergebnis einer Operation zugewiesen wird. (Stichwort H2077 Value assigned to <variable> never used)
Wer würde das nicht tun?

Stevie 29. Apr 2012 11:52

AW: Übergebenes nil erkennen?
 
Zitat:

Zitat von Furtbichler (Beitrag 1164113)
Zitat:

Zitat von Stevie (Beitrag 1164108)
Für mich persönlich ist es sehr viel verwirrender, wenn ich sowas im Sourcecode sehe. Dann frag ich mich, ob hier entweder ein ahnungsloser am Werke war, oder ob es irgendein Problem gab, weswegen das gemacht wurde.

Beide Gedanken könntest Du dir abgewöhnen (und solltet Du vielleicht auch), denn nur weil der Code nicht deinem Geschmack entspricht, heißt das nicht, das ein Ahnungloser ab Werk war oder es ein Problem gab. Das ist so, als ob ein impressionistischer Künstler einem Expressionisten jegliche (handwerkliche) Fähigkeit abspricht. Etwas eng gefasst, die Sichtweise, wenn Du mich fragst.

Wir reden hier eigentlich nicht von künstlerischer Freiheit.

In allen objektorientierten Sprachen, mit denen ich bisher gearbeite habe (eventuell ist es aber auch zu lang her, zuletzt nur mit Delphi und C#, also korrigier mich, wenn ich falsch liege) war es so, dass Felder von Objekten immer den Default Wert hatten und man nicht Explizit auf false, Leerstring, nil/null oder 0 setzen musste. Das ist auch eins der ersten Dinge, die ich einem Neuling sage, wenn er mit OOP anfängt. Daher ist überflüssiger Code keine Dokumentation für mich, sondern Code Bloat.


Zitat:

Zitat von Furtbichler (Beitrag 1164113)
Zitat:

Genauso initialisier ich eine Variable nur dann, wenn deren Wert irgendwo benutzt wird, bevor ihr ein Ergebnis einer Operation zugewiesen wird. (Stichwort H2077 Value assigned to <variable> never used)
Wer würde das nicht tun?

Ich hab nicht gezählt, wie viele Warnings und Hints (unter anderem der besagte) wir in unserem Source im letzten Jahr beseitigt haben, weil sich da scheinbar einige nicht dran gehalten haben in der Vergangenheit. ;)

MaBuSE 30. Apr 2012 10:52

AW: Übergebenes nil erkennen?
 
Zitat:

Zitat von Stevie (Beitrag 1164108)
Zitat:

Zitat von MaBuSE (Beitrag 1163807)
Ich empfinde es auch als "Dokumentation" gut, wenn Variablen initialisert werden, und man sich nicht darauf verlässt, das es der Compiler schon richtig initalisieren wird. Das zeigt dass Du bewusst diesen Wert (in Deinem Fall nil) zugewiesen haben möchtest.

Dem muss ich widersprechen.

Für mich persönlich ist es sehr viel verwirrender, wenn ich sowas im Sourcecode sehe. Dann frag ich mich, ob hier entweder ein ahnungsloser am Werke war, oder ob es irgendein Problem gab, weswegen das gemacht wurde.

Genauso initialisier ich eine Variable nur dann, wenn deren Wert irgendwo benutzt wird, bevor ihr ein Ergebnis einer Operation zugewiesen wird. (Stichwort H2077 Value assigned to <variable> never used)

Ich finde es schade, dass Du meine Aussagen nicht in den Kontext meiner Aussagen weiter oben in diesem Thread setzt.
(Das finde ich verwirrend :?)

Ich schrieb weiter oben:
Zitat:

Zitat von MaBuSE (Beitrag 1163558)
Grundsätzlich sollte ein Programmierer nie dem Compiler vertrauen und alle Variablen initialisieren.

Der Compiler gibt auch Warnungen beim Compilieren aus.
-> http://www.delphi-treff.de/tutorials...wirds-wichtig/

Versuche grundsätzlich Deine Anwendung so zu schreiben, dass keine Warnungen und Hinweise auftreten.

Ausnahme: Warnungen die Du selbst einbaust
Delphi-Quellcode:
{$message warn 'Hier muss ich noch mal genau prüfen !!!'}
oder
Delphi-Quellcode:
{$message hint 'TODO: Quellcode muss noch kommentiert werden, damit es auch ein anderer versteht ;)'}
.
Wenn Du Deinen Code immer sauber hällst, fallen solche eigenen Hinweise und Warnungen natürlich auf und animieren Dich das angemahnte auch zu tun.

Ich sagte es macht Sinn alle Variablen zu initialisieren, ich sagte nicht, man solle sie mehrfach initialisieren !!!

Delphi-Quellcode:
var
  i: Integer;
begin
  i := 0; // <- Das ist in diesem Falle Blödsinn
  // mach was ohne auf i zuzugreifen ...
  i := FunctionX(...); // <- das ist die initalisierung !!!
  if i = 0 then //...
  //...
end.
Lokale Variablen sind NICHT automatisch initialisiert (außer strings) !!! -> also sollte man das tun.
Bei globelen Variablen kannst Du ja folgendes (zur Dokumentation) verwenden:
Delphi-Quellcode:
var
  i: Integer = 0;
Ich empfinde das nicht als Werk eines Ahnungslosen, sondern als Dokumentation.
Abgesehen davon, dass man globale Variablen eh vermeiden sollte, muß sichergestellt werden, dass diese einen sinnvollen vordefinierten Wert haben.
Auch wenn wir wissen, dass es mit 0 initialisiert wird, sollte es für die, die es nicht wissen dokumentiert sein.

und ein
Delphi-Quellcode:
var i: Integer = 0;
ist kürzer als ein
Delphi-Quellcode:
var i: Integer; // ist mit 0 initialisert
;-)

Stevie 30. Apr 2012 11:43

AW: Übergebenes nil erkennen?
 
Zitat:

Zitat von MaBuSE (Beitrag 1164242)
Ich finde es schade, dass Du meine Aussagen nicht in den Kontext meiner Aussagen weiter oben in diesem Thread setzt.
(Das finde ich verwirrend :?)

Es ging um das "ich schreib es lieber hin, weil ich nicht darauf vertraue, dass der Speicher initialisiert ist".

MaBuSE 30. Apr 2012 12:16

AW: Übergebenes nil erkennen?
 
Zitat:

Zitat von Stevie (Beitrag 1164251)
Zitat:

Zitat von MaBuSE (Beitrag 1164242)
Ich finde es schade, dass Du meine Aussagen nicht in den Kontext meiner Aussagen weiter oben in diesem Thread setzt.
(Das finde ich verwirrend :?)

Es ging um das "ich schreib es lieber hin, weil ich nicht darauf vertraue, dass der Speicher initialisiert ist".

Ja, aber ein Satz weiter steht doch, dass ein Programm KEINE Hinweise & Warnungen enthalten soll.
Damit ist doch klar, das Doppelt-Initialisierungen damit nicht gemeint sind.

[edit]
Wenn es dokumentiert ist, das der Compiler das so macht, ist das OK.
Wenn Du Dir nicht sicher bist, das der Compiler das so macht, initialisierte selbst.
Ein ich habe es ausprobiert und der Compiler hat es so initialisiert, finde ich nicht ok. (undokumentiertes Verhalten, kann sich ja auch in der nächsten Compiler Version ändern)
Bzw.: Bei Deinem Test einer lokalen Variable i: Integer ist zufällig 0 enthalten. Daraus kannst Du nicht schließen, dass es immer 0 ist.
Lokale Variablen werden NICHT initialisiert, das ist dokumentiert !!!
[/edit]

DeddyH 30. Apr 2012 12:19

AW: Übergebenes nil erkennen?
 
Werden wir jetzt nicht ein wenig zu sehr OT? :roll:

MaBuSE 30. Apr 2012 12:48

AW: Übergebenes nil erkennen?
 
Zitat:

Zitat von DeddyH (Beitrag 1164261)
Werden wir jetzt nicht ein wenig zu sehr OT? :roll:

Nicht direkt,
das Problem des Fragestellers ist ja, dass eine Variable, die nicht initialisiert wurde, nicht mit 0 (nil) initialisiert war.
Wenn er in der Create diese Variablen mit nil initialisiert funktioniert es.
Das hat er ja selbst geschrieben.
Wobei es sich bei seine Variablen um Objektinstanzdaten (Felder) handelt, die eigentlich mit 0 initialisiert werden sollten.
Sie es aber aus welchem Grund auch immer nicht sind. -> selbst initialisieren ist in diesem Fall also durchaus OK :lol:

In der Hilfe steht:
ms-help://embarcadero.rs_xe/rad/Variablen.html
Wenn Sie eine globale Variable nicht explizit initialisieren, wird sie vom Compiler mit 0 initialisiert. Objektinstanzdaten (Felder) werden auch mit 0 initialisiert. Auf der Wiin32-Plattform ist der Inhalt von lokalen Variablen so lange undefiniert, bis ein Wert zugewiesen wird.

mkinzler 30. Apr 2012 12:54

AW: Übergebenes nil erkennen?
 
Das gilt aber nicht für lokale Variablen und Feldern von Klassen (wie in diesem Fall). Hier sollte man immer initialisieren

himitsu 30. Apr 2012 13:07

AW: Übergebenes nil erkennen?
 
Zitat:

Wenn Sie eine globale Variable nicht explizit initialisieren, wird sie vom Compiler mit 0 initialisiert. Objektinstanzdaten (Felder) werden auch mit 0 initialisiert. Auf der Win32-Plattform ist der Inhalt von lokalen Variablen so lange undefiniert, bis ein Wert zugewiesen wird.
Globale und Objekt-Felder
Lokale


Alle Zeitangaben in WEZ +1. Es ist jetzt 18:33 Uhr.
Seite 4 von 5   « Erste     234 5      

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