Und hier der Coding-Horror unserer älteren Kollegen mit nichtssagenden
Namen und Literalen. Kein Mensch kann den Code lesen, er bricht alle
Benamungsregeln und optimiert nicht 2²!
Dein Beispiel ist doch Mumpitz.
ImaginärDiskriminatorSchwelle ist sicher nicht vorschriftsmäßig.
Deutsche Variablennamen finde ich insgesamt fragwürdig.
p und q finde ich in dem Falle auch akzeptabel.
Willst du uns also trollen oder möchtest du wirklich darauf hinaus, dass
es Leute geben soll die Probleme bei der Benennung haben?
Denk daran:
"There are only two hard things in Computer Science: cache invalidation
and naming things."
-- Phil Karlton
Ehrlich gesagt, gefällt mir die zweite Version aber besser, weil man
sofort auf einen Blick sieht, was gemacht wird.
Was soll denn die erste Version sein? Waldorf-C?
Das zweite Beispiel ist klar übersichtlicher.
Bis ich beim ersten herausgefunden habe, welche Werte durch
DefaultWertBeiImaginaerenLoesungen und
FehlerReturnWert_KeineLoesungImReellenausgedrückt werden ist der Tag
doch rum, lediglich LoeseQuadratischeGleichung als Funktionsname finde
ich besser.
Die Umlaute sind gar noch illegal und schön rot hervorgehoben.
In beide gehört zur defensiven Programmierung aber noch if(x1) etc. vor
die über Pointer gehenden Zuweisung.
Ich finde auch das 2. lesbarer.
jede Konstante als viel zu langes Wort ist einfach nicht überschaubar.
Wenn ich einen Wert durch 2 rechen muss, dann macht man doch keine
Konstante dafür. (so lange die 2 nicht ein wert ist der mehrfach
verwendet wird und eine spezielle Bedeutung hat)
Marek N. schrieb:> Ehrlich gesagt, gefällt mir die zweite Version aber besser, weil man> sofort auf einen Blick sieht, was gemacht wird.
Solange man es wirklich auf einen Blick sieht!
Alles was außerhalb dieses Sichtbereiches liegt, sollte ein wenig in
Richtung erste Variante gehen.
Ich halte das für getrolle oder wenigstens satire.
Natürlich ist die 2. Lösung viel einfacher zu interpretieren, weil
kürzer. und was beinder pq formel p,q,x1 und x2 sind sollte doch jeder
schulabgänger ergoogeln können.
Im übrigen fehlen die doxygen-header...
WaMin schrieb:> Ja, schon schlimm solche Kollegen, die die erste Variante produzieren.> Die zweite Variante ist natürlich viel lesbarer.
Ich glaub das hat der TO schon so gemeint. Das Problem ist dass die
zweite Variante auch nicht gut ist, wenn auch aus anderen Gründen. :D
Sven B. schrieb:> Ich glaub das hat der TO schon so gemeint. Das Problem ist dass die> zweite Variante auch nicht gut ist, wenn auch aus anderen Gründen. :D
(>) Ich glaub das hat der MaWin schon so gemeint.
Hmm, Terry Pratchett würde wohl sowas sagen wie: Guter Code ist nicht
das Gegenteil von schlechtem Code, sondern lediglich die Abwesenheit
davon. Wenn man Code so "gut" macht, dass er den Gutpunkt überschreitet
und auf der anderen Seite wieder rauskommt, dann kommt die erste
Variante heraus.
Um die vollends unleserlich zu machen, empfehle ich ein "#define
QuadratWurzelVon sqrt" und ein "typedef
GleitKommaZahlMitDoppelterGenauigkeit double".
Es ist ja vollkommen in Ordnung, ein und dieselbe Variable an
verschiedenen Stellen unterschiedlich zu benennen, denn wir haben ja
schon in der Schule beim Aufsatzschreiben gelernt, dass häufige
Wortwiederholungen schlechter Stil sind. Da der C-Compiler aber nicht so
gut Deutsch kann, um zu erkennen, dass mit TermUnterWurzel und
Wurzelterm dasselbe gemeint ist, sollte man ihm dies mit der Zeile
1
#define Wurzelterm TermUnterWurzel
mitteilen. Da die Variable insgesamt viermal im Code auftaucht, sollte
man sich aber im Sinne einer weiteren Stilverbesserung noch zwei weitere
aussagekräftige Synonyme ausdenken bspw.
Marcus H. schrieb:> Marek N. schrieb:>> .... Waldorf-C?>> you made my day!
Wenn er seinen Sourcecode tanzen kann ...
You put your right foot in
You take your right foot out
You put your right foot in
And you shake it all about
You do the hokey pokey
And you turn yourself around
That's what it's all about
Ich weiß nicht, was gegen anständige Variablennamen spricht. Im Betrieb
war es früher so, daß z.B. Magnetbänder und Wechselplatten nach ihrem
Inhalt benannt waren:
KAUZ= Kaufteile zusammengefasst
AKST= Arbeitskräfte Stammdaten
PAUL= Programme Anderer Unterproduzenten und Lagerorte
Das verstehe ich unter vernünftigen Abkürzungen.
MfG Paul
> "There are only two hard things in Computer Science: cache invalidation> and naming things.">> -- Phil Karlton
Falsch:
"There are only two hard things in Computer Science: cache invalidation,
naming things and off-by-one-errors"
Paul B. schrieb:> Ich weiß nicht, was gegen anständige Variablennamen spricht. Im Betrieb> war es früher so, daß z.B. Magnetbänder und Wechselplatten nach ihrem> Inhalt benannt waren:> KAUZ= Kaufteile zusammengefasst> AKST= Arbeitskräfte Stammdaten> PAUL= Programme Anderer Unterproduzenten und Lagerorte>> Das verstehe ich unter vernünftigen Abkürzungen.>> MfG Paul
Tja, und in SAP-Zeiten hast du dann so kryptische Namen wie "ZMM01EX"
und musst auf "Maschinenbau" klicken, wenn du nen Widerstand anlegen
willst, während hingegen man im gesamten System keine M3-Mutter finden
kann ballaballa
Soeren K. schrieb:> Deutsche Variablennamen finde ich insgesamt fragwürdig.
Besser gutes Deutsch als schlechtes Englisch.
Da kenne ich z.B. den Fall, dass einer die deutsche "Glocke" in eine
englische "Clamp" übersetzt hat. Als Tipp: der mentale Umweg war die
"Schelle"...
Achim S. schrieb:> Und hier der Coding-Horror unserer älteren Kollegen mit> nichtssagenden Namen und Literalen.
"p-q-Formel" ist eine bekannte Bezeichnung für das Ding, siehe
https://de.wikipedia.org/wiki/Quadratische_Gleichung#p-q-Formel
Die Bezeichner sind also nicht "nichtssagend" sondern beziehen sich auf
eine bestimmte, weithin bekannte (Lösungs-)Formel, die heutzutage jeder
Schüler auswendig lernt wie ein Gedicht.
Und der Code versuchte, diese Formel möglichst leserlich darzustellen,
was in C ja einigermaßen gut geht -- bis auf die Quadratwurzel, die als
sqrt ausgetextet werden muss.
Und jetzt setze deine Blubberbezeichner ein und setze die Formel z.B. in
TeX und bewundere das "voschriftsmäßige" Ergebnis.
> Kein Mensch kann den Code lesen, er bricht alle Benamungsregeln
Der Funktion sollte entsprechend kommentiert sein und die Formel nennen,
die sie implementiert, z.B. als TeX oder ASCII-Formel oder / und Link
und Referenz zur Fachliteratur. Da findet sich jeder zurecht, der nicht
in der Schule komplett gepennt hat :-)
Daran, dass das Zeug nicht kommentiert ist, scheitern aber beide
Versionen.
Und was du das als "voschriftsmäßig" abgeliefert hast lässt fief
blicken. Sehr tief.
> optimiert nicht 2²
Glückwunsch. Du hast erfolgreich die Semantik des Codes gepimpt und
bekommst weniger Lösungen als das Original. Warum das so ist: =>
Hausaufgabe.
Das dein Code ineffizienter ist -- geschenkt.
> Kennt Ihr auch solche Kollegen?
Zum Glück kenn ich keine, die Code duch Logorrhoe verschlimmbessern
büssen, um ihre Brötchen zu verdienen. Und die Regeln zur
Quellformatierung sehen arg Hausbacken aus, da hat sich jemand WIRKLICH
eingebracht und was geschaffen :-/
> Sprechende Namen sind das A und O.
Gerne
> TermUnterWurzel
Baby-Sprech. Das Ding heißt in dem Kontext "Diskriminante"
https://de.wikipedia.org/wiki/Diskriminante
und auch nicht "Diskriminator" oder was auch immer.
Falls es primär um Wurzelziehen geht, gern auch "Radikand". Aber wer
"TermUnterWurzel" verwendet, der schreckt auch nicht zurück vor
1
VariableLinksVomPlus+VariableRechtsVomPlus
> *ErsteLoesung> *ZweiteLoesung
Erstens sind es ZEIGER auf die Lösungen und nicht die Lösungen selbst.
Zweitens sind die Lösungen -- falls reelle existieren -- der Größe nach
geordnet, was aber auch nicht klar ist. Wie das Verhalten bei einer
Lösung (Diskriminante = 0) ist, bleibet der Phantasie des Lesers
überlassen.
> const double FaktorQuadratDivisor = 4;> const double FaktorDivisor = 2;
Wenn überhaupt dann
> const double FaktorDivisor = 2;> const double FaktorQuadratDivisor = FaktorDivisor * FaktorDivisor;
Aber wenn du die Lösungsformel in der Doku hast, dann brauchts keine
Schwurbelbezeichner. Außerdem handelt es sich nicht um einen Faktor (der
wäre 1/2 bzw. 1/4) sondern um einen Divisor. Der Bezeichner ist also
zumindest missverständlich.
Guter Code wird versuchen, eine Formel, die in mathematischer Notation
vorliegt, in ihrer Struktur und Notation zu erhalten. Falls das nicht
möglich ist, z.B. wegen anderer Konditionierung, gehört das kommentiert
und erklärt.
> Anbei ein Beispiel wie eine Funktion> vorschriftsmäßig bei uns aussehen sollte:> #define FehlerReturnWert_KeineLoesungImReellen (1)> #define ReturnWert_AllesOK (0)
"Alles OK" ist erstens Falsch, weil es zu einem Überlauf kommen kann.
Zweitens ist "AllesOK" ziemlich nichtssagend und könnte
"ZweiLoesungenImReellen" heißen, was aber immer noch sperrig ist.
Erittens: Warum Makros anstatt Enum für den Return-Wert? Oder die Anzahl
(nicht notwendigerweise unterschiedliche) Lösungen zurückliefern.
Weiters ist es nicht klug, Bezeichner nach einem bestimmten Kontext zu
benennen, wenn sie auch in einem anderen Kontext verwendet werden. Nimm
den Caller deiner Funktionen, die wollen auch diese Bezeichner
verwenden. Aber es ist dort nicht der Return-Wert des Callers gemeint,
sondern der Return-Wert des Callees => Potentielle Quelle der
Verwirrung.
> const double ImaginärDiskriminatorSchwelle = 0;>> if(Wurzelterm < ImaginärDiskriminatorSchwelle )
Reingefallen. Eine Variable dieses Namens gibt es nicht. Dass sie
besser "Diskriminante" oder "discriminant" oder wie auch immer heißen
würde, steht bereits oben. Und eine quadratische Gleichung hat eben
keine reele Lösungen, wenn die Diskriminante negativ ist. Ein
1
// Eine quadratische Gleichung mit negativer Diskriminante hat
2
// keine reelen Loesungen.
3
4
if(discriminant<0)...
wird selbst in deiner Firme niemand intelektuell überfordern. Oder doch?
> const double DefaultWertBeiImaginaerenLoesungen = NAN;
Es jandelt sich i.d.R. nicht um imaginäre Lösungen, sonder um komplexe.
Wenn schon Klugscheißen, dann richtig ;-)
> *ErsteLoesung = DefaultWertBeiImaginaerenLoesungen;> *ZweiteLoesung = DefaultWertBeiImaginaerenLoesungen;
Was ist schlecht an NAN oder Not-A-Number? Warum über einen
Zwischenbezeichner her, den man erst "nachschlagen" muss?
1
entia non sunt multiplicanda praeter necessitatem
Außerdem sind die Bezeichner inkonsistent: Der return-Wert bezieht sich
auf Lösungen im Reellen, aber die Werte auf Lösungen im Imaginären.
Das passt nicht zusammen.
Insgesamt: Operation gelungen, Code tot und weit(!) über das Ziel
hinausgeschossen und den Fetisch zur Überspezifizikation voll ausgelebt.
Da hat sich echt jemand ersetzlich gemacht.
Achim S. schrieb:> Sprechende Namen sind das A und O. Anbei ein Beispiel wie eine Funktion> vorschriftsmäßig bei uns aussehen sollte:
Lass mich raten: Du wirst nach produziertem Datenmüll bezahlt. Effizient
ist was anderes.
Sprechende Namen sind schon sinnvoll, aber Beispiel 1) des TE finde ich
arg konstruiert. Das ist natürlich weit über jedes sinnvolle Maß
hinausgeschossen und (hoffentlich) praxisfern.
Bei der Formel kann man gerne q und p, oder meinetwegen a, b, c
verwenden.
Zählervariablen heißen auch bei mir i und j.
Dennoch sind aussagekräftige Namen bei "eigenem" Code, wo also nicht nur
stumpf eine Formel runtergecodet wird sinnvoll.
userString und parsedUserString könnte es bei mir durchaus geben.
userStringWithSpacesAndTabsRemoved dagegen ist überzogen und fällt für
mich in die Kategorie Fiktives Extrembeispiel.
Lothar M. schrieb:>> Deutsche Variablennamen finde ich insgesamt fragwürdig.> Besser gutes Deutsch als schlechtes Englisch.
Neben der treffenderen Semantik bei einem (auch künftig) rein deutschem
Team, hat es auch den Vorteil, dass Bezeichner sich von den
Schlüsselwörtern und Library-Bezeichnern abheben. Quasi linguistisches
Croma-Coding.
In den 70ern wurde wohl mal überlegt, Compiler quasi zu lokalisieren,
also z.B. Schlüsselwörter ins Deutsche zu übertragen. Dies wurde von
Programmieren aus obigem Grund abgelehnt.
Achim S. schrieb:> In den 70ern wurde wohl mal überlegt, Compiler quasi zu lokalisieren,> also z.B. Schlüsselwörter ins Deutsche zu übertragen. Dies wurde von> Programmieren aus obigem Grund abgelehnt.
Länderspezifische Funktionsnamen in Microsoft Excel.
Sehr übel, das...
Johann L. schrieb:> Und was du das als "voschriftsmäßig" abgeliefert hast lässt fief> blicken. Sehr tief.
Vielleicht solltest Du mal Deinen Ironie-Detektor neu kalibrieren. ;-)
Das Eröffnungsposting ist ganz klar ironisch, wenn nicht sogar
sarkastisch gemeint. Das kann man an den wenigen Sätzen, die zwischen
den Codezeilen stehen, sofort erkennen.
Interessant ist jedoch, was es für Reaktionen auslöst...
Frank M. schrieb:> Das Eröffnungsposting ist ganz klar ironisch, wenn nicht sogar> sarkastisch gemeint.
Das halte ich jetzt für postfaktisch, wenigstens alternative Fakten,
wenn nicht gar Fake News.
Frank M. schrieb:> Johann L. schrieb:>> Und was du das als "voschriftsmäßig" abgeliefert hast lässt fief>> blicken. Sehr tief.>> Vielleicht solltest Du mal Deinen Ironie-Detektor neu kalibrieren. ;-)
Ja, möglicherweise. Aber ich würd drauf wetten, dass es auf diesem
Planeten mehr als eine Firma gibt, die entsprechende Gütekriterien
vorschreibt und "lebt". Bei denen man dann nur denkt: "ach du meine
Güte!".
> Das Eröffnungsposting ist ganz klar ironisch, wenn nicht sogar> sarkastisch gemeint. Das kann man an den wenigen Sätzen, die zwischen> den Codezeilen stehen, sofort erkennen.
Naja, ernst gemeint war's jedenfalls nicht, da es noch nicht einmal
übersetzen würde.
Am bemerkenswertesten finde ich übrigens "p-q-Formel", unabhängig vom
Posting:
Teilweise ist der Unterricht in Schulen derart degeneriert, dass Schüler
Formeln auswendig lernen wie Gedichte -- so auch die p-q-Formel. Wenn
die armen Schüler denn eine quadratische Gleichung der For x^2 + qx + p
lösen sollen, ist der Totalschaden vorprogrammiert. Und wenn sowas in
einer Arbeit auftauchen sollte, ist ein Lynchen durch die Elternschaft
vorprogrammiert.
Selbst so erlebt bei Nachhilfeschülern: Potenzgesetze konnten die im
Schlaf aufsagen; aber anwenden? Panne. Und wenn in einem rechtwinkligen
Dreieck die Seiten nicht a, b und c hießen, sondern x, y, und z dann war
Ende Gelände.
Mich ergreift bei sowas wirklich das Grausen, und Namen wie
"Mitternachtsformel" erübrigen jeglichen Kommentar...
> Interessant ist jedoch, was es für Reaktionen auslöst...
:-)
> if(Wurzelterm < ImaginärDiskriminatorSchwelle )
if namenslänge >
temporäre_erfassbarkeitsmenge(Hauptspeicher)_of_gewöhnlicher-Mitleser
then take (p,q)
SQNR
Achim S. schrieb:> In den 70ern wurde wohl mal überlegt, Compiler quasi zu lokalisieren,> also z.B. Schlüsselwörter ins Deutsche zu übertragen. Dies wurde von> Programmieren aus obigem Grund abgelehnt.
Sei froh.
Achim S. schrieb:> In den 70ern wurde wohl mal überlegt, Compiler quasi zu lokalisieren,> also z.B. Schlüsselwörter ins Deutsche zu übertragen.
Siemens hatte in den 80/90ern ihr SINIX (mehr schlechter als rechter
Unix-Ableger) eingedeutscht - zumindest die Meldungen der Unix-Befehle.
An einen Befehl haben sie sich aber nicht rangetraut, nämlich strip, mit
dem man die Symboltabellen vom Executable abtrennen konnte.
So blieb es bei wiederholter Anwendung auf dasselbe Executable bei der
englischen Meldung:
strip: already stripped.
Frank M. schrieb:> Siemens hatte in den 80/90ern ihr SINIX (mehr schlechter als rechter> Unix-Ableger) eingedeutscht - zumindest die Meldungen der Unix-Befehle.
Wichtig sind anständige Fehlermeldungen für den Bediener: Auf einer
K1630-Anlage lief ein Unix-artiges Betriebssystem (m.E.n. aus Rumänien)
Fehlermeldungen wurden aber in deutscher Sprache ausgegeben z.B:
"Wenn Du noch einmal diese Taste drückst, sage ich es Deiner Mutter!"
oder "Stammt das aus den "Dornenvögeln?"
Das fand ich in Ordnung.
:)
Mfg Paul
Nach dem Aufsetzen eines Antergos (vorkonfiguriertes Arch) war ich sehr
überrascht als der gcc mir mit deutschen Fehlermeldungen helfen wollte.
Wenn man jahrelang mit dem "normalen" gcc vertraut ist können einen
deutsche Fehlermeldungen, selbst bei einfachen Problemen, ziemlich aus
dem Konzept bringen :-)
Hi
Thomas E. schrieb:> wenn(a)> {> //> }> sonst> {> //> }
Zumindest bei LibreOffice werden die Befehle nach der installierten
Sprache 'eingedeutscht'.
Eine englische Lösung zu Deinem Problem mit deutschem OS ...
Fehlanzeige.
Ich hätte es ja verstanden, wenn die deutschen 'Befehle' zusätzlich,
also aus Feature, angeboten würden - aber ne, die Englischen, Die man an
jeder WWW-Ecke erklärt bekommt, sind dort einfach weg - auch nicht in
der Hilfe enthalten, daß man so vll. auf die Lösung können könnte.
Meine Kommentare sind meist Deutsch - will den Code ja auch noch lesen
und verstehen können ;)
MfG
Le X. schrieb:> Nach dem Aufsetzen eines Antergos (vorkonfiguriertes Arch) war ich sehr> überrascht als der gcc mir mit deutschen Fehlermeldungen helfen wollte.
Ich glaube, das hat der gcc inzwischen wieder aufgegeben. Viele andere
Projekte machen das aber trotzdem. :-)
Patrick J. schrieb:> Zumindest bei LibreOffice werden die Befehle nach der installierten> Sprache 'eingedeutscht'.
Das hängt damit zusammen, dass Microsoft Office (Excel) das auch tut und
man ja kompatibel sein muss. Wäre ja schlimm, wenn ein deutscher
Programmierer seine Excel-Skillz nicht benutzen könnte.
Patrick J. schrieb:> Meine Kommentare sind meist Deutsch - will den Code ja auch noch lesen> und verstehen können ;)
Das ist übrigens bei LibreOffice tatsächlich ein Problem. Viele
Kommentare im Code sind dort nämlich deutsch - das ist das Erbe von
StarDivision (StarOffice).
S. R. schrieb:> Le X. schrieb:>> Nach dem Aufsetzen eines Antergos (vorkonfiguriertes Arch) war ich sehr>> überrascht als der gcc mir mit deutschen Fehlermeldungen helfen wollte.>> Ich glaube, das hat der gcc inzwischen wieder aufgegeben. Viele andere> Projekte machen das aber trotzdem. :-)
Nein, aufgegeben ist es nicht, und es aufzugeben ist auch nicht geplant.
Stattdessen wird es sogar weiter ausgebaut.
Ob NLS-Support (Native Language Support) ein hilfreiches Feature ist,
mag jeder für sich selbst beurteilen. Wenn man im Netz Hilfe bei
Bedeutung einer Diagnostic (Warnung, Fehler, Internal Error, ...) sucht,
dann es Englisch i.d.R. wesentlich hilfreicher als andere Sprachen.
Von daher finde ich es sinnvoll, GCC mit -disable-nls zu configuren, so
dass Diagnostics immer auf Englisch sind. Ansonsten kann man das
Verhalten durch Umgebungsvariablen wie LANG oder LANGUAGE beeinflussen,
aber die will man meist nicht verändern, da auch andere Programme dies
benutzen, z.B. zur Anzeige des Datumsformats.
NLS im GCC wurde z.B. auf Plural Forms erweiter, weil es nicht wie in
Deutsch in allen Sprachen nur 2 Plural-Formen gibt, sondern abhängig von
der Anzahl z.B. unterschiedliche Plurale für 2 oder für 3 Entitäten.
http://docs.translatehouse.org/projects/localization-guide/en/latest/l10n/pluralforms.html
Johann L. schrieb:> Ansonsten kann man das Verhalten durch Umgebungsvariablen wie LANG oder> LANGUAGE beeinflussen, aber die will man meist nicht verändern, da auch> andere Programme dies benutzen, z.B. zur Anzeige des Datumsformats.
Deswegen verwende ich
LANG=de_DE.UTF-8
LC_MESSAGES=POSIX
LC_NUMERIC=POSIX
LC_COLLATE=POSIX
Damit ist alles deutsch bis auf die Meldungen, die Zahlendarstellung und
die lexikalische Sortierreihenfolge.
Thread beobachten
Seitenaufteilung abschalten