Die häufigsten Programmierirrtümer

[angos]

ich denke, folgender nicht im Code zu findender Ausdruck sollte hier auch mit aufgenommen werden:

"Kein Problem, das hab ich in ner Stunde fertig." :-D

[Dezipaitor]

Zitat:

Zitat von angos

"Kein Problem, das hab ich in ner Stunde fertig." :-D

Zitat:

Ich machs in ner halben.

Zitat:

Ich geb dir 15min.

:mrgreen:

[himitsu]

"Ich glaube es läuft."

"Es kompiliert, also läuft es."


[ot]

Zitat:

Zitat von angos

"Kein Problem, das hab ich in ner Stunde fertig." :-D

Scotty schafft es im Notfall auch in 5 Minuten.

[Der.Kaktus]

Zitat:

..Bei mir laeuft es...dann muss es bei Dir auch laufen

:-D

[Matze]

Hier schon eher ein Irrtum als ein Fehler. Bisher wurden (fast) nur Fehler erwähnt.
Das trifft auf PHP zu:

Code:

$s = '0'; // hier wird der String '0' zugewiesen

if (!empty($s))
{
   // wird nicht aufgerufen
}
else
{
   // trifft zu, da 0 = '0' = empty
   // wenn man den Datentyp nicht explizit abfragt
}

[Meflin]

Zitat:

Zitat von Matze

Hier schon eher ein Irrtum als ein Fehler. Bisher wurden (fast) nur Fehler erwähnt.

Da hab ich auch was :mrgreen: (Java)

Code:

Integer i1 = 127; 
Integer i2 = 127; 
System.out.println(i1 == i2);         => true
System.out.println(i1.equals(i2));    => true
 
Integer j1 = 128; 
Integer j2 = 128; 
System.out.println(j1 == j2);         => false
System.out.println(j1.equals(j2));    => true

FehlerVerfänglich ist der Vergleich auf Referenzgleichheit der zufälligerweise wegen Caching zwischen -128 und 127 auch noch klappt... (verschiedene VMs verhalten sich nach 127 unterschiedlich...)

[Alien426]

Zitat:

Zitat von Wolfgang Mix

- IF-Schleife (2260 Hits im Forum)

Da verlinke ich immer gerne zu der Seite auf der alles Wissenswerte zu if-Schleifen steht.

Allgemein nervt mich an Anfänger- oder einfach nur schlechten Programmen, wie mit den Rechnern der Benutzer umgegangen wird.
Erst mal alles in die Registry speichern, dann Dateiarten-Verknüpfungen auf das eigene Progamm verstellen und (weil das erste Programm gleich als Shareware vertrieben wird) eine Datei im System verstecken. Wenn es eine Deinstallier-Funktion gibt, wird die Hälfte dieser Eingriffe nicht rückgängig gemacht.

Der gefühlte Drang, das Programm mit Skin zu versehen, auch wenn der Benutzer mit Themes sowas auch selbst erledigen kann.

Der Missbrauch von Steuer-Elementen.

Der Einsatz von TComboBox mit csDropDown, ohne dass auf eingetippte Werte reagiert wird (auf csDropDownList setzen!).

[DP-Maintenance]

Dieses Thema wurde von "mkinzler" von "Programmieren allgemein" nach "Klatsch und Tratsch" verschoben.
Passt hier besser

[Valle]

Hallo,

Zitat:

Zitat von Matze

Hier schon eher ein Irrtum als ein Fehler. Bisher wurden (fast) nur Fehler erwähnt.
Das trifft auf PHP zu: [...]

das ist aber eher eine Inkonsistenz von PHP als ein Irrtum oder Fehler des Programmierers. In dieser Hinsicht hat PHP leider sehr viele Probleme, was PHP meiner Meinung nach zu schlechtesten Programmiersprache für Anfänger macht. Solange man es richtig macht, kann PHP aber auch was sehr schönes sein. :-) Aber lassen wir das, das ist Offtopic und auch subjektiv. Wollte hier nur sagen, dass ich nicht der Meinung bin, dass hier der PHP-User schuldig ist.

Ich weiß nicht so genau, was der Unterschied zwischen Irrtum und Fehler ist in diesem Fall, aber einer der häufigsten (Der Häufigste?) Fehler ist auf jeden Fall folgendes. (In PHP)

Code:

$result = $database->query('SELECT ... FROM ... WHERE ... = ' . $_GET['arg']);

Außerdem nicht zu vergessen der in C häufigste, älteste, bekannteste und gefährlichste Fehler: Der Buffer-Overflow!

Liebe Grüße,
Valle

[invalid_operation]

Ganz nett finde ich auch den da von mir:

http://www.delphipraxis.net/internal...t.php?t=175115

[Mavarik]

If then else Einrückung...

