if c in ["A".."Z", "1"]

[Frolo]

Ja, ich hab mich nur daran gewöhnt, dass in Delphi relativ viel kurz ist..

if ( ((c >= 'A') && (c <= 'Z')) || (c=='1') ) {
}

ist halt um einiges länger (vor allem bei mehr Faktoren)

Aber trotzdem vielen Dank!

[Sone]

Das ist auch völlig redundant:

if ( c >= 'A' && c <= 'Z' || c == '1' )

[DirkB]

Ein isupper() geht hier auch.

if ( isupper(c) || (c=='1') ) {
}

[Cyres]

Sone schrieb:

Das ist auch völlig redundant:

if ( c >= 'A' && c <= 'Z' || c == '1' )

Gerade die Klammern bei Konjunktion und Disjunktion sollte man der Lesbarkeitshalber aber belassen, auch die anderen Klammern machen das ganze nur übersichtlicher.

[Nexus]

Cyres schrieb:

Gerade die Klammern bei Konjunktion und Disjunktion sollte man der Lesbarkeitshalber aber belassen, auch die anderen Klammern machen das ganze nur übersichtlicher.

Ich persönlich lasse Klammern fast immer weg, wenn ich es kann. Sie machen Code in vielen Fällen weniger lesbar und lenken von den tatsächlich wichtigen Anwendungen (Funktionsaufrufen, Kontrollstrukturen) ab.

Die Priorität von && und || sollte nun wirklich jeder kennen. Bei komplexeren Ausdrücken würde ich eher zeilenweise als mit Klammern trennen.

[TyRoXx]

Ich versuche seit kurzem binäre Operationen als Bedingungen zu vermeiden. Stattdessen gebe ich den Werten Namen:

bool isCapitalAlpha = (c >= 'A' && c <= 'Z');
bool isOne = (c == '1');
bool isRelevant = isCapitalAlpha || isOne;
if (isRelevant)
{
	...
}

[2346257rf]

TyRoXx schrieb:

Ich versuche seit kurzem binäre Operationen als Bedingungen zu vermeiden. Stattdessen gebe ich den Werten Namen:

bool isCapitalAlpha = (c >= 'A' && c <= 'Z');
bool isOne = (c == '1');
bool isRelevant = isCapitalAlpha || isOne;
if (isRelevant)
{
	...
}

finde ich nicht gut. Wenn ich diese if sehe, schießen mir sofort zwei Fragen in den Kopf, die ich in der Zeile nicht beantworten kann.

1. WAS muss relevant sein?
2. WIE wird dieses etwas relevant?

ich würde da wohl DirkBs Variante bevorzugen.

[freaky]

2346257rf schrieb:

TyRoXx schrieb:

Ich versuche seit kurzem binäre Operationen als Bedingungen zu vermeiden. Stattdessen gebe ich den Werten Namen:

bool isCapitalAlpha = (c >= 'A' && c <= 'Z');
bool isOne = (c == '1');
bool isRelevant = isCapitalAlpha || isOne;
if (isRelevant)
{
	...
}

finde ich nicht gut. Wenn ich diese if sehe, schießen mir sofort zwei Fragen in den Kopf, die ich in der Zeile nicht beantworten kann.

1. WAS muss relevant sein?
2. WIE wird dieses etwas relevant?

ich würde da wohl DirkBs Variante bevorzugen.

Und diese Fragen kannst du dir nicht beantworten, indem du eine Zeile darüber schaust? Ich finde diese Variante sehr übersichtlich, muss aber zugeben, dass ich wohl zu faul für solch eine Variante wäre.

[tntnet]

if c in ['A'..'Z', '1'] then {..};

Der Bedingung einen Namen zu geben finde ich grundsätzlich eine gute Idee. Die Delphi Variante ist zwar kurz und übersichtlich aber nicht wirklich verständlich.

Warum soll cgenau diesen Wert haben? Da würde ich doch eine kleine Hilfsfunktion schreiben, die im Namen sagt, was da eigentlich erreicht werden soll. Oder eben so, wie vorgeschlagen eine bool Variable.

Das Beispiel isRelevant sehe ich als Vorschlag. Da wir nicht wissen, was die tiefere Bedeutung dieser Abfrage ist, ist das isReleveant wohl der beste Vorschlag, der hier geboten werden kann. Eventuell gibt es ja eine fachliche Begründung, warum genau diese Werte erlaubt sind. Das sollte dann im Namen auftauchen. Wie die Abfrage dann technisch erfolgt, ist dann nicht wirklich relevant.

[volkard]

TyRoXx schrieb:

Ich versuche seit kurzem binäre Operationen als Bedingungen zu vermeiden. Stattdessen gebe ich den Werten Namen:

bool isCapitalAlpha = (c >= 'A' && c <= 'Z');
bool isOne = (c == '1');
bool isRelevant = isCapitalAlpha || isOne;
if (isRelevant)
{
	...
}

Das wird schiefgehen.
Die Bezeichner wie isCapitalAlpha lassen Sachen weg. In dem Fall den Bezug zur Variablen c. Also bei zwei Variablen kracht es schon.

isRelevant ist übertrieben und entfernt die ENtscheidung von der folgenden Tat.

if( isCapitalAlpha || isOne )
{
	...
}

ist doch in nullkommanix besser als

if( isCapitalAlpha(c) || isOne(c) )
{
	...
}

, außer daß die Variable weggelassen wurde.

Künstliche Hilfsvariablen kann ich mir höchstens vorstellen bei so Quark wie

if( container.find(foo)!=container.end() )

wo man nur der Tatsache Rechnung trägt, daß

if( container.contains(foo) )

schlicht fehlt.

[Sone]

Ein anderes, objektiveres Problem ist, dass so SCE unterbunden wird.

[volkard]

Sone schrieb:

Ein anderes, objektiveres Problem ist, dass so SCE unterbunden wird.

SCE?

[SeppJ]

Sone schrieb:

Ein anderes, objektiveres Problem ist, dass so SCE unterbunden wird.

Jetzt machst du das mit den obskuren "Fachworten" aber absichtlich! Googlesuche nach Leuten, die "short-circuit evaluation" als "SCE" abkürzen, ergibt 47 Treffer weltweit.

[Sone]

SeppJ schrieb:

Googlesuche nach Leuten, die "short-circuit evaluation" als "SCE" abkürzen, ergibt 47 Treffer weltweit.

Wat?

Entschuldige, ich wusste echt nicht dass die Abkuerzung so unbekannt ist!

Ich meinte "Kurzschlussauswertung", also dass Argumente bei solchen logischen Operationen manchmal nicht ausgewertet werden muessen, wenn das Ergebnis vorher feststeht. Tyrrox' Variante erzwingt das Auswerten aller Operanden, was natuerlich nicht wuenschenswert ist.

Da short circuit evaluation nun mal huebsch aus drei Worten besteht, dachte ich auf die Schnelle, das ist doch bestimmt als SCE abgekuerzt. Ich entschuldige mich nochmals, und hoffe, dass nicht gleich ein shitstorm kommt.