Eure dümmsten Fehler bei der Programmierung

[Bashar]

Mach doch nicht Pascal für die Syntax von C verantwortlich.

[Ein ehemaliger Benutzer]

Was ist daran ein Fehler eine gut strukturierte und entwickelte Sprache zu benutzen als so eine Sprache an der immer wieder rumgeflickt wird und so kaum noch konsistent ist, sondern eigentlich mehr einem Flicenteppich ähnelt?

[rüdiger]

Original erstellt von Bashar:
Mach doch nicht Pascal für die Syntax von C verantwortlich.

das waren ja gar nicht die Gründe, warum ich Pascal nicht mag. Obwohl man ja schon sieht, dass := unüberlegt ist. Ich hab mal gehört, dass man in C = als Zuweisungsoperator benutzt hat, da es öfter vorkommt als ein Vergeleich. Bei Pascal ist der Zuweisungsoperator länger

nein, es gibt andere Dinge, die mich an (O)Pascal stören

-Variablen müssen in einem Extra Block deklariert werden
-Konstruktor muss explizit aufgerufen werden und bei "normalen" Klassen auch der destruktor
-publish Sektion, für die IDE eingeführt

-Keywörter wirken so unangepasst und schlecht integriert in den Syntax if ... then anstelle if(...), wirkt dadurch wie Basic
-begin end; und begin end. da dreht man doch auch durch
-keine Initalisierung
-keine statischen Variablen

if x=a then 
begin
  y;
  z;
end;

mit else muss das ; nach dem end Weg

if x=a then
begin
  y;
  z;
end
else
  a;

[ms]

Zu zweit sind wir damals vorm PC bis spät in die Nacht gesessen.
Der PC (Minitower) stand unter dem Tisch.
Mein Kollege hatte das eine Bein über das andere geschlagen.
Während dieser Debugsession und ein paar Bugfixes setzt er
sich etwas aufrechter auf und erwischt dabei genau mit seiner
Fußspitze den Powerschalter des PC.
Wie es natürlich so üblich ist, war der letzte Speichervorgang
schon eine weile her.
In meiner Magengegend verspürte ich einerseits hilflose Verzweiflung und
andererseits den Drang laut zu Lachen.

[ranger81]

[...]
int i;
for(i=0;i<20;i++);
{
  printf("\nHallo Welt !");
}
[...]

[Bashar]

wenn man das so schreibt:

for (i = 0; i < 20; ++i) {
   foo();
   bar();
}

fällt das falsche Semikolon viel eher ins Auge, ausserdem bekommt man nicht die Angewohnheit, nach jeder schließenden Klammer ein ; zu tippen, sondern sich jeweils für ; oder { zu entscheiden. Mir ist dieser Fehler jedenfalls, seit ich die Klammern so setze, nicht passiert.

[ranger81]

@Bashar: Was ist denn das in der for schleife ???

++i

[rüdiger]

was soll damit sein?

[Shade Of Mine]

Mir ist
for(...);

noch nie passiert... irgendwie komisch...

[???]

Shade, vielleicht bist du einfach besser als wir. Aktzeptier es doch einfach. :p

[mastercpp]

Original erstellt von Shade Of Mine:
**Mir ist
for(...);

noch nie passiert... irgendwie komisch...**

Mir auch nicht. Liegt bei mir aber eher daran, dass ich sehr oft Semikolons verggesse.

Edit:
Mir fällt gerade ein, dass ich in Assembler manchmal diesen Fehler mache:

mov**,** ax, bx

[ Dieser Beitrag wurde am 20.11.2002 um 18:22 Uhr von mastercpp editiert. ]

[Shade Of Mine]

Original erstellt von <???>:
Shade, vielleicht bist du einfach besser als wir. Aktzeptier es doch einfach. :p

dafuer vergesse ich immer (naja, ab und zu) bei

cass Foo
{
}

den strichpunkt

[Minuspunkt]

Warum muss man da überhaupt nen Strichpunkt machen? Ist der Parsetechnisch unbedingt nötig? Bei Java brauch man den glaub ich auch nicht.

[Shade Of Mine]

ueberbleibsel aus C

struct foo
{
int a,b;
} obj;

da brauchte man den Strichpunkt

Deshalb wurde class genauso gemacht wie struct:

class Klasse
{
public:
void foo() {}
} objekt;

[Gerard]

Why is semicolon required after class definition?

[HumeSikkins]

Warum muss man da überhaupt nen Strichpunkt machen? Ist der Parsetechnisch unbedingt nötig? Bei Java brauch man den glaub ich auch nicht.

Lesen, verstehen, glücklich sein

[HumeSikkins]

Yes
Keine zieht schneller als HumeSikkins

[Gerard]

[nix]

ich vertippe mich oft und schreibe : statt ; , weil die so nahe beieinander liegen.

[Gast]

Mein häufigster und gefährlichster Fehler ist eindeutig der, den Aufwand zu unterschätzen etwas tatsächlich zu realisieren. Im Kopf ist das Ding schnell fertig - bzw. durchgecheckt, ob und wie machbar, aber gemacht werden muss es noch. Und alleine das Userinterface (was beim Durchchecken gar keine Rolle spielt) ist dann ein sehr zeitaufwendiges Kapitel.