Das schwieigste was mir bisher begegnet ist war ein VB.NET Projekt das von ehemaligen VB4/VB6 Entwicklern erstellt wurde. Hier waren in der "Main Form" >25.000 Zeilen Code zu finden - sprich: Nahezu das komplette Projekt. Methoden waren teilweise über 7 Bildschirmseiten lang und die meisten Variablen "Modulglobal" definiert.

Aber am schlimmsten sind die alten "On Error goto Next" bzw.

Try
Catch (Ex as Exception)
//Hier wird absichtlich nichts gemacht nach dem Motto: Wenn man keinen Fehler sieht, ist auch keiner passiert :-(
end try

Was ist für dich der nervigste / schlimmste Programmierstil der dir bisher in deiner Karriere begegnet ist?

Ich hatte mal ein ANSI C Programm mit zehtausenden Codezeilen und gut darin versteckt:

define("while","until");

Nun versucht mal das Verhalten zu verstehen, wenn dort steht:

int i = 0;
do
{
  // something
  i++;
}until(i < 1000);

Da waren sogar noch mehr solche Perlen drin :)

Das schlimmste für mich ist wenn ein anderer Entwickler meine Architektur zerstört. Sei es weil diese nicht verstanden ist oder weil er schlicht zu faul ist den Mehraufwand einer sauberen Architektur durchzuziehen.
Jüngstes Bsp: Das durchbrechen meiner Indirektion indem eine Assembly einfach Referenziert wird und „mal schnell“ direkt gegen die Implementierung programmiert wird.

Grmpf……aaaaarrrrrrggghhhhhh

Bad Programming: a collection of worst codes in the world

Mit dabei:

#define private public

Wo es mir immer wieder die Sicherungen haut, sind untypisierte string Vergleiche von DateTimes oder Integern.
Sowas in der Art:

if (DateTime.Now.Date.ToString() == "14.04.2011 00:00:00")
  Console.WriteLine("Ich bin ein Idiot und sollte den Beruf wechseln!");

oder sowas

//(Jo ich benamse bei solch kleinen Sachen oder demonstrationen einen Integer mit z1)
int z1 = GetIntValue();

if (z1.ToString() == "3")
    Console.WriteLine("Ich bin ein Idiot und sollte den Beruf wechseln!");

//Jojo, ich weiß da steht 2mal es gleiche, aber ich schreib jetzt ka extra Methode ;)

++++++++++
 [
  >+++++++>++++++++++>+++>+<<<<-
 ]                       Schleife zur Vorbereitung der Textausgabe
 >++.                    Ausgabe von 'H'
 >+.                     Ausgabe von 'e'
 +++++++.                'l'
 .                       'l'
 +++.                    'o'
 >++.                    Leerzeichen
 <<+++++++++++++++.      'W'
 >.                      'o'
 +++.                    'r'
 ------.                 'l'
 --------.               'd'
 >+.                     '!'
 >.                      Zeilenvorschub
 +++.                    Wagenrücklauf

Schlimmer Programmierstil :o)

Das beste, was ich mal gesehen hab, war Code, der von Kollegen in Fernost kam. Die sollten Code schreiben, der Straßennamen in einer Komponente verfügbar macht. Anstatt eine Textdatei mit den Namen zu bauen und die dann einzulesen, haben sie die Namen in den Code geschrieben:

List<string> streets = new List<string>();
streets.Add("Asamstraße");
streets.Add("Behamstraße");
streets.Add("Clemensstraße");
...
streets.Add("Zeppelinstraße");

Passend zu der if(myValue==true)-Methode gibts auch noch die Möglichkeit, den Abbruch einer Schleife zu erzwingen:

max = 10000;
  for(i=1; i<max; i++)
  {
    if( abbruchbedingung )
      i = max;
    else
    ...

Sehr schön finde ich übrigens auch, wenn Variablen zwar urspünglich sprechend bezeichnet waren, sich ihre Bedeutung aber mit der Zeit ins Gegenteil verkehrt hat.
Oder eine gute Mischung aus deutschen, englischen und denglischen Bezaichnern.

Gruselig!

Folgende Elemente führen aus meiner Sicht automatisch zu Programmierkatastrophen:

- "Hacken" einer API (z.B. durch Nutzung von Reflection um Zugriff auf private Member zu erhalten)
- Fehlende Granularität (Stichwort Methodenlänge, Klassenlänge)
- Verkehrte Weltvorstellung (z.B. Erde ist eine Scheibe, Wettermodell liefert falsche Ergebnisse)
- Semantische Uneindeutigkeit
- Durchlässigkeit von inkonsistenten Daten. (Führt zu Fail-Save-Operationen an jeder Stelle, wo die inkonsistenten Daten verarbeitet werden)
- Eierlegende Wollmilchsäue (Methoden saveOrUpdate, getOrCreate, save(Object))
- generische Allgemeinplätze ( Object doSomething(Object o) )
- Heisenberg'sche Unschärferelation (Getter, die Objektzustände semtisch ändern)
- "Weiterarbeiten" mit "mäßigen" Implementationen (Don't touch it-Phänomen)-
- Schlechtes Exception Handling (führt dazu, dass exceptions einfach weitergereicht werden)
- Fehlende Modularisierung (Große, nicht handlebare Moule)
fehlende Normalisierung (zig Stellen im Code müssen für eine semantische Änderungen angepasst werden)

Mich regt folgendes auf:

StreamWriter sw = ...;
...
sw.Flush();
sw.Close();
sw.Dispose();

Das zeigt, dass sich derjenige keine Sekunde mit der API befasst hat und zudem noch die gängige using-Pattern nicht kennt. Abhilfe ist natürlich:

using(StreamWriter sw = ...) {
...
}

Das ist auch Exception-sicher.

Das schlimmste, was mir begegnet ist, waren Abfragen an die Datenbank, die als SQL in einer PHP-Seite standen. Das ist zwar übliche Praxis und unter Performance-Gesichtspunkten vielleicht auch verständlich, macht aber den Code absolut unlesbar, die Fehlersuche wird zur Qual. Das Schlimmste daran ist aber, dass ich den Code auch noch selbst geschrieben habe. Ist zwar schon lange her, aber man schämt sich trotzdem immer noch dafür.

ganz allgemein fällt mir hier auf: jeder findet den stil,

*) den er selbst vor langer zeit hatte
*) eigenheiten, die entwickler von anderen sprachen mitgenommen haben
*) alles was er nicht selber so machen würde

als schlechten stil.

ich sag jetzt dazu ganz - wahrscheinlich in oppostion zu allen anderen hier - folgendes:

da erfahrungsgemäß der "mehraufwand", der mit "gutem stil" einhergeht, nicht bezahlt wird, begegnet man immer wieder "schlechtem" stil (hauptsache, schnell und es funktioniert).

das hat mich auch jahrelang gestört (eher: jahrzehnte), aber mittlerweile auch schon bald ein jahrzehnt) ist es mir wurscht: wenn der stil schlecht ist, kostet die änderung halt jetzt mehr! oder es gibt sie nicht, wenn das zu teuer ist.

beispiel: wörtlich hat mir ein auftraggeber (der das erzeugnis an seine kunden verkauft) gesagt: wenn das geld nicht reicht, machen wir es halt mit weniger funktionalität.

muss ich da noch was dazusagen?

Mittlerweile find ich auch ganz hübsch:

int reportWanted = CheckArgumentsOfProgramSomeHow();
switch(reportWanted)
{
  case 0: DoDefaultReport();
  case 1: DoReport1(); // Benutzer-Auswertung
  case 2: DoReport2(); // Auswertung nach Bestand
  ..
  case 115: DoReport115(); // Bericht für Kunde xyz
}

1. Vollkommen selbsterklärender Code
2. jederzeit erweiterbar... was will man mehr?

Ich hatte mal mit Code zu tun, der HTML-Code manipuliert hat. Aus Gründen, die ich vergessen habe, gab es die Notwendigkeit, das '.'-Zeichen zu escapen. Der dafür zuständige Senior(!)-Entwickler (Architekt mag ich ihn wirklich nicht nennen) hatte dafür den genialen Einfall, einen String zu bilden aus den Anfangsbuchstaben aller 5 Entwickler im Team und deren Nachnamen, also etwa "hmuellerbschulzfmeyercschneider". Mit diesem Bandwurm wurde dann jeder einzelne Punkt im HTML-Code ersetzt!

Übrigens gab es dann gewisse Performance-Probleme... aber bei weitem nicht nur aus diesem Grund.

Der gleiche Typ hat übrigens auch sein Geburtsdatum als "expires"-Header an den Browser übermittelt, um das Cachen der Seiten zu verhindern.

Ok, einen hab ich noch. Es gab mal einen Vorschlag, die Dateizugriffe im Netzwerk zu beschleunigen, in dem man ganz tief in der untersten Bibliotheksschicht hardgecoded eine Datei immer zuerst auf C:\ sucht.

Wohlgemerkt, der Quelltext lief unter Mac, Linux und das dritte System hab ich vergessen ;-)

Meine Erfahrung ist, dass manches, was als schlechter Stil empfunden wird, nur ungewohnt ist. Z.b. fand ich die "lazy-init-pattern"

public Klasse Property
{
    get { return feld ?? (feld = new Klasse()); }
}

früher dirty. Inzwischen erscheint sie mir natürlich und steigert meine Effizienz.

Das ist mir gerade eingefallen. Ich denke mal, dass man dies als schlechten Programmierstil bezeichnen kann, aber auch in einer gewissen Weise interessant. :-)

(new Thread (delegate() { try { ((IOperator)(obj)).Run(); } catch { } })).Start();

Allgmein kann ich Code nicht ausstehen, der folgender maßen aussieht:

String s;
String s1;
String s2;
String s3;

public a()
{
   s1 = s2;
   ...

}

Sprich, wenn die Leute keine vernünftigen Bezeichner für ihre Variablen oder Methoden haben.
Wenn dann auch nicht mal darauf geachtet wird, ob vielleicht eine member-variable eine globale überlädt, dann is der Ofen endgültig aus.
Ein weiteres Highlight was ich mal betrachten durfte war folgendes:

while(something = true)
{
   do something
}

Als der Verursacher dann endlich drauf gekommen zu sein schien was falsch ist hat er folgendes draus gemacht. :)

while(true)
{
    if(something = false)
   {
      break;
   }
   do something
}

Fazit:
Setzen, 6.

Ich hab noch was zum Thema QBasic!
Als Anfänger sollte ich in den Jahre 2001-2002 eine QuickBasic Anwendung (von meinen Chef in den 80ger und 90ger programmiert) zur Rezeptoptimierung für "Gross-Schlachtereien" nach VB.net portieren. Mahtematisches Prinzip war die LineareOptimierung. Das Programm bestand aus einer Datei BSRezopt.bas

Kleine Kostprobe:



PS: Dann schon lieber Ook! :o)

Die schlimmsten sachen die ich leider schon als ernsthaften code sah waren folgendes:

void ShowString(string value)
{
    this.TextBox.Text = value.ToString();
}

und

void IEnumerable ListToIEnumerable(List<int> zahlen)
{
    return (from c in zahlen select c).ToEnumerable<int>();
}

if !(Bedingung != true) { ... }

*Facepalm*

Ich hab auch mal was schönes gesehen:

if(MyValue) //Der If-Block war immer leer. Es war immer nur der else-Block gefüllt.
{
}
else
{
...DoSomething...
}

Ach das ist ganz einfach: Fortran mit 6 Leerzeichen vor jeder Zeile. Was für ein Bullshit.

Ist mir bei altem C Code begegnet: Print()-Routinen für irgendwelche structs, in denen aber auch Variablen gesetzt werden. Die print()-Routinen werden allerdings nur bei Setzen eines printflags ausgeführt, hauptsächlich für debug-Zwecke... ;-(
Eieiei...