EMB DCE 12 - Bedingungen mit einen Assign-Zeichnen

[paule32.jk]

Hallo,
ich habe mich schon öfters gefragt, warum bei Delphi Bedingungen/Condition's und Vergleichen der rechte Wert mit einen Assign-Zeichen (also dem ist-gleich = Zeichen) eingeleitet wird.

Für mich macht es mehr Sinn:

Delphi-Quellcode:

if foo == 42 then...

zu schreiben als:

Delphi-Quellcode:

if foo = 42 then ...

weil das if foo = 42 doch sehr nach Zuweisung und nicht gerade nach Vergleich anmutet.
Sind da Pläne bekannt, das zu ändern - oder ist das Historisch bedingt ?
ich mein... Alles Neu macht der Mai ...

[Rollo62]

Zitat:

Zitat von paule32.jk (Beitrag 1542012)

Hallo,
ich habe mich schon öfters gefragt, warum bei Delphi Bedingungen/Condition's und Vergleichen der rechte Wert mit einen Assign-Zeichen (also dem ist-gleich = Zeichen) eingeleitet wird.

Das ist wohl der Ur-Pascal Syntax geschuldet, mach Dir keine Hoffnung auf Änderung :-D

[Uwe Raabe]

Unter Pascal ist das "=" eben kein Assign-Zeichen, sondern ein Vergleichszeichen. Zum Assign verwendet man ":=".

Aber tröste dich, wenn man von Pascal kommt, dann sieht C halt einfach nur falsch aus.

[Rollo62]

Zitat:

Zitat von Uwe Raabe (Beitrag 1542015)

.. dann sieht C halt einfach nur falsch aus.

Soweit würde ich jetzt aber auch nicht gehen :-D

[freimatz]

Ich schon. Ich kam von der Schule und da gab es nur "=". Ich fand das ":=" komisch und auch das ":=". :-D

[himitsu]

Wobei grade in C-Sprachen dieser Mist viele Probleme bereitet hat.

Logisch und Syntaktisch finde ich = garnicht schlecht.
Es entspricht auch dem, was man im Matheunterricht mal gelernt hat.

Zitat:

Delphi-Quellcode:

