Wie kommentiert ihr?

asc schrieb:

Zu große Funktionen deuten immer auf einen schlechten Stil hin. Funktionen sollten nur so groß sein das man sie noch sinnvoll überblicken und verstehen kann. Daher sehe ich diese Form der Kommentierung eh als Schwachsinn an.

schon richtig, aber manchmal gibts switch/case-anweisungen die ganz schön lang sein können. da ist so'n kommentar */* end of switch(...) / gar nicht so verkehrt.

Knuddlbaer

mal abgesehen davon dass wenn eine funktion ueber mehr als eine seite geht, du andere probleme hast als kommentare...

z.B. die Realität wie Praxis oder Wirtschaftlichkeit - manchmal auch einfach switch Statements.

byto

-fricky- schrieb:

asc schrieb:

Zu große Funktionen deuten immer auf einen schlechten Stil hin. Funktionen sollten nur so groß sein das man sie noch sinnvoll überblicken und verstehen kann. Daher sehe ich diese Form der Kommentierung eh als Schwachsinn an.

schon richtig, aber manchmal gibts switch/case-anweisungen die ganz schön lang sein können. da ist so'n kommentar */* end of switch(...) / gar nicht so verkehrt.

Wo wir wieder beim schlechten Stil wären...

byto schrieb:

Wo wir wieder beim schlechten Stil wären...

was tust du denn z.b. gegen einem switch mit 30 cases?

by the hammer

SideWinder

Gibt verschiedene Möglichkeiten, zB:

methods[case].invoke();

MfG SideWinder

SideWinder schrieb:

Gibt verschiedene Möglichkeiten, zB:
methods[case].invoke();

das fängt nicht den default-fall ab. ausserdem erzeugen compiler für sitch/case-konstrukte sehr effizienten code, was bei einer tabelle mit function-pointern nicht immer gegeben ist. also ich finde es nie gut, performance gegen 'schönen code' zu tauschen.

mit C++-style kommentaren statt C-style kommentaren

byto

-fricky- schrieb:

byto schrieb:

Wo wir wieder beim schlechten Stil wären...

was tust du denn z.b. gegen einem switch mit 30 cases?

Polymorphie nutzen.

Bashar

byto schrieb:

Polymorphie nutzen.

Gratulation, du hast gerade eine Funktion zu 30 vom Designstandpunkt her völlig überflüssigen Klassen vereinfacht.

SideWinder

-fricky- schrieb:

SideWinder schrieb:

Gibt verschiedene Möglichkeiten, zB:
methods[case].invoke();

das fängt nicht den default-fall ab. ausserdem erzeugen compiler für sitch/case-konstrukte sehr effizienten code, was bei einer tabelle mit function-pointern nicht immer gegeben ist. also ich finde es nie gut, performance gegen 'schönen code' zu tauschen.

Ich würde immer Performance gegen "schönen Code" tauschen. Aber abgesehen davon, habe ich nicht behauptet, dass mein Code "schön" ist. Es war nur ein Beispiel. Das kommt dann immer auf das konkrete Beispiel an. Aber Dinge wie:

switch(errorcode)
{
    case 404: return NLS.get("DOC_NOT_FOUND"); break;
    ... // weitere 1000 fälle
}

rgen mich ganz furchtbar auf:

String str = NLS.get(errorMap.get(404));

MfG SideWinder

SideWinder

Wobei, wenn man tatsächlich mehr als 5 "Modi" hat die alle differenten Quellcode zur Ausführung bringen und die wirklich (meistens Designschwäche) durch das selbe switch abgedeckt werden sollen, würde ich schon auf dynamischen Methodenaufruf setzen (da brauch ich dann auch keinen default-Fall, denn default-mäßig ruft mein Benutzer nicht den Punkt File->Open auf ... im Notfall kommt eine NotFoundException und auf die kann ich dann reagieren).

MfG SideWinder

byto schrieb:

Polymorphie nutzen.

ich wusste doch, dass es noch sinnvolle anwendungen von OOP gibt.

SideWinder schrieb:

Wobei, wenn man tatsächlich mehr als 5 "Modi" hat die alle differenten Quellcode zur Ausführung bringen und die wirklich (meistens Designschwäche) durch das selbe switch abgedeckt werden sollen, würde ich schon auf dynamischen Methodenaufruf setzen.

die designschwächen machen aber oft andere (siehe dein beispiel mit dem http) und damit muss man leider leben.

SideWinder schrieb:

im Notfall kommt eine NotFoundException und auf die kann ich dann reagieren).