Mein Senf dazu...

Delphi-Quellcode:

// Einzeilige If's

if bla then
  a := 'xyz';

// Wenn es ein else gibt dann immer!

if bla
  then a := 'xyz'
  else a := 'zyx;

// Mehrzeile If's

if bla then
  begin
    a := 'xyz';
    b := 'abc';
  end;

// Wenn es ein else gibt dann immer!


if bla
  then begin
         a := 'xyz';
         b := 'abc';
       end
  else begin
         a := 'zyx';
         b := 'cba';
       end;

Warum das ganz? ist doch klar! Ich erkenne am if und an der Position des 'then' schon ob es einen else-Teil gibt.

Und zwar in einem range von 3x2 zeichen (von 'I' aus gerechnet)

Besonders interessant: Wenn 'das was' im if then-Tteil steht so lang ist, dass das 'else' nicht mehr auf den Bildschirm passt..

Kommt logischerweise von den alten DOS zeigen 25 Zeilen 80 Zeichen...28 Jahre Programmierung haben auch einige
Regeln hervorgebracht... :zwinker:

Ach ja bitte keine Diskussion das man dann ne Procedure daraus machen soll... :wall:

Und natürlich begin und end immer untereinander um die Zugehörigkeit sofort erkennen zu konnen...

------- Snip ---------

mybool := (A=200);

Würde ich nie machen... weil ich, wenn noch ein Zuweisung dazu kommen, dann doch wieder if then ele benötige...


Mavarik :coder:

[Wolfgang Mix]

... weil hier auch von Fehlern gesprochen wird ...

Als häufigste Anfangerfehler habe ich folgende beobachtet:

- Semikolon bei nicht zusammengehörenden Anweisungen als Zeilenabschluss fehlt

- Semikola in zusammengehörenden Anweisungen (z,B. Begin; ... End;

- End. mehrfach im Programm

- Prozeduren und Funktionen unterhalb des Hauptprogramms (Pascal)

- Doppelte Bezeichner

- Schreibfehler

- Fehlende oder falsche Abbruchbedingungen für Schleifen

- Anzahl von Begin und End stimmt nicht


... kann fortgestzt werden

[invalid_operation]

@Wolfgang Mix: Bitte keine Fehler auflisten. Davon habe ich genug gemacht.

(kein Smiley mit Opera 10.51 reinklickbar)

[Wolfgang Mix]

Dachte ich eigentlich nur als Hilfe für Anfänger

Für meine eigenen Fehler reicht Daniels Speicher nicht :mrgreen:

[Daniel]

Also ich gebe Euch ja Recht, dass das kein schöner Stil sein mag - ein Fehler ist es jedoch nicht, im Hauptprogramm, also der .dpr-Datei, eine Prozedur anzulegen. Und wenn das anständig begründet wird und der Rest des Programms stimmig ist, dann wäre ich u.U. sogar bereit, auch im Hauptprogramm eine kleine - auch nur dort genutzte - Prozedur zu tolerieren.

Ich denke, wir driften jetzt in den sehr schwammigen Bereich der allgemeine Aussagen über guten und schlechten Stil. Bedauerlicherweise hat dieser Bereich eine sehr große Grauzone, die zu diskutieren hier kaum lohnt.

[Wolfgang Mix]

Sorry, du hast Recht,
bleiben wir lieber bei Irrtümern
wie

Delphi-Quellcode:

if eingabe = 7 or 13

[Daniel]

Ich habe dafür noch was aus dem Bereich PHP.

Code:

$data = array();
if ($data == null)
{
  echo 'na holla die waldfee';
}

Bedauerlicherweise schreibt PHP 5.x o.g. Zeichenfolge auf den Schirm, da ein leeres Array als Äquivalenz zu null gesehen wird. Man mag es noch so leidenschaftlich PHP vorwerfen, am Ende muss jedoch ich als Entwickler damit klar kommen und darf nicht dem Irrtum unterliegen, ich könnte auf die hier gezeigte Art und Weise zwischen einem nicht initialisierten und einem leeren Array unterscheiden.

[himitsu]

Zitat:

Zitat von Wolfgang Mix

- Semikola in zusammengehörenden Anweisungen (z,B. Begin; ... End;

Das Semikolon nach dem End ist richtig.

Das nach Begin oder Repeat ist nicht falsch, sondern optional. :angel2:

Man macht da eigentlich keines hin, aber wenn dort Eines ist, dann ist es nicht verkehrt.
Ebenso werden doppelte Semikola tolleriert.

[Wolfgang Mix]

Du hast Recht, aber optisch nervt das schon

[Crazy Ivan]

Zitat:

Zitat von himitsu

Ebenso werden doppelte Semikola tolleriert.

Von Semikolon zu Semikolon reicht dann quasi eine leere Anweisung.


Was auch schön ist:

Delphi-Quellcode:

function GibMirNeStringlist : TStringList;
begin
  Result := TStringList.Create;
  try
  //bla blub
  finally
    Result.Free;
  end;
end;

[Matze]

Zitat:

Zitat von himitsu

Man macht da eigentlich keines hin, aber wenn dort Eines ist, dann ist es nicht verkehrt.
Ebenso werden doppelte Semikola tolleriert.

Es ist zwar nicht verkehrt, aber schlichtweg überflüssig und irritiert (jawohl, da haben wir das Wort) den, der Quelltext lesen muss.
Es werden übrigens nicht nur doppelte ignoriert, sondern alle > 1.
Bzw. ignoriert ist nicht ganz richtig. Es handelt sich einfach um leere und somit überflüssige Anweisungen.

Auch das kompiliert und funktioniert (so programmiert hoffentlich keiner von euch *g*):

Delphi-Quellcode:

function GetAnswer: Integer;
begin
;;;;;;;;;;;;;;;          ;;  ;;  ;;;;;;  ;;      ;;       ;;;;
;;;;;;;;;;;;;;;          ;;  ;;  ;;      ;;      ;;      ;;  ;;
;;Result := 42;          ;;;;;;  ;;;;    ;;      ;;      ;;  ;;
;;;;;;;;;;;;;;;          ;;  ;;  ;;      ;;      ;;      ;;  ;;
;;;;;;;;;;;;;;;          ;;  ;;  ;;;;;;  ;;;;;;  ;;;;;;   ;;;;
end;

Aber genug "OT". ;)

@Daniel: Stimmt, das Verhalten hätte ich auch nicht erwartet.

[arbu man]

Zitat:

Zitat von Daniel

Ich habe dafür noch was aus dem Bereich PHP.

Code:

$data = array();
if ($data == null)
{
  echo 'na holla die waldfee';
}

php ist halt dynamisch typisiert, damit finde ich das verhalten vollkommen Erwartungskonform. Wer wissen will ob der Wer wirklich gleich null ist schreibt halt:

Code:

if ($data === null)
{
  echo 'na holla die waldfee';
}

[Wolfgang Mix]

@Matze:

Mist, wieder 'mal geirrt :(

[Klaus01]

habe leider noch nicht alles durchgelesen,
aber war der schon dabei?

Delphi-Quellcode:

begin
  i:=0;
  while i < 10 do;
    begin
      memo1.Lines.add(IntToStr(i));
      inc(i);
    end;
end;

[edit] hier ist durch das Semikolon (Leeranweisung) hinter dem do
eine Endlosscheife entstanden.


Grüße
Klaus

[Wolfgang Mix]

Zwischendurch möchte ich euch um eines bitten:
Editiert bitte euren Beitrag noch einmel und zeigt auf,
worin nun der Irrtum besteht. Sonst macht mir das
Zusammenfassen 'ne Menge Arbeit. Ich bin halt kein
Universalgenie.

LG

Wolfgang

P.S.: Finde toll, wie gross das Interesse ist :)

[stoxx]

es wäre schön, wenn Du dich nicht nur auf Quelltextfehler beziehen würdest, sondern auch auf "Konstruktionsfehler"
ich mein, alle aufgezählten Fehler sind mehr oder weniger schnell durch den Compiler zu finden oder spätestens wenn das Programm eine Zugriffsverletzung meldet.
Ist zwar vielleicht mal ein netter Zeitvetreib für die Mittagspause, aber nicht dazu geeignet, ein besserer Programmierer zu werden.

Viel wichtiger finde ich solche Fehler einem Anfänger nahezubringen, nicht alles in die Button1 - Click Procedue zu schreiben.
Nicht in "Blackbox" Systemen zu denken und stattdessen den gesamten Code in einen großen Spagettihaufen zu schmeißen.
Oder noch nie was von dem MVC Modell gehört zu haben.
Das finde ich viel wichtiger, als solche kleinen Syntaktischen Fehler, die sich mit jedem Debugger finden lassen, wenn das Programm nicht macht, was es soll ...

Das Problem von Konstruktionsfehler ist nämlich, dass man erstmal schon ein recht gutes Stück weit kommen kann, aber irgendwann in eine Sackgasse landen wird. Denn aus einem VW Polo lässt sich nachträglich nicht mehr zu einem Porsche umbauen, das muss man vorher geplant haben, weil die Plattform dafür einfach nicht geeignet ist.

[Angel4585]

falsch:

Delphi-Quellcode:

 
succ(zaehlervariable);

richtig:

Delphi-Quellcode:

zaehlervariable:=succ(zaehlervariable);

oder

Delphi-Quellcode:

inc(zaehlervariable);