if (i = 132) {

Und dann wurde später in Editoren eingebaut, dass es hier eine Warnung gibt, weil man vermutlich == machen wollte, es aber dennoch der Syntax entsprach,
denn so wird erstmal die Variable überschrieben und es ergibt auch immer True.

In nicht tysicheren C-igen kann man auch gern sowas bekommen. :lol:
1 + 1 = 11
1 - 1 = 0

[Rollo62]

Zitat:

Zitat von freimatz (Beitrag 1542019)

Ich schon. Ich kam von der Schule und da gab es nur "=". Ich fand das ":=" komisch und auch das ":=". :-D

und wie findest Du "==", "===", "!=", "!==", "<>" "is" ?
Ist auch alles nicht besser :stupid:

Mit würde auch "=" "==" und "!=" reichen, aber die Welt ist halt komplexer :-D

[paule32.jk]

also rein logisch und mathematisch bedeutet ja = eine Zuweisung - zum Beispiel für Variablen:
v = 2.
C = v + v.
C = 2 + 2.
C = 4.

dann gibt es noch =/= was in C/C++ != oder in Pascal <> bzw. >= or <= entspricht.
Ein:

if (var = 2) würde in C oder vielen anderen Programmiersprachen logisch "wahr" (1) ergeben,
weil zuerst der Variablen "var" der Wert 2 zugewiesen wird und die IF-Klausel dann schaut, ob der Wert der Variablen var 0 oder größer 0 ist.
Und alles was größer 0 ist (was hier der Fall ist) wird als 1 - also wahr gemätscht bzw. ausgewertet.
Das kann gefährlich werden wenn zum Beispiel auf EOF und/oder \0 geprüft werden soll.
Weil \0 zugleich das terminierende End-Byte ist - by C-Zeichketten (Pchar) wie auch beim erreichen der EOF Marke.
Beide Zeichen (also \0) haben dann unterschiedliche Bedeutungen.
Im Ascii-Zeichensatz entspricht dann \0 das lachende Smily-Zeichen, das man mit einen DOS-Eingabe-Hex-Editor zu Gesicht bekommt, wenn mit einen Hex-Editor das binäre Image einer executable betrachtet (sofern die Codepage auch auf ASCII oder UTF-8 gestellt ist).
Manche Hex-Editoren stellen auch einfach ein Leerzeichen dar - was dann auch gut verwechselt werden kann mit dem Leerzeichen 32 dez. oder 20 hex.
Dann gibt es auch noch die geniale Idee von Null-Feldern (zum Beispiel in Datenbankprogrammen)...

[dummzeuch]

Diskutieren wir jetzt ernsthaft darüber, warum Delphi/Pascal anders ist als C/C++/Java ... ?

Dann kann man auch darüber diskutieren, warum in Pascal/Delphi/C/C++ eine Einrückung keine Bedeutung hat, wo sie doch in COBOL und Python so wichtig sind.

Will sagen: So eine Diskussion ist absolut sinnlos.

[Rollo62]

Zitat:

Zitat von dummzeuch (Beitrag 1542029)

Will sagen: So eine Diskussion ist absolut sinnlos.

:thumb:

[himitsu]

Schade, dass man in Pascal/Delphi keine eigenen Operatoren definieren kann. (in C++ geht sowas)

Sonst könnte man sich eigene "weitere" Operatoren basteln (so lange sie nicht mit der restlichen Pascal-Syntax kollidieren).

So können wir nur bestehende Operatoren anpassen. (Record-Operatoren).
Wobei dort teilweise zwischen binär und logisch unterschieden wird, was es im Pascal so aber "garnicht" gibt, da das nicht über den Operator, sondern anhand der Typen entschieden wird.

[paule32.jk]

man muss sich vieleicht vor Augen halten, das Pascal als Lehrsprache entwickelt wurde (vom Herrn Wirth).
Das dann eine angestaubte Entwicklungssprache draus werden sollte hatte er damals sicherlich nicht gedacht.

Und als Programmierer sollte man sowie mindestens zwei Sprachen können - so wie Deutsch und Englisch.
Weil ja das meiste für global Trottler geschrieben wurde, damit die Verständigung untereinander besser veranstaltet werden kann.
Denn was nützt denn Einem das beste Tool, wenn die Beschreibung auf Schienäesisch rückwärts geschrieben wurde und der arme User nur Deutsch oder Englisch kann.

Ist ja wie in anderen Berufszweigen genauso: Arzt => Latein.

[DeddyH]

Um es mal mit Sascha Grammel zu sagen:

Zitat:

Was für ein sinnloses Gespräch!

[Uwe Raabe]

Zitat:

Zitat von paule32.jk (Beitrag 1542028)

rein logisch und mathematisch bedeutet ja = eine Zuweisung

Um das mal einem Faktencheck zu unterziehen: Das bedeutet es weder logisch noch mathematisch. In beiden Fällen wird es als Vergleichsoperator verwendet. Nicht umsonst wird es Gleichheitszeichen genannt.

In dieser Tabelle sind die Logischen Operatoren nach Kontext aufgeführt. Man beachte Mathematik, Delphi, Pascal und Visual Basic.

Für die Mathematik siehe hier: https://de.wikipedia.org/wiki/Liste_...chheitszeichen

[TomyN]

Drum verstehe ich die Matheaufgaben, die aktuell in der Schule gestellt werden, kaum noch.
Da heisst es dann 'Wird abgebildet auf', 'geht über in' oder aus dem '=' wird ein ->
Ich persönlich finde die 'Notation' in Delphi deutlich klarer als z.B. in Java.

[himitsu]

Mathe ist doch eh nur noch 'ne sinnlose Beschäftigungstherapie und wird zum Lernen des Auswändiglernens misbraucht.

einmaleins bis 100
'ne Sache, wo tausende Bäume sinnlos für sterben
und wofür man heute doch nur 4 Zahlen in Excel eingibt, zwei Mal klickt und draggt und fertig ist.

Wenn 3 Leute in einem Raum sind und 5 gehn raus, dann müssen 2 wieder rein, damit niemand mehr drin ist.

Statt das Hirn mit nutzlosen Dingen zu überfüllen, wo dann scheinbar politische Bildung und Sozialkompetenz keinen Platz mehr haben,
man stattdessen vielleicht besser dieses Kopfrechnen üben sollte, oder das mit den Fingern ... Araber zählen mit 2 Händen bis 60 (mit 4 bis 3600) und Computernerds locker bis 1023 (1048575).


Wo es bei uns damals noch hieß, dass jetzt alle verdummen, weil ohne Taschenrechner niemand mehr rechnen kann.
Dann gab es Handies und Google ... alle verdummen, weil niemand mehr was wissen muß. (nur blöd, wenn in der Schule der Umgang damit nicht geleert wurde)
egal ... jetzt gibt es ChatGPT :stupid:

[Rollo62]

Zitat:

Zitat von himitsu (Beitrag 1542047)

Mathe = Lernen des Auswändiglernens

So einfach :gruebel: coool

[dummzeuch]

Zitat:

Zitat von himitsu (Beitrag 1542047)

Mathe ist doch eh nur noch 'ne sinnlose Beschäftigungstherapie und wird zum Lernen des Auswändiglernens misbraucht.

Wenn ich mir ansehe/höre, wie viele meiner Mitmensch*innen sagen, sie hätten Mathe nie verstanden und auch nie gebraucht, und auch noch stolz darauf sind, wundert mich nicht, dass Deutschland im IT-Bereich keinen Spitzenplatz belegt.

Aber gut, die sollen dann halt Influencer werden, da werden sie bestimmt reich bei (Das denken anscheinend 40% der 14-16 Jährigen, hat gestern in der Glotze ein Comedian behauptet. Kann natürlich sein, dass er sich die Zahl nur ausgedacht hat.).

Das 1x1 bis 10 auswendig zu lernen ist durchaus sinnvoll als Grundlage für's Kopfrechnen. Das wiederum ist sinnvoll, um Ergebnisse überschlagen zu können, was wichtig ist, wenn man Berechnungen auf Plausibilität überprüfen will. Das wiederum ist in vielen Lebenslagen hilfreich, sei es beim Einkaufen oder der Geldanlage, oder auch bei der Softwareentwicklung.

Klar, man kommt auch ohne durch's Leben, irgendwie.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1542047)

Mathe ist doch eh nur noch 'ne sinnlose Beschäftigungstherapie und wird zum Lernen des Auswändiglernens misbraucht.

Das ist wohl eher einer irgendwann mal verordneten Umbenennung des Schulfachs geschuldet. Zu meiner Grundschulzeit hieß das noch Rechnen. Erst auf dem Gymnasium hatte ich dann Mathematik. Wobei ich dann während des Studiums noch eine weitere Zäsur in der Bedeutung des Begriffs erfahren durfte.

Kleine Anekdote aus einer Elternversammlung am hiesigen Gymnasium, bei der die Mutter eines der Schüler in Bezug auf das aktuelle Thema im Mathe-Unterricht sagte: "Baumstrukturen? Das braucht doch kein Mensch."

[Rollo62]

Zitat:

Zitat von Uwe Raabe (Beitrag 1542057)

"Baumstrukturen? Das braucht doch kein Mensch."

Natürlich nicht, ist doch für Bäume :-D

[peterbelow]

Zitat:

Zitat von Rollo62 (Beitrag 1542017)

Zitat:

Zitat von Uwe Raabe (Beitrag 1542015)

.. dann sieht C halt einfach nur falsch aus.

Soweit würde ich jetzt aber auch nicht gehen :-D

Ich schon, die C/C++-Syntax ist einfach hässlich und dass die Sprache case-sensitive ist nur eine Fehlerquelle mehr. Naja, C kommt halt aus dem frühen IT Mittelalter, als Compiler noch Probleme mit Identifiern mit mehr als 4 Zeichen hatten etc., weil die Rechner einfach nicht genug Arbeitsspeicher hatten...

[Rollo62]

Zitat:

Zitat von peterbelow (Beitrag 1542065)

Naja, C kommt halt aus dem frühen IT Mittelalter, ...

Na gut, Pascal aber auch
https://unterrichten.zum.de/wiki/Pro...ammiersprachen

1971/1972, das macht wenig Unterschied.

Mit C/C++ kann man sehr elegante Konstrukte machen, wenn man will,
und Pascal's begin-end muss man nicht unbedingt schön finden :stupid:

Für mich ist es halt ein unentschieden :-D

[himitsu]

Pascal ist einer der Urväter ... C kam 1-2 Jahre später .... die haben bestimmt bei uns abgeguckt (das aber nicht sonderlich gut :duck:)
Es haben Beide auch Algol als Vorfahre.
Wobei für Pascal die Ursprünge schon in den 5 Jahren davor begannen (siehe dem, der Algol W erfand :stupid:)

Spätestens bei C# haben sie beim Pascal abgeguckt ... bzw. sie hatten sich Anders Hejlsberg als Cheffentwickler geklaut,
drum sehen da auch einige Bezeichner so bissl delphiig aus.

https://de.wikipedia.org/wiki/Zeitta...ammiersprachen
siehe auch der Screenshot da ganz unten https://www.delphipraxis.net/215958-...ml#post1541749

[TomyN]

Helft mir mal. Gab's bei Fortran 77 überhaupt zwei verschiedene Zeichen für Zuweisung und Vergleich?

O. T. : Und das mit der Sinnhaftigkeit des Unterrichts erlebe ich mehr im 'modernen' Physikunterricht. Da sollte ich mal was erklären, fand aber in Heft und Buch nur Philosophisches zur Solarenergie.... :-D

[bcvs]

Ja, gab es:
https://de.wikibooks.org/wiki/Fortra...ausdr%C3%BCcke

[Rollo62]

Ok, wenn wir schon beim theoretisieren sind.
Die Frage ist ja , warum gibt es ÜBERHAUPT zwei verschiedene Zeichen.

Bei einem Vergleich wäre das ja gar nicht nötig, weil das "if" ja schon alles dazu sagt:

Delphi-Quellcode:

a = 1234;  // Zuweisung

if ( a = 1234 ) then   // Vergleich
begin
end

Das Problem sind wohl die direkten Zuweisungen aus einem boolschen Operator:

Delphi-Quellcode:

a = 1234;

b = a = 1234;   // Zuweisung und Vergleich, b wäre dann True

Im 2ten Fall weiß der Compiler nicht genau, ob er b zuweisen soll, oder a.
Wenn der Compiler schlauer wäre, dann sollte er das meiner Meinung nach trotzdem hinbekommen,
denn das erste "=" müsste IMMER eine Zuweisung sein, oder nicht?

Gibt es eventuell andere Fälle, wo eine Unterscheidung Zuweisung und Vergleich nötig wäre?
Sehe ich auf die Schnelle nicht.
Eine Zuweisung innerhalb von komplexeren Vergleichen würde ich sowieso als Seiteneffekt, und Fehler ansehen.

! Also: Weg mit all dem überflüssigem Zeug und nehmen wir nur "=" für Alles :-D

[dummzeuch]

... und dann ist da noch die C-Syntax:

Code:

a = 5;
if (a=6) {
  AIst6(); // wird aufgerufen
} else {
  AIstNicht6();
}

Es wird AIst6 aufgerufen, weil das Gleichheitszeichen in der If-Abfrage als Zuweisung interpretiert wird und eine Zuweisung auch noch den zugewiesenen Wert zurückliefert. Der ist in diesem Fall <> 0 also True.

In Delphi entspräche das

Delphi-Quellcode:

  a := 5;
  a := 6; // in C findet dies in der If-Abfrage statt
  if a = 6 then
    AIst6()
  else
    AIstNicht6();

Wenn also die ersten C Compiler nicht versucht hätten, Tipparbeit zu sparen, sprich,

Code:

(Wert1 = Wert2)

immer einen Boolschen Wert liefern würde statt Wert1 auf Wert2 zu setzen, brauchte man den ganzen Kladderadatsch nicht.

Aber es war halt wichtiger (oder cooler?), schreiben zu können:

Code:

a = b = c = 10;

statt

Code:

a = 10;
b = 10;
c = 10;

Und der Mist zog sich danach durch alle von C abgeleiteten Sprachen. Das führte dann dazu, dass man statt

Code:

  if (a == 5)

immer

Code:

  if (5 == a)

schreiben sollte. Was das Problem etwas entschärfte, denn falls man ein '=' vergisst, schlägt die Zuweisung auf die Konstante fehl.

Inzwischen warnen die Compiler vermutlich, wenn sie in If-Abfragen etc. (x=y) finden, aber da bin ich nicht mehr auf dem Laufenden. Ich bin vor mehr als 20 Jahren aus den C-ähnlichen Sprachen ausgestiegen.

[QuickAndDirty]

Zitat:

Zitat von paule32.jk (Beitrag 1542012)

Hallo,
ich habe mich schon öfters gefragt, warum bei Delphi Bedingungen/Condition's und Vergleichen der rechte Wert mit einen Assign-Zeichen (also dem ist-gleich = Zeichen) eingeleitet wird.

Für mich macht es mehr Sinn:

Delphi-Quellcode:

if foo == 42 then...

zu schreiben als:

Delphi-Quellcode:

if foo = 42 then ...

weil das if foo = 42 doch sehr nach Zuweisung und nicht gerade nach Vergleich anmutet.
Sind da Pläne bekannt, das zu ändern - oder ist das Historisch bedingt ?
ich mein... Alles Neu macht der Mai ...

":=" ist in der Mathematik als Definitions zeichen gebräuchlich.
Da Pascal(aka Procedural Delphi) aus dem Universitäts- und Lehrumfeld kommt , benutzt es mathematische Symbole soweit das geht.
"=" wird zum vergleichen benutzt.
":=" das Definitionszeichen wird zum Zuweisen genutzt....das Zuweisungszeichen wäre iegentlich ein links pfeil...aber sowas wie "<-" führt zu Verwirrungen bei negativen zahlen
"a<-7" könnte ja a kleiner -7 heißen oder +7 der variable a zuweisen.
Wenn man Mathe-Formel-Editoren hatte benutzte man früher auch oft das Indentiätszeichen "≡" für zuweisungen aber das ist eben nach ISO 31-11
https://de.wikipedia.org/wiki/Liste_...nitionszeichen
nicht mehr en vogue und "≡" sollte jetzt nur noch für Identität/Kongruenz genutzt werden.

Delphi benutzt ":=" weil es damals noch keine coolen unicode zeichen gab wie Definition linksseitig "≔" oder eben "≝" (das ist ein = mit dem Wort DEF oben drüber).



Es gibt übrigens noch eine ganze Reihe anderer operatoren die wir in Delphi nicht haben ...zum Glück...
z.b. "test auf unifizierbarkeit" wie in Prolog....

[paule32.jk]

Zitat:

Zitat von Rollo62 (Beitrag 1542080)

Ok, wenn wir schon beim theoretisieren sind.
Die Frage ist ja , warum gibt es ÜBERHAUPT zwei verschiedene Zeichen.

Das Problem sind wohl die direkten Zuweisungen aus einem boolschen Operator:

Code:

a = 1234;

b = a = 1234;   // Zuweisung und Vergleich, b wäre dann True

Im 2ten Fall weiß der Compiler nicht genau, ob er b zuweisen soll, oder a.
Wenn der Compiler schlauer wäre, dann sollte er das meiner Meinung nach trotzdem hinbekommen,
denn das erste "=" müsste IMMER eine Zuweisung sein, oder nicht?

Das hat damit zu tun, das die Werte bei C/C++ auf einen Stack gelegt werden - nach dem LIFO (last in first out) Prinzip:
die Werte gehen also immer nach unten bzw links nach rechts beim setzen aufgebaut:

seter:
push b
push a
push 1234

geter:
pop 1234
pop a
pop b

bei Pascal werden Variablen-ähnlich nach oben aufgebaut.
hat beides sein für und wider...

[freimatz]

Ich halte es für ein Gerücht, dass bei einer Zuweisung der Stack benutzt wird. Wir sind doch nicht bei FORTH :-D

[Rollo62]

Zitat:

Zitat von dummzeuch (Beitrag 1542083)

... und dann ist da noch die C-Syntax:

Code:

a = 5;
if (a=6) {   //<== Halte ich IMMER für einen Fehler
  AIst6(); // wird aufgerufen
} else {
  AIstNicht6();
}

Ja genau, aber ich halte das eben immer für falsch, korrigiert mich wenn es Fälle gibt, wo dies wirklich logisch Sinn macht.

Außer maximaler Verwirrung hat das doch keine Vorteile, außer vielleicht wirklich auf Assembler-Ebene,
wo dann z.B. ein zugewiesener Wert direkt weiterverarbeitet werden kann, der schon im Register ist, oder sowas.

Man muss dabei vielleicht Bedenken, dass diese Syntax wirklich aus Zeiten kamen,
als 1024 Byte noch ein Riesenspeicher war, und als noch um jedes Bit mit Säbeln und Morgenstern hart gekämpft wurde. :-D

[paule32.jk]

Ihr kennt bestimmt die Anekdote mit den Russen und C ... ?

Einige Verschwörer denken ja bis heute, das C entwickelt wurde, um den technischen Fortschritt der Federation (mit Luna, Lika und Gagarin) zu bremsen. Und weil die Russen als erstes Bunt TiWi hatten, sollte das mit den in den USA gestarteten Gemini Projekte (also die bemante Mondbesteigung) ausgeglichen werden.

[Rollo62]

Nee, glaube ich nicht.
IT Nerds waren schn immer auf ihrem Paralleluniversum in ihrer Parallelwelt unterwegs,
da zählen Ländergrenzen oder Staatszugehörigkeiten einfach nichts.
Es ist wie eine große Familie, Sternenübergreifend.

[jaenicke]

Zitat:

Zitat von Rollo62 (Beitrag 1542097)

Ja genau, aber ich halte das eben immer für falsch, korrigiert mich wenn es Fälle gibt, wo dies wirklich logisch Sinn macht.

Naja, also ich habe schon öfter Code wie diesen:

Delphi-Quellcode:

CallResult := CallAPI(...);
if CallResult = 0 then
  Result := ...
else
  raise ESevereError.Create('Fehlercode: ' + CallResult.ToString);

Ich finde es aber immer besser, wenn man einzelne Befehle auch separat schreibt, damit es übersichtlicher ist. Insofern würde ich das ohnehin nicht zusammenfassen wollen. Also so nach dem Motto:

Delphi-Quellcode:

if CallResult := CallAPI(...) then
  raise ESevereError.Create('Fehlercode: ' + CallResult.ToString)
else
  Result := ...

Theoretisch wäre das mit Pascal-Syntax durchaus umsetzbar, ohne dass es dort Mehrdeutigkeiten gäbe. Die automatische Umwandlung des Zahlenwerts in einen Boolean wäre noch zusätzlich nötig. Sonst müsste es so gemacht werden:

Delphi-Quellcode:

if (CallResult := CallAPI(...)) > 0 then

Wie gesagt, ich würde es nicht wollen. ;-)

[smallie]

Niklaus Wirth schrieb vor einigen Jahren:

Zitat:

Good Ideas, Through the Looking Glass
IEEE Cover Feature 2006

It has become fashionable to regard notation as a secondary issue depending purely on personal taste. This could partly be true; yet the choice of notation should not be considered arbitrary. It has consequences and reveals the language’s character.

Choosing the equal sign to denote assignment is one notoriously bad example that goes back to Fortran in 1957 and has been copied blindly by armies of language designers since. This bad idea overthrows a century-old tradition to let = denote a comparison for equality, a predicate that is either true or false. But Fortran made this symbol mean assignment, the enforcing of equality. In this case, the operands are on unequal footing: The left operand, a variable, is to be made equal to the right operand, an expression. Thus, x = y does not mean the same thing as y = x. Algol corrected this mistake with a simple solution: Let assignment be denoted by :=.

This might appear as nitpicking to programmers accustomed to the equal sign meaning assignment. But mixing up assignment and comparison truly is a bad idea because it requires using another symbol for what the equal sign traditionally expresses. Comparison for equality became denoted by the two characters == (first in C). This is an ugly consequence that gave rise to similar bad ideas using ++, —, &&, and so on.

Published by the IEEE Computer Society 0018-9162/06/$20.00 © 2006 IEEE

