AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Übergebenes nil erkennen?

Ein Thema von solus · begonnen am 25. Apr 2012 · letzter Beitrag vom 30. Apr 2012
Antwort Antwort
Seite 4 von 5   « Erste     234 5      
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.027 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#31

AW: Übergebenes nil erkennen?

  Alt 29. Apr 2012, 03:16
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)
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#32

AW: Übergebenes nil erkennen?

  Alt 29. Apr 2012, 07:43
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?
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.027 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#33

AW: Übergebenes nil erkennen?

  Alt 29. Apr 2012, 12:52
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:
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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie (29. Apr 2012 um 16:08 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von MaBuSE
MaBuSE

Registriert seit: 23. Sep 2002
Ort: Frankfurt am Main (in der Nähe)
1.840 Beiträge
 
Delphi 10 Seattle Enterprise
 
#34

AW: Übergebenes nil erkennen?

  Alt 30. Apr 2012, 11:52
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:
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 {$message warn 'Hier muss ich noch mal genau prüfen !!!'} oder {$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 var i: Integer = 0; ist kürzer als ein var i: Integer; // ist mit 0 initialisert
(°¿°) MaBuSE - proud to be a DP member
(°¿°) MaBuSE - proud to be a "Rüsselmops" ;-)
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.027 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#35

AW: Übergebenes nil erkennen?

  Alt 30. Apr 2012, 12:43
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".
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Benutzerbild von MaBuSE
MaBuSE

Registriert seit: 23. Sep 2002
Ort: Frankfurt am Main (in der Nähe)
1.840 Beiträge
 
Delphi 10 Seattle Enterprise
 
#36

AW: Übergebenes nil erkennen?

  Alt 30. Apr 2012, 13:16
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]
(°¿°) MaBuSE - proud to be a DP member
(°¿°) MaBuSE - proud to be a "Rüsselmops" ;-)

Geändert von MaBuSE (30. Apr 2012 um 13:24 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.625 Beiträge
 
Delphi 12 Athens
 
#37

AW: Übergebenes nil erkennen?

  Alt 30. Apr 2012, 13:19
Werden wir jetzt nicht ein wenig zu sehr OT?
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
  Mit Zitat antworten Zitat
Benutzerbild von MaBuSE
MaBuSE

Registriert seit: 23. Sep 2002
Ort: Frankfurt am Main (in der Nähe)
1.840 Beiträge
 
Delphi 10 Seattle Enterprise
 
#38

AW: Übergebenes nil erkennen?

  Alt 30. Apr 2012, 13:48
Werden wir jetzt nicht ein wenig zu sehr OT?
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

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.
(°¿°) MaBuSE - proud to be a DP member
(°¿°) MaBuSE - proud to be a "Rüsselmops" ;-)
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.861 Beiträge
 
Delphi 11 Alexandria
 
#39

AW: Übergebenes nil erkennen?

  Alt 30. Apr 2012, 13:54
Das gilt aber nicht für lokale Variablen und Feldern von Klassen (wie in diesem Fall). Hier sollte man immer initialisieren
Markus Kinzler
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.184 Beiträge
 
Delphi 12 Athens
 
#40

AW: Übergebenes nil erkennen?

  Alt 30. Apr 2012, 14:07
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
$2B or not $2B
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 4 von 5   « Erste     234 5      


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 00:29 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