[Erledigt ]Logik-Problem mit and/or-Verknüpfung

[Hobby-Programmierer]

Auch wenn ich deinen Code immer sehr schätze, muss ich zugeben das mich als Amateur deine Hilfsconstanten eher verwirren.
Aber das des funktioniert war eher darauf fokussiert

Zitat:

Zitat von Wolfgang Mix (Beitrag 1177951)

in (1,2) hatte ich auch versucht, allerdings mit [] :(

Schönen Abend noch ;)

[Wolfgang Mix]

Nochmal wegen der Lesbarkeit und ohne Hilfskrücken
(unnötige Zusatzvariblen) habe ich es jetzt so
und es funktioniert.

Delphi-Quellcode:

if (monat in[1,2]) and isleapyear(jahr) then
  schaltjahrkorrektur:=1
else schaltjahrkorrektur:=0;

Zitat meines Lehrmeisters:
"Geht nicht" gibt es nicht :-)

LG

Wolfgang

[DeddyH]

Das waren aber weder Variablen noch Krücken, sondern einfache Konstanten.

[Wolfgang Mix]

Sorry Detlef,
aber mein Code braucht jetzt weder zusätzliche Variablen,
Konstanten noch externe Funktionen.
Bin eigentlich mit dem jetzigen Code zufrieden :-)
Mein k und Dein CORRECTIONVALUE sind also überflüssig

LG

Wolfgang

[Hobby-Programmierer]

... und if / then brauchst du auch nimmer :roll: ROFL

Delphi-Quellcode:

schaltjahrkorrektur:= ((Month in [1,2]) and IsLeapYear(Year));

[Furtbichler]

Achtung, Klugscheißerkommentar!

Ist kompakter Code strebenswert oder lesbarer? Soll man das noch verstehen, wenn man in ein paar Jahren drüberschaut oder einfach übersehen, weil es ja so herrlich kompakt ist?

Zunächst fällt auf, das Monate durch numerische Werte repräsentiert werden. Das ist ungünstig, denn für welchen Monat steht die 1? Immer für Januar? Was ist, wenn wir mit Fiskaljahren rechnen und der erste Monat des Fiskaljahres ist der Juli? Was bedeutet dann die 1?

Ich würde daher den Monaten eine Enumerationsliste spendieren und den Monat durch seinen Namen repräsentieren. Dann ist das unmißverständlich.

DeddyH ist schon auf dem richtigen Weg, indem er auf magische Konstanten verzichtet, aber stellt sich über seinen 'Correctionvalue' selbst ein Bein: Das macht den Ansatz dann wieder schwerer Lesbar. Wolfgang will doch nur den einfachen Satz ins delphianische übersetzt haben:
"Wenn Januar oder Februar im Schaltjahr vorliegt, soll eine Schaltjahreskorrektur vorgenommen werden (1), andernfalls 0."
In Englisch wäre das
"A correctionvalue should be 1, if and only if the year is a leapyear and the month is a january and 0 otherwise".

Fast am Ziel (Delphi kennt das so ja nicht)

Delphi-Quellcode:

If IsLeapYear() and month in [January, February]  Then 
  CorrectionValue := 1 
else 
  CorrectionValue := 0;

Dieser Code liest sich fast so wie Wolfgangs Aufgabenstellung. Fast wortwörtlich, ergo verständlich.

Wenn man nun die Eigenschaft 'Schaltjahr und Januar oder Februar' noch beschreiben möchte (z.B. weil das eine Bedingung ist, die Fred Rembremerdinger in seiner Gleichung aufgestellt hat) dann kann man das noch in eine Funktion auslagern und dieser Funktion einen aussagekräftigen Namen geben. Muss aber nicht.

Das Einzige, was mich noch stören würde, ist der Name dieses Korrekturfaktors. Was korrigiert er? Wenn Wolfgang mehr Code zeigen würde, dann könnte man diesen Faktor noch umbenennen. Aber in dieser Aufgabenstellung reicht diese Bezeichnung aus.

@Hobbyprogrammierer: Ist 1/0 gleichbedeutend mit einem Boolean

[Jonas Shinaniganz]

Find Ich garnicht so klugscheißerisch... hört sich einfach nach Erfahrung an.

Hilfsvariablen oder "Krückenvariablen" heißen eigentlich ungünstig, weil sie Pflicht-Leseverbesserungs-Variablen heißen sollten und man davon soviele erstellen sollte, wie es für ein besseres Verständnis des Codes förderlich ist.

Angenommen du berechnest in einer Funktion:

Delphi-Quellcode:

Border := 10 * Parameter;
Result := Border + Width;

// Könntest du das auch ohne Border und in 1 Zeile abwickeln

Result := (10 * Parameter) + Width

Wenn du jenes allerdings in komplexeren Methoden ohne weitere Bezeichner machst, wird der Code wieder ein Stückchen unübersichtlicher -> schwerer zu warten.

Ich würde Klammern immer setzen, weil sie der Gleichnung verschiedene menschliche Interpretationsmöglichkeiten aberkennen, denn eigentlich ist das Problem, dass du scheinbar nicht genau weißt was passiert wenn sie nicht da sind:

Dazu gibts einen kleinen Bereich in der Referenz:
http://docwiki.embarcadero.com/RADSt....29_Operatoren

Zitat:

Das Kurzschlussverfahren geht streng von links nach rechts vor und wird beendet, sobald das Ergebnis des gesamten Ausdrucks feststeht

Delphi-Quellcode:

If (IsLeapYear()) and (month in [January, February]) Then

Nach unserem Styleguide würde die Bedingung zwanghaft nochmals eingeklammert werden aber das ist was hausinternes.

[Iwo Asnet]

Es ist etwas OT, aber eine interessante Diskussion.
Ich persönlich verzichte gerne auf Überflüssiges im Code, wobei ich bei der Klammersetzung dazu tendiere, komplexe Ausdrücke durch Funktionen oder Hilfsvariablen verständlich zu machen.

Ich persönlich finde es aber einen Overkill, einen Funktionsaufruf in Klammern zu setzen. Ich setze beim Leser meines Codes voraus, das er Delphi kann.

Was allerdings grenzwertig wäre, wäre ein Konstrukt wie

Delphi-Quellcode:

if not ((a>=1) and (a<=10)) or not((b>=-2) and (b<=15)) then // habe ich Klammern vergessen?

.

Das ist zwar schön kompakt, aber man muss schon genauer hinschauen, um zu erkennen, das a und b auf 'außerhalb einer Toleranz' geprüft werden (also eigentlich ja negiertes 'innerhalb der Toleranz' :freak:). Also wieso nicht gleich

Delphi-Quellcode:

if Not InTolerance(a,1,10)) or not InTolerance(b,-2,15) then// garantiert keine Klammer vergessen
// oder nach Umformung (leichter zu lesen????)
if Not (InTolerance(a,1,10)) and InTolerance(b,-2,15)) then

[himitsu]

Zitat:

Zitat von Iwo Asnet (Beitrag 1178061)

Delphi-Quellcode:

if Not InTolerance(a,1,10)) or not InTolerance(b,-2,15) then// garantiert keine Klammer vergessen

Doch, da fehlt ein ( :stupid:

[Iwo Asnet]

:rofl: Aber da fehlt keine, das ist eine zu viel.
Herrlich ins Knie geschossen!