Design <> Geschmack von Code
-
jo, reines englisch
auch die kommentare, wenn möglich, in englisch
aber bei kommentaren: lieber gutes deutsch als schlechtes englisch.
-
english, ganz klar.
-
english, ganz klar.
-
auch wenn du zur zeit der einzige bist der deinen code liest (lesen muss) solltest du dir einen stil angewöhnen und den auch durchziehen. irgendwann muss bestimmt jemand deinen code lesen, und vor allem verstehen, und ein klarer stil hilft da ganz gut. ansonsten kann ich meinen vorpostern nur zustimmen.
wenigstens bin ich nicht der einzige bei dem das forum grad zicken macht
-
Hallo,
kommt drauf an für welches Umfeld ich programmiere. Für die Uni ist meist alles deutsch. Private verwende ich den Namen, der das Konzept meiner Meinung nach am Besten ausdrückt. D.h. ich bevorzuge zwar Englisch, wenn mir aber kein passendes englisches Wort bekannt ist und ich ein gutes deutsches habe, nehme ich das.Im Team richte ich mich nach den Team-Richtlinien.
-
ich benutze englisch, da die meisten Programmierer zumindest ein bissel englisch verstehen und ich meine Codes als OpenSource veröffentliche.
-
Englisch only. Spätestens wenn man mal mit einem Spanier, Italiener oder sonstwem zusammenarbeiten muß, der kein Deutsch kann, hat sichs ausgezahlt.
Außerdem bin ich in Deutsch eh ne Pfeife :p
-
englisch seitdem ich ein jahr in london gelebt habe
und mir die einfachheit und direktheit der sprache sehr aufgefallen ist
-
Englisch mit deutschen Kommentaren
M.T.
-
Grundsätzlich ja Englisch, was für technische Anwendungen auch im Regelfall kein Problem ist.
Schwierig wird's im Bereich BWL-Anwendungen... wenn man nämlich z.B. den MWSt_Satz_pauschal_fuer_Verpflegungsmehraufwendungen englisch macht, wird's unverständlich. Dann doch lieber deutsch.
Und auch kein Denglish: findet man sehr oft, Variablen die sich "actualValue" nennen. Soll für "aktueller Wert" stehen. Müßte englisch doch aber "currentValue" heißen, weil "actual" "tatsächlich" heißt. Ähnliches gibt's zuhauf. Damit kann man es dann letztlich auch wieder schaffen, sogar englische Muttersprachler zu verwirren.
Ich erinnere da nur an das:
German guest to the waiter "May I become a Schnitzel please."
Waiter "I hope never, Sir."Insbesondere gilt sowas nämlich für englische Kommentare:
// here becomes dlg a new handle
soll bedeuten????
-
// here becomes dlg a new handle
soll bedeuten????
falsch wäre so was IMHO
dlg.new_handle(handle(xyz));da bin ich mir nicht sicher ob es falsch wär, weil dlg ja wirklich ein neues Handle wird
dlg=handle(xyz);
-
dlg=handle(xyz);
Das erfüllt sicher nicht den Kommentar. dlg "wird" hier schließlich kein neues Handle. Der Kommentar lässt sich eigentlich auch nicht erfüllen, da Objektidentität eindeutig und unveränderlich ist.
Man könnte vielleicht mit einem Destruktor-Aufruf + placement-new-Hack etwas machen. Einfacher wäre es allerdings den Kommentar zu berichtigen
-
Im häufigsten Fall meinte der Ersteller wohl einfach "bekommen" - hat's aber falsch geschrieben (get programmieren und become kommentieren).
Ihr müßt mal Codes nach solchen Sachen durchsuchen, ist ein sehr beliebter Fehler in Kommentaren. Aber stellt Euch nun mal den armen Engländer vor, der diesen Kommentar liest. Er weiß ja nix von "bekommen" und darf nun rätseln, was eigentlich gemeint war.
-
Hallo.
Bei mir wird immer alles Englisch bezeichnet. Warum, weiß ich nicht, da eh niemand jemals meine Codes lesen wird. Aber es trainiert und hilft mir irgendwann vielleicht mal in der Schule
Bye.
-
Kommentare sollte man eh spärlich einsetzen... (aber zugegeben, meine Einbuchstabenbezeichner muss ich mir abgewöhnen :>)
-
Mr. N schrieb:
Kommentare sollte man eh spärlich einsetzen...
???
-
Mr. N schrieb:
Kommentare sollte man eh spärlich einsetzen... (aber zugegeben, meine Einbuchstabenbezeichner muss ich mir abgewöhnen :>)
Find ich auch. Besser verständlichen Code schreiben, der keiner Erklärung bedarf, als unverständlichen, der dann noch ne Seite Kommentar benötigt ...
Ich verwende nie Kommentare, hat sich bisher noch niemand beschwert.
-
dEUs schrieb:
Besser verständlichen Code schreiben, der keiner Erklärung bedarf, als unverständlichen, der dann noch ne Seite Kommentar benötigt ...
Fullack. Von Code, der vielleicht pro Funktion noch ne kurze Beschreibung braucht hat man viel mehr Lesbarkeit als von schlechtem Code wo dafür jede Zeile nen Kommentar enthält. Ausgenommen vielleicht größere Datenstrukturen, da schadet sowas manchmal nicht.
-
Im Kleinklein gebe ich Euch ja recht, aber es tut manchmal schon gut zu wissen, warum jemand zum Beispiel eine bestimmte Reihenfolge gewählt hat. Wenn also irgendwo ein if (Kontostand < Disporahmen) im Quelltext steht weiß ich natürlich auch ohne Kommentar sofort was passiert. Es ist aber später durchaus gut auch mal zu erfahren, warum die Prüfung zum Beispiel an dieser Stelle (nämlich bei der Abhebung) passiert und nicht bei den täglich Mahnläufen. Nur als Beispiel. Weil diese Infos ergeben sich auch aus klar lesbarem Code eindeutig NICHT.
Ein Kommentar soll also nicht das "Was" des Codes erklären, soweit soll der Code selbsterklärend sein. Aber zum "Warum" (auch: warum hat man ein bestimmtes Teil als 3 Klassen realisiert, in einem anderen Fall aber nur in einer einzigen) sagt lesbarer Code noch nicht allzu viel aus. Oder "warum" verbietet Ihr in einer Klasse die Ableitung? Gibt's da einen Grund? Oder "warum" dürfen diese Objekte nicht kopiert werden. Das ist manchmal schon interessant zu erfahren, wenn man fremden Code verstehen will.
-
Das stimmt allerdings auch ...