Stilfrage: Zuweisungen in if-Klammern

randa

Bashar schrieb:

Wenn du das verwechselst, solltest du mal zum Augenarzt gehen.

quatsch, das ist leicht zu verwechseln, deshalb ist es schlechter stil. Nach einer Zuweisung separat, also nicht in der if-Anweisung, auf einen Gültigen Wert zu prüfen ist außerdem Ausdrucksstärker.

int *f () { ... }

int *x;
if (x=f()) //undeutlich
x=f;
if (x)	//deutlich

ich schreibe meinen code so, das ich ihn praktisch in die menschliche Sprache übersetzen und verstehen kann. Wenn ich if (x=f()) schreibe, dann denke ich intuitiv etwas anderes. Es geht wohl auch anderen so. Je expliziter etwas ausgedrückt ist, desto verständlicher ist der Code.

Shlo

randa schrieb:

quatsch, das ist leicht zu verwechseln, deshalb ist es schlechter stil.

Achsooo, dann gehörst du bestimmt zu denjenigen die auch sowas schreiben:

int i;

for ( i = 0; i < 2; i++)
    //...

net 0

Shlo schrieb:

Des Weiteren siehe Kapitel 6.3.2.1 des Buches "Die C++ Programmiersprache" von Bjarne Stroustrup. Dort wird erklärt warum, eine Deklaration in einer Bedingung kein schlechter Stil ist.

das ist seine meinung. muss ich die teilen?

Shlo schrieb:

Achsooo, dann gehörst du bestimmt zu denjenigen die auch sowas schreiben:
int i;
for ( i = 0; i < 2; i++)
    //...

in c muss man das.
aber in c++ das 'int' in die for-anweisung zu schreiben ist z.b. kein schlechter stil, weil eindeutig. die lesbarkeit verbessert sich sogar, wenn man die variablendeklaration in die for-klammer schreibt. allein wegen der gültigkeit von 'i' ist es besser in der for-anweisung aufgehoben

randa

und du gehörst zu denen:

if (x=(y=z?y==f():z=4)=p++) cout << "Hello World"
else cout << "Verschissen";

das ist seine meinung. muss ich die teilen?

Er argumentiert plausibel und hat recht. Du musst nicht auf ihn hören, weil er "der Master" ist, sondern weil er in 99% der Fälle mit seinen Feststellungen recht hat.

Jester

randa schrieb:

Er argumentiert plausibel und hat recht.

Geiles Argument!

Bashar

net schrieb:

ich sagte man 'kann' es verwechseln.
wenn man den code nur überfliegt z.b.

Man kann viel verwechseln, wenn man nur überfliegt. Aber bei normalem Lesen fällt auf, dass da eine Deklaration steht (am unsigned zu erkennen). Wenn da die Mustererkennung im Gehirn immer noch einen Vergleich sehen will ... wie gesagt, medizinischer Notfall.

IMHO hilft es auf lange Sicht ungemein, wenn man seine 'Intuition' der Sprache anpasst, es nützt nichts ständig dagegen anzukämpfen.

In diesem Punkt teile ich seine Meinung auch nicht. Ich sehe keinen Vorteil darin? Haben wir wieder eine Zeile Code gespart?
Ich unterstelle ja niemanden, deswegen lauter Fehler zu machen. Aber es reicht ein einziges mal und man kann sich mit nem hässlichen hard-to-find-bug rumplagen. Und was bringt es? Nichts.

Ich kann sowas lesen, wenn jemand unbedingt so programmieren möchte. Aber selber schreibe ich das ausführlich hin.

randa

Jester schrieb:

randa schrieb:

Er argumentiert plausibel und hat recht.

Geiles Argument!

damit Meinte ich, das die Argumente, die Stroustrup gegen einen bestimmten Stil einbringt, einleuchten.

Edit: Hab mich verlesen. Ja, im Stroustrup steht, das eine Deklaration in der if - Anweisung in Ordnung ist.
Jedoch weiß ich das irgendwo stand, das Zuweisungen in Deklarationen missverständlich sein können.

Shlo

randa schrieb:

und du gehörst zu denen:

if (x=(y=z?y==f():z=4)=p++) cout << "Hello World"
else cout << "Verschissen";

Siehst du, ich habe Recht.

net 0

Bashar schrieb:

IMHO hilft es auf lange Sicht ungemein, wenn man seine 'Intuition' der Sprache anpasst...

wozu sind denn die sprachen da? damit man es als mensch leichter hat. man solte es sich und anderen nicht unnötig schwer machen und zu 'obfuscated' coden.
es bringt keinen weiter, wenn man einen c++ -parser im kopf hat und dementsprechen code schreibt. der compiliert zwar fehlerfrei aber kaum einer kann ihn lesen.

Shlo

net schrieb:

allein wegen der gültigkeit von 'i' ist es besser in der for-anweisung aufgehoben

Bei Deklaration in einer if-Anweisung ist es nicht anders:

if (int a = foo())
    //...

Hier möchte ich, dass der Gültigkeitsbereich von a von der Deklarationsstelle bis zum Ende der Bedingung reicht. Anhand deiner Argumentation nehme ich an, dass du in einem solchen Fall lieber sowas schreiben würdest:

{
    int a = foo();

    if (a)
        //...
}

was ich natürlich für Blödsinn halte.

Bashar

net schrieb:

man solte es sich und anderen nicht unnötig schwer machen und zu 'obfuscated' coden.

Zuweisungen in Bedingungen sind aber nicht 'obfuscated', sondern gängige Praxis.

net 0

Shlo schrieb:

{
    int a = foo();

    if (a)
        //...
}
was ich natürlich für Blödsinn halte.

ja, es sieht doof aus aber wär eine alternative wenn man die gültigkeit von 'a' einschränken will. würde ich fast dem 'if (int a=foo())' vorziehen.
(jetzt bin ich bestimmt unten durch bei dir)

Walli

OMG, das machst du hoffentlich nicht konsequent...

{
  int i;
  for(i=0; i!=100; ++i)
    foo(i);
}

Grauenhaft!

Jetzt vergleicht ihr Äpfel mit Birnen. :p

net 0

MaSTaH schrieb:

OMG, das machst du hoffentlich nicht konsequent...
{
  int i;
  for(i=0; i!=100; ++i)
    foo(i);
}

nein, nicht in for-schleifen weil da kann's bei oberflächlicher betrachtung nicht so leicht zu verwechslungen führen (== statt zuweisung). aber das schrieb ich schon irgendwo hier

interpreter

Dass dieser Stil in der Vergangenheit wohl oft zu schwer auffindbaren Fehlern geführt hat, sieht man doch am Design neuer Sprachen. Genau _das_ ist der Grund, warum z.B. in Java oder C# sowas _nicht_ mehr erlaubt ist:
if(i = foo())

randa

Grauenhaft!

Es hat ja auch niemand von der for-Schleife geredet, sondern von if und der verwechslung mit ==.

Vellas

Hi!

interpreter schrieb:

Dass dieser Stil in der Vergangenheit wohl oft zu schwer auffindbaren Fehlern geführt hat, sieht man doch am Design neuer Sprachen. Genau _das_ ist der Grund, warum z.B. in Java oder C# sowas _nicht_ mehr erlaubt ist:
if(i = foo())

In C# ist das sehr wohl noch erlaubt. Allerdings benötigst du anschließend noch einen expliziten Vergleich:

int i;
if((i = foo())!=0) Console.WriteLine("Hello World!");

Code-Hacker

interpreter schrieb:

Dass dieser Stil in der Vergangenheit wohl oft zu schwer auffindbaren Fehlern geführt hat, sieht man doch am Design neuer Sprachen. Genau _das_ ist der Grund, warum z.B. in Java oder C# sowas _nicht_ mehr erlaubt ist:
if(i = foo())

Ich kann mich jetzt täuschen, aber ich glaube, es ist immer noch erlaubt, wenn man ein bool zuweist. Es wird nur kein Pointer oder ein int implizit in ein bool konvertiert, zum Glück.