[bernau]

Zitat:

Zitat von Rollo62 (Beitrag 1542067)

und Pascal's begin-end muss man nicht unbedingt schön finden :stupid:

Ich finde es sogar sehr schön.

[himitsu]

Aber fehlt da nicht ein n und e?

[Rollo62]

Zitat:

Zitat von bernau (Beitrag 1542114)

Ich finde es sogar sehr schön.

Außer man ist ein Klammer-Fan so wie ich, und nutze Klammern gerne in Mathematik und Code um Teile zu separieren,
auch wenn dies nicht immer absolut notwendig ist.
Das erspart über implizierte logische Zuordnungen nachzudenken und legt die Berechnung so dar, wie es geplant ist.
Zum Verhindern von blöden Flüchtigkeitsfehler und der besseren Zuordnung logischer Zusammenhänge ist das eine gute Sache.
Hier mal ein Extrembeispiel:

Delphi-Quellcode:

if ....Assign(......FClass        )
   and ......(......FClass.CanUse ) 
   and ......(.(....FClass.ValueA 
   .............+ ( FClass.ValueB * FClass.ValueC )
               ). = 42
             ) then
  begin
  end;

vs.

Delphi-Quellcode:

if Assign(FClass) and FClass.CanUse and (FClass.ValueA+FClass.ValueB*FClass.ValueC=42) then
  begin
  end;

Wo kann man logische Fehler wohl besser erkennen?

Natürlich versuche ich das weiter zu entflechten durch negative Logik und Guards

Delphi-Quellcode:

if not Assign(     FClass        ) then
begin
    Exit;     
end;

if not FClass.CanUse then
begin
    Exit;
end;


if (.....FClass.ValueA 
     + ( FClass.ValueB * FClass.ValueC ) ) = 42 then
begin
end;

Ok, das ist sicher extremer als ich das aktuell mache, aber größtenteils Geschmackssache und Philosophie ...
Soll Jeder machen, wie er meint, was für ihn Vorteile bringt.
Für mich steht eine übersichtliche Formatierung an erster Stelle, gerade weil Logik so mehrdeutig und verheddert sein kann. :stupid:

[himitsu]

Zitat:

Zitat von Rollo62 (Beitrag 1542145)

Außer man ist ein Klammer-Fan so wie ich, und nutze Klammern gerne in Mathematik und Code um Teile zu separieren,

Das geht ja noch ... wir haben hier ein paar Klammer-Fetischisten, die klammern ALLES und JEDEN, sogar einzelne Variablen,
schreiben NOT wie eine Funktion (mit Klammer und ohne Leerzeichen) und nochmal 'ne Klammer drumrum und boar eh.

Code:

if    (Assign(      (FClass))) )
   and       (      (not(FClass.CanNotUse)) )
   and       ( (    (FClass.ValueA)
               + ( (FClass.ValueB) * (FClass.ValueC) )
              )   = 42
            ) then
  begin
  end;

Ach ja, AND, OR und + am Zeilenende :wall:

Code:

if (Assign(      (FClass))) ) and
          (      (not(FClass.CanNotUse)) ) and
          ( (    (FClass.ValueA) +
               ( (FClass.ValueB) * 
                 (FClass.ValueC) )
            )   = 42
         ) then

Vorne ist es immer an der selben Stelle und als Erstes (nicht sonstwo im Text hinten versteckt) ... man sieht also (nicht), dass es und wie an der vorhergehenden Zeile hängt.

[Uwe Raabe]

Um solche mehrzeiligen Conditions besser les- und wartbar zu machen, bieten sich separate

Delphi-Quellcode:

function <sinnvoller Name>(...): Boolean

an. Um die Performance nicht zu sehr zu beeinträchtigen, kann man die dann ja inline deklarieren.