EMB DCE 12 - Bedingungen mit einen Assign-Zeichnen

[Rollo62]

Zitat von dummzeuch:

... 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.

[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 von Rollo62:

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: 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 von Rollo62:

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

Ich finde es sogar sehr schön.

[himitsu]

Aber fehlt da nicht ein n und e?

[Rollo62]

Zitat von bernau:

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.

[himitsu]

Zitat von Rollo62:

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

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 function <sinnvoller Name>(...): Boolean an. Um die Performance nicht zu sehr zu beeinträchtigen, kann man die dann ja inline deklarieren.