das halte ich wiederum für schlechten stil: exceptions einzusetzen, obwohl man mit einem einfachen 'if' testen kann, ob ein wert überhaupt gültig ist.

tfa

Bashar schrieb:

byto schrieb:

Polymorphie nutzen.

Gratulation, du hast gerade eine Funktion zu 30 vom Designstandpunkt her völlig überflüssigen Klassen vereinfacht.

Woher willst du das wissen? Vielleicht hat er auch unwartbaren Spaghetticode zu einem vernünftigen OO-Design gemacht.

SideWinder

@fricky: Naja, grundsätzlich kann der Benutzer keine nicht vorhandenen Menüpunkte aufrufen. Also handelt es sich in so einem Fall imho sehrwohl um eine Exception.

Edit: Ja, damit muss man wohl leben. Aber man muss diese Schwächen (warum auch immer die hier sind - gibt es eine bessere Methode?) nicht auch noch mit schwachem Code in das eigene Projekt hineinziehen.

MfG SideWinder

SideWinder schrieb:

@fricky: Naja, grundsätzlich kann der Benutzer keine nicht vorhandenen Menüpunkte aufrufen. Also handelt es sich in so einem Fall imho sehrwohl um eine Exception.

nichtvorhandene menüpunkte triggern keine aktionen, also können auch keine exceptions auftreten. aber ich glaube, so langesam reden wir aneinander vorbei.

Bashar

tfa schrieb:

Bashar schrieb:

byto schrieb:

Polymorphie nutzen.

Gratulation, du hast gerade eine Funktion zu 30 vom Designstandpunkt her völlig überflüssigen Klassen vereinfacht.

Woher willst du das wissen? Vielleicht hat er auch unwartbaren Spaghetticode zu einem vernünftigen OO-Design gemacht.

Da er nicht mehr Informationen hat, als dass da eine Funktion ein längliches Switch enthält, ist das unwahrscheinlich. Reflexartig irgendwelche Patentrezepte auf nichtexistente Probleme anzuwenden ist eigentlich eher das, was unwartbare Designs erst erzeugt.

tfa

Bashar schrieb:

Da er nicht mehr Informationen hat, als dass da eine Funktion ein längliches Switch enthält, ist das unwahrscheinlich.

Und aus diesen wenigen Informationen kannst du ableiten, dass OO hier böse ist und er lieber ein Spaghetti-Switch machen soll? Respekt! Ich trau mir das nicht zu.

Hast du schonmal was vom State Pattern gehört? Wer es nicht kennt läuft Gefahr, das eine oder andere überflüsse switch in seinen Code einzubauen, statt ein wartbares Entwurfsmuster zu verwenden. Das soll natürlich nicht heißen, dass switch völlig überflüssig und immer zu ersetzen ist. Aber nachdenken sollte man schon drüber.

Bashar schrieb:

Reflexartig irgendwelche Patentrezepte auf nichtexistente Probleme anzuwenden ist eigentlich eher das, was unwartbare Designs erst erzeugt.

Ich finde reflexarte Ablehnung von OO-Mustern viel gefährlicher. Außerdem würde ich ein überlanges switch nicht als "nichtexistentes" Problem ansehen.

DEvent

byto schrieb:

Nicht mehr dokumentieren als zum groben Verständnis nötig. Schließlich muss man die Doku beim Code-Refactoring immer mitpflegen. Je kürzer die Dokumentation, umso leichter fällt das. Je leichter es fällt, umso häufiger wirds gemacht.

Und nichts ist schlimmer, als eine veraltete (falsche) Dokumentation. Die ist dann nämlich schlechter als gar keine Doku weil irreführend!

Der einzige Fall in dem du die Dokumentation aendern musst, ist es, wenn du das Interface der Methode veraenderst.

Wie loks richtig gesagt hat, soll die Dokumentation aussagen was die Methode machen soll. Wie sie es macht, kann sich sicher oft aendern.

*john 0

-fricky- schrieb:

also ich finde es nie gut, performance gegen 'schönen code' zu tauschen.

Das sind Mikrooptimierungen, die nur als Ausrede für schlechten Code verwendet werden. Select-Orgien werden in massenweise bedingte Sprünge übersetzt und die bringen die spekulative Ausführung der CPU ziemlich durcheinander. Wann welcher Code schneller ist hängt auch von den Cache-Größen, wie oft der Code durchlaufen wird ab etc. pp.

Ohne Profiling einfach so zu postulieren Code A sei schneller als Code B halte ich zumindest für gewagt. Ein sauberes Design ist aus Gründen der Wartbarkeit vorzuziehen, und nur im Falle von nicht ausreichender Performance ist darauf zu verzichten.