Camel Caps (Coding Standards)

[Griecherus]

OffTopic:

---

@Mods: Ich habe hoffentlich nicht das falsche Forum erwischt... Das Thema hat zwar etwas mit Programmierung zu tun, passt nur nicht so richtig in eins der Nicht-OT-Foren. Falls doch: sorry.

---

Mir geht's bei diesem Thema um Coding Standards, genauer gesagt um eine scheinbar beliebte und (besonders in der OOP) weit verbreitete Namenskonvention: Camel Caps (Bsp.: public function kickMe($extraHard = FALSE) statt public function kick_me($extra_hard = FALSE)).
Meine Frage dazu ist eher trivial: Bin ich abnormal und der einzige, der diese Konvention hinsichtlich des Erscheinungsbilds und der Lesbarkeit zum findet? (Ja-Antworten zum ersten Teil der Frage werden überlesen. )
Aus irgendeinem Grund, der sich mir aber nicht erschließt, muss diese Methode ja so beliebt sein. Ich programmiere in der Regel mit Kleinbuchstaben und Unterstrichen - auch bei Klassen - (Konstanten und andere Ausnahmen ausgenommen) und finde, dass diese Art um Längen lesbarer und sauberer ist.
Wie sieht das bei euch in Sachen Coding Standards aus? Mir ist klar, dass die Frage eigentlich ziemlich belanglos ist. Mich interessiert's trotzdem, und vielleicht den einen oder anderen von euch auch.

[TBT]

siehe Wikipedia

Verwendung in Programmiersprachen
Für Quelltexte von Computerprogrammen gibt es verschiedene Konventionen für die Verwendung von Binnenversalien in Bezeichnern (zum Beispiel die Ungarische Notation, aber auch persönliche Konventionen), oder Binnenversalien werden einfach verwendet, um lange Namen übersichtlicher zu machen („checkInputBuffer“). Diese Schreibweise hat sich durchgesetzt, weil Bezeichner normalerweise keine Leerzeichen enthalten dürfen. Eine alternative Lösung dieses Problems ist die Verwendung des Unterstrichs anstelle von Leerzeichen. Welche Variante verwendet wird, hängt vom Programmierstil ab. In Java und Basic ist die Verwendung von Binnenmajuskeln bei der Benennung von Methoden und Variablen gebräuchlich. Die Variante mit dem Unterstrich findet man vermehrt in PHP (bis zu Version 4, danach blieb die Variante nur aus Gründen der Kompatibilität enthalten) und C.

und ja, ich schreibe auch mit Camel Caps

[Hopka]

Also ich kenne CamelCase hauptsächlich aus der Java-Welt. Und die Notation mit den Unterstrichen kenne ich eher von C. Ich finde Java schöner als C und es ist auf jeden Fall sehr viel objektorientierter, und daher verwende ich für PHP OOP Code auch CamelCase.

[Wyveres]

da ich ein kleines problem mit dem gross und kleinschreiben habe verwende ich dieses wirklich nur in den sprachen in den es nicht anders geht ... z.b. JS ...

aber ansonsten und vorallem in PHP liebe ich es alles klein schreiben zu können ^^ und das _ erst recht ^^

[closure]

Hi,

unter anderem wird camel-case benutzt um die methode zu beschreiben.
In aller regel kann man methoden mit verben vergleichen und
wenn sie auf objekten arbeiten dann sind dies auch objekte im
grammatikalischen sinn.

Wenn ich also in ein tassenobjekt mit tee fuellen möchte dann kann ich
schreiben:

$cup->insertTee(30); //30 ml oder was auch immer 

Jedenfalls wird das oft als erklärung angegeben.
Ich komme ursprünglich aus der c/c++-ecke wo eher wenig
camel-case geschrieben wird, deswegen bevorzuge ich
auch die unterstrich-methode.
Andere sprachen die einem nicht solche einschränkungen was die
benamung von identifiern angeht, auferlegen nutze ich gern die vollen möglichkeiten.
Zb. in scheme/lisp

(define (++ num) (+ num 1))
(++ 1) ; => 2

Wiederum andere sprachen wie z.B. ruby gehen so weit dass
anhand der groß/kleinschreibung entschieden wird ob es sich
um klassen, konstanten, variablen oder methoden handelt.
In ruby müssen Klassen mit einem großbuchstaben beginnen.
Konstanten müssen durchgehend groß geschrieben werden.

Das ist natürlich nicht so toll, soll aber einen einheitlichen codingstil
erzwingen.

greets

[Lennie]

ich arbeite ohne camel caps. Es reicht wenn man den sinn der Variable/function usw. erkennen kann am namen. und wieso ihn dan unnötig in die länge ziehen?

$sosäheeinevarausbeimir

[Wyveres]

Original geschrieben von Lennie
$sosäheeinevarausbeimir

OffTopic:

---

aber dann ohne das ä

---

[Shurakai]

Lennie, du hast den Sinn glaube ich nicht verstanden.

Vergleiche mal

$sosäheeinevarausbeimir

mit

$soSäheEineVarAusBeiMir


Na, wo checkst du schneller dass die Variable einen sinnvollen Satz hat?

Deine Begründung ist also nonsense, der Variablenname wird dadurch nicht länger. Denk erstmal nach

[Kropff]

wobei ein

$so_saehe_eine_var_aus_bei_mir 

sich sicher noch besser lesen läßt. ich setze camel caps bei klassen sowie funktionen (methoden) und unterstriche bei variablen

gruß
peter

[Lennie]

Original geschrieben von Shurakai
Deine Begründung ist also nonsense, der Variablenname wird dadurch nicht länger. Denk erstmal nach

Das mit der variable ist wie gesagt ein beispiel wie eine variable bei mir aussähe. sorry dass ich nciht mitgedacht habe. ich meinte mit den langen variablen namen die tatsache dass ich keine _ verwende. diese würden das schon in die länge ziehen.

[Griecherus]

Es ist interessant zu sehen, dass es doch noch andere Leute gibt, die nicht mit der Camel Caps Methode arbeiten, betrachtet man mal die Masse an nach dieser Konvention gestalteten PHP-Code.

@closure: Die grammatikalische Erklärung für die Camel Caps Schreibweise finde ich indes ziemlich interessant, aus der Sichtweise habe ich das Ganze noch nicht gesehen. Danke.

Wenn man mich fragt, dann ist beispielsweise $ichBinEinParameter um einiges unleserlicher als das Pendant $ich_bin_ein_parameter. Wobei $ichbineinparameter meiner Meinung nach gar nicht geht, da die Lesbarkeit hier ganz auf der Strecke bleibt. Gerade bei umfangreichen Code dürfte die Übersicht doch stark leiden. Hast du da andere Erfahrungen gemacht, Lennie? Bei langen Bezeichnernamen würde ich dann eher bekannte Abkürzungen benutzen (z.B. param statt parameter, arg statt argument, etc.), wobei diese auch mit Vorsicht zu genießen sind.

Das einzige Argument für Camel Caps, das mir noch eingefallen ist (das closure auch im Zusammenhang mit Ruby angesprochen hat), ist die Unterscheidung von Klassen-Programmierung und "dem Rest". Und da bin ich auch eher uneins, da man - egal nach welcher Schreibweise - am Kontext bzw. der Syntax erkennt, worum es sich handelt.

Danke für eure Antworten.

[Shurakai]

Eigentlich kann ich mich Peter nur anschließen. Wobei ich bei PHP auch ganz gerne sowas wie $bool_isTemp mache, also einen Mix von beidem. Man muss nur immer schauen, wie die Übersichtlichkeit ist - und ich finde, die ist bei beiden Möglichkeiten gut. Nur bei Lennie, das ist echt grottig. Er sollte sich das mal dringend(st) abgewöhnen

[closure]

Original geschrieben von Shurakai
Eigentlich kann ich mich Peter nur anschließen. Wobei ich bei PHP auch ganz gerne sowas wie $bool_isTemp mache ...

Kurz vorweg, das soll keine grundsatzdiskussion werden.
Hast du mal länger mit c/c++ im windowsumfeld zu tun gehabt?
Ich meine wegen der ungarischen notation?

Es gibt gute gründe sie nicht zu benutzen, insbesondere im
umfeld objektorientierter sprachen

greets

[asp2php]

und ich hasse lange Namen, vor allem wenn man keine IDE mit Intellisense hat. Warum muss man denn lange Namen einsetzen damals mit Assembler, da hat kenier sich über die abstrakten Speicheraddressen und Befehle beklagt, und es entstanden genauso viel nützliche Programme wie heute

[Shurakai]

Original geschrieben von closure
Es gibt gute gründe sie nicht zu benutzen, insbesondere im
umfeld objektorientierter sprachen

greets

Das ist richtig, allerdings geht mir diese Typenlosigkeit bei PHP derbe auf den Senkel und es hilft halt schon sehr, auch noch nach 3 oder 6 Monaten beim Debugging zu wissen, was eigentlich in der Variable drinne sein sollte. Wenn bool dran steht aber String drin ist, ist da was falsch und man weiß wo man ansetzen muss. Das hat mir bei PHP eine Menge Zeit gespart und deshalb wird es dort von mir auch stark praktiziert.

Bei zB Java setze ich es allerdings nicht ein, da von vorneherein klar ist was drin ist, was allerdings bei nicht streng-typisierten Sprachen - wie zB C oder PHP - nicht der Fall ist. Ich persl. setze diese Notation übrigens größtenteils nur in geringem Umfang (bool, string, int, obj, arr) bei PHP ein.

In PHP 5 verzichte ich bei den Klassenattributen häufig auch darauf, lediglich bei lokalen Variablen benutze ich es da noch.
Ansonsten steht bei mir immer in den Kommentaren über der Deklaration was für ein Datentyp drin ist.