Ist jetzt nicht wirklich Horror (finde ich jedenfalls, ist nämlich von mir ). Fällt vielleicht eher in den Bereich "Coding For Fun", aber ich glaube dazu gibt's hier keinen eigenen Thread.
Wir hatten damals eine Anforderung dass recht umständlich anhand bestehender Status-Informationen ein neuer Status berechnet werden sollte, dabei war es jedoch möglich dass das Ergebnis uneindeutig ist. Laut Kunde war's dann egal welcher Status als gültig betrachtet würde.
Zur gleichen Zeit waren damals in Amerika die Wahlen bei denen G. Bush recht seltsam Präsident wurde (ich meine das erste mal :evil: ). Irgendwie konnte ich's mir nicht verkneifen die ganze Sache als getürkten Wahlkampf zu implementieren.
(ist c++ und der Urnengang ist an der Stelle schon abgeschlossen )
/*
* Get the majority of the voting.
* If we got a tie the democratics will win (we are not in the US)
*/
CStatusVoting* pDemocratics = NULL;
CStatusVoting* pRepublicans = NULL;
for (i = 0; i < aVotingResult.GetSize(); i++)
{
CStatusVoting* pMajority = aVotingResult[i];
if (pDemocratics == NULL)
{
pDemocratics = pMajority;
}
else
{
if (pDemocratics->m_i4Count < pMajority->m_i4Count)
{
pDemocratics = pMajority;
pRepublicans = NULL;
}
else if (pDemocratics->m_i4Count == pMajority->m_i4Count)
{
pRepublicans = pMajority;
}
}
}
if (pDemocratics == NULL)
{
/*
* If we had no relevant Status (nobody voted for our requested status :-( )
* Set a hard coded status
*/
//m_pDesAdv->AddStatus(PACT_MS_DEL_DEL, 251, m_xtPodDate, m_xsSigner, m_xsRemark, TRUE);
}
else
{
// ...
ist doch korrekt nach IEEE-754. Aber es ist natürlich nicht das (vereinfachte) Runden aus der Schule.
Argh, das erinnert mich an ein Problem das ich bei einer Anwendung kürzlich hatte. Da wollte ich berechnete Beträge auf zwei Nachkommastellen runden und
double d = ... // Berechnung des Werts
d = Math.Round(d, 2);
hat nicht so gerundet wie ich es erwartet hab (so wie man es eben in der Schule lernt (DIN_1333 ist das offenbar)).
ich hab noch genau in Erinnerung, dass ich das ausprobiert hatte, bei einigen Testzahlen aber trotzdem zu falschen Ergebnissen kam, weshalb ich mir eben mit ToString() geholfen hatte. Kann jetzt das Problem aber auch gar nicht rekonstruieren, mit meinen Tests eben hat alles funktioniert... Sehr seltsam.
Naja, das ist aber auch nen dämlicher Fehler der nur in Sprachen mit typedefs und Präprozessor der Defines erlaubt, vorkommen kann... In C# ist so ein Fehler nicht möglich (praktisch natürlich schon, aber ungemein leichter zu finden da der Typ ja direkt dasteht)
das schlimmste das ich je gesehen habe war eine Methode die 1436 Zeilen lang war. es war absolut unmöglich da noch irgendwie was zu ändern, sprich einen Kundenwunsch zu implementieren. das war der nackte Horror.
Schlimm an der Geschichte war, das der Programmierer überhaupt nicht verstehen konnte worüber ich mich aufrege als ich ihm erklärt habe, diese methode augenblicklich zu bereinigen. nein er hat es nicht verstanden.
dafür hat er ein exception handling gemacht, wie es detaillierter nicht sein könnte.
Ich glaube er hat sogar die Mondphasen mit einbezogen.. :-)
Das kenn ich mit Backup-Memory. Am Anfang unnötige MB reservieren und falls Not am Mann ist, löscht man sie wieder. Das Hat aber mehr mit Projektmanagement als mit Coding zu tun.
As a man thinketh in his heart, so he is.
- Jun Fan Es gibt nichts Gutes, außer man tut es.
- Erich Kästner Krawutzi-Kaputzi
- Kasperl
Was findest du daran so schlimm? Gut, dass "true == true" ist wohl etwas übertrieben, aber das kann schon mal passieren. Stress, langer Arbeitstag, ....
Gut, true sollte man nicht verwenden. Aber wenn jemand seinen Code so besser versteht, dann soll er das machen. Der Compiler sollte immer den gleichen Code erzeugen. Oder ist das beim MS-Compiler nicht so?
was man dann wiederum umschreiben kann zu....
was man dann nocheinmal umschreiben kann zu.... :evil:
@Xynratron:
Jeder schreibt seine Code so, wie er ihn gerade braucht und auf seinem eigenen Kenntnisstand / seiner eigenen Entwicklung basierend. Wenn der Autor den Code in zwei Jahren sieht, weiß er vielleicht auch ein, zwei Wege, wie es eleganter gegangen wäre.
@Siassei:
Aber im Großen und Ganzen hast du recht. Ich bin auch der Meinung, == true ist nicht gerade gut lesbar und auch nicht schön (wobei "Schönheit" gerade beim Coding Style Definitionssache ist), aber Coding Styles Horror würde ich es nicht nennen.
Gruß, Christian.
There are 10 types of people in the world:
Those, who think they understand the binary system
Those who don't even have heard about it
And those who understand "Every base is base 10"
naja, lasst mal die Kirche im Dorf. In dem Code waren definitiv 2 Fehler:
b1 == true == true
b1 & b2
ob == true/false jetzt gut oder schlecht ist. Naja ohne ist es für mich besser zu lesen.
Ich dachte da wäre in meinem Posting noch der Satz "Da hat wohl jemand was gelöscht" über dem Coding-Horror-Zitat gestanden, (lt. einem Kollegen hat das wohl auch der Wahrheit entsprochen) gestanden^^ Das hätte zumindest das "== true == true" erklärt.
Imho sehr schön zu lesen und auch klar was nicht passiert, aber umständlich zu schreiben.
:-)
Xynratron
Edith + PS: die { } verlängern zwar den Code hier, verdeutlichen aber hoffentlich was ich meine. Ohne wäre diese Routine noch lesbarer (s.o. bei ANSI_code)
PPS: Hab oben einen Satz etwas präzisiert. Nicht das jemand denkt, mir wäre ein ganzes Posting abhanden gekommen.
Dieser Beitrag wurde 4 mal editiert, zum letzten Mal von Xynratron am .
Herr, schmeiss Hirn vom Himmel - Autsch!
Zitat von herbivore
Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.
Naja - korrekterweise muss man sagen, dass das '&' nicht zu einem falschen Ergebnis geführt hat (das wäre wahrscheinlich auch schon vorher aufgefallen). Es wurde eben nur die Kurzschlussauswertung außer Kraft gesetzt.
Trotzdem sieht der Code grauenhaft aus - denn eigentlich reicht ein Einzeiler:
