Camel Caps (Coding Standards)

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Camel Caps (Coding Standards)

    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.
    Zuletzt geändert von Griecherus; 06.05.2007, 21:49.
    Nieder mit der Camel Case-Konvention

  • #2
    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
    TBT

    Die zwei wichtigsten Regeln für eine berufliche Karriere:
    1. Verrate niemals alles was du weißt!


    PHP 2 AllPatrizier II Browsergame

    Kommentar


    • #3
      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.
      hopka.net!

      Kommentar


      • #4
        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 ^^
        Bitte Beachten.
        Foren-Regeln
        Danke

        Kommentar


        • #5
          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:
          PHP-Code:
          $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
          Code:
          (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
          (((call/cc call/cc) (lambda (x) x)) "Scheme just rocks! and Ruby is magic!")

          Kommentar


          • #6
            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
            Webdesign und Webentwicklung - Plunix.de

            Kommentar


            • #7
              Original geschrieben von Lennie
              $sosäheeinevarausbeimir
              OffTopic:
              aber dann ohne das ä
              Bitte Beachten.
              Foren-Regeln
              Danke

              Kommentar


              • #8
                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
                Für alle die Fehler suchen, gibts gratis tolle Debuggingmöglichkeiten:
                var_dump(), print_r(), debug_backtrace und echo.
                Außerdem gibt es für unsere Neueinsteiger ein hervorragendes PHP Tutorial zu PHP 4 und PHP 5 (OOP)
                Es heißt $array['index'] und nicht $array[index]! Und nein, das ist nicht egal!
                Dieses Thema lesen, um Ärger im Forum und verzögerte Hilfen zu vermeiden.

                Kommentar


                • #9
                  wobei ein
                  PHP-Code:
                  $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
                  Nukular, das Wort ist N-u-k-u-l-a-r (Homer Simpson)
                  Meine Seite

                  Kommentar


                  • #10
                    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.
                    Webdesign und Webentwicklung - Plunix.de

                    Kommentar


                    • #11
                      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.
                      Nieder mit der Camel Case-Konvention

                      Kommentar


                      • #12
                        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
                        Für alle die Fehler suchen, gibts gratis tolle Debuggingmöglichkeiten:
                        var_dump(), print_r(), debug_backtrace und echo.
                        Außerdem gibt es für unsere Neueinsteiger ein hervorragendes PHP Tutorial zu PHP 4 und PHP 5 (OOP)
                        Es heißt $array['index'] und nicht $array[index]! Und nein, das ist nicht egal!
                        Dieses Thema lesen, um Ärger im Forum und verzögerte Hilfen zu vermeiden.

                        Kommentar


                        • #13
                          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
                          (((call/cc call/cc) (lambda (x) x)) "Scheme just rocks! and Ruby is magic!")

                          Kommentar


                          • #14
                            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

                            Kommentar


                            • #15
                              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.
                              Für alle die Fehler suchen, gibts gratis tolle Debuggingmöglichkeiten:
                              var_dump(), print_r(), debug_backtrace und echo.
                              Außerdem gibt es für unsere Neueinsteiger ein hervorragendes PHP Tutorial zu PHP 4 und PHP 5 (OOP)
                              Es heißt $array['index'] und nicht $array[index]! Und nein, das ist nicht egal!
                              Dieses Thema lesen, um Ärger im Forum und verzögerte Hilfen zu vermeiden.

                              Kommentar

                              Lädt...
                              X