camelCase oder under_line

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • camelCase oder under_line

    Ich bin da über ein interessantes Thema gestoßen, über das ich mir nie wirklich gedanken gemacht habe. (Vor allem jetzt, wenn ich code schreibe der für möglichst viele Programmierer lesbar und erweiterbar sein soll.)
    Dabei geht es um die Art, wie man variablen bzw. funktionen schreibt. > im "camelcase" pder "underline" -Stil.

    Beispiele von Camelcase und Underline:

    Quellcode

    1. //Javascript/GML Code
    2. //camelCase
    3. function dasIstEineFunktion(){
    4. var ichBinEineVariable = 2;
    5. rufeNeueFunktionAuf();
    6. }
    7. //underline
    8. function das_ist_eine_funktion(){
    9. var ich_bin_eine_variable = 2;
    10. rufe_neue_funktion_auf();
    11. }
    Alles anzeigen


    Bei underline schreibt man zwischen einzelnen Wörter einen Unterschtrich, während bei Camelcase die Wärter durch einen großbuchstaben getrennt werden.
    Ich bin an die underline Schreibweise gewöhnt, da ich bei längeren Funktions- oder variablennamen sehr schnell den überblick verliere. vor allem bei größeren Projekten...)
    Habe jedoch nach etwas Recherche feststellen müssen, dass viele Programmierer an "camelcase" gewöhnt sind. (und die underline Methode gar nicht mögen bzw. gar verachten.)
    Viele meinen auch man sollte sich an die Namenskonvetionen der jeweiligen Sprache halten (um alles möglichst einheitlich zu haben.)
    Das ist verständlich. Dennoch besteht der Fakt dass ich bei dieser camelcase Methode leseprobleme habe. (ich brauche vergleichsweise lange um den Funktionsnamen aus camelcase rauszubekommen. VorAllemWennDieNamenSoLangSeinKönnen.) Bei mir wird einfach der Lesefluss unterbrochen, da ich genauer hinschauen muss um den Namen korrekt lesen zu können.
    Bei underline geht dies wesentlich schneller. Vor allem wenn ich mich in fremden Code einlesen muss. (Voraussgesetzt dass dieser im underline-Stil geschrieben wurde.)

    Vor allem frage ich mich, was ich machen sollte falls ich anfange eine Library zu schreiben die von anderen verwendet werden soll. Bei eine größeren Anzahl an Funktionsnamen die sich ähnlich sehen können, erscheint mir die underline-Methode wesentlich angenehmer.

    Meine Frage an euch:
    Nach welchem Stil benennt ihr eure Variablen oder Funktionen? (sei es im GM oder in anderen Sprachen wie C#,Java oder C++.)

    Weitere Beispiele von Camelcase:

    Quellcode

    1. glEnableCulling();
    2. glSetShader();
    3. transformAddTranslation();
    4. setCameraLookat();


    Beispiele von underline:

    Quellcode

    1. gl_enable_culling();
    2. gl_set_shader();
    3. transform_add_translation();
    4. set_camera_lookat();

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von LEWA ()

  • Ich benutze schon immer underline und hatte auch nich vor es zu ändern.
    Find ich auch praktischer und außerdem hat der Game Maker von Haus aus auch primär underline-Funktionen.
    Fügt sich also gut ein.

    Auch wenn ich Camelcase persönlich eigentlich ganz schön anzusehen finde :D Mehr aber auch nicht.
    Sorm ist Schuld

    Edit: Doch ist er
  • Eine interessante Sache das Ganze, hab da noch nie wirklich drüber nachgedacht mich da anzupassen, da ich auch nicht denke das je jemand meine Code in die Finger bekommt oder gar verwenden möchte.

    Ich persönlich mische das ganze ja:

    var_ClientLogin
    list_SpielerAll
    map_SpielerPort
    spr_LoginMenue
    usw.

    Finde es so sehr Praktisch, da ich auf den ersten Blick sehe um was für eine art Variable es sich handelt, und sehr leicht erkennen kann für was sie da ist.

    Aber wie schon gesagt, ich schreibe den Code auch für mich und nicht für andere ;)

    Man könnte diesen Stil CamelLine nennen xD
  • Ich persönlich verwende CamelCase, einfach da Java standartmäßig CamelCase nutzt und ich mit Java das Programmieren begonnen habe. Ist aber nur gewöhnungs sache.

    Wichtig ist vorallem nur einen Stil pro Projekt zu verwenden.
    Für Java Libraries würde ich allerdings CamelCase empfehlen, da auch alle Standart Libraries sowie diie meisten 3rd-Party Liibraries in Java diesen verweden.

    PS: Bei Funktionen mit Namen in der Länge von "VorAllemWennDieNamenSoLangSeinKönnen" würde ich mich persöhnlich fragen, ob der Name wirklich so lang sein muss.
  • andre111 schrieb:

    PS: Bei Funktionen mit Namen in der Länge von "VorAllemWennDieNamenSoLangSeinKönnen" würde ich mich persöhnlich fragen, ob der Name wirklich so lang sein muss.


    Nehmen wir mal ein du hast eine Klasse (in Java) welche verschiedenste openGL funktionen verwendet, welche den ganzen verwendungsprozess streamlinen.
    Da können schonmal Funktionsnamen auftauchen wie:

    Quellcode

    1. glEnableBackfaceCulling();
    2. glResetBackgroundColor();
    3. glSetCameraLookat();
    4. glLoadAsyncTexture();
    5. glTransformAddTranslation();


    Vor allem wenn du viele Funktionen/Variablen hast die sehr stark konzentriert in einem Codeabschnitt auftauchen ist es Schluss mit lustig. (Für mich zumindest.)
    Bis ich mich da in einen Code wirklich eingelesen habe vergeht wesentlich mehr Zeit als mit dem underline stil.
    Betrachte mal die ganzen funktionen mit underline:

    Quellcode

    1. gl_enable_backface_culling();
    2. gl_reset_background_color();
    3. gl_set_camera_lookat();
    4. gl_load_async_texture();
    5. gl_transform_add_translation();


    Für mich wesentlich übersichtlicher da ich auf anhieb erkennen kann welche Funktion was macht.
    Vor alle mwenn man dann ähnlich klingende Funktionsnamen hat.
    Beispiel:

    Quellcode

    1. gl_load_async_texture();
    2. gl_load_async_model();
    3. gl_load_async_sequence();


    Wäre für mich im Camelcase stil nur schwer unterscheidbar: /auf den ersten blick)

    Quellcode

    1. glLoadAsyncTexture();
    2. glLoadAsyncModel();
    3. glLoadAsyncSequence();


    Ist aber interessant dass hier auch viele Camelcase bevorzugen.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von LEWA ()

  • Quellcode

    1. gl_enable_backface_culling();
    2. gl_reset_background_color();
    3. gl_set_camera_lookat();
    4. gl_load_async_texture();
    5. gl_transform_add_translation();

    Ich finde die Lesbarkeit leidet hier auch darunter, dass die Begriffe irgendwie wirr geordnet sind. Meiner Meinung nach müsste es z.B. eher heißen

    Quellcode

    1. gl_camera_lookat_set();
  • Für mich w#re es wiederum

    Quellcode

    1. set_gl_camera_lookat

    ^^

    Also ich bevorzuge eigentlich underlines. Wenn ich c++ schreibe, schreibe ich allerdings iwie automatisch Funktionen und Klassen in camelCase. Lesbarkeitsprobleme habe ich bei keiner der Varianten. Mit underlines kann so ein Name zwar sehr lang werden, aber bla, Konventionen etc.
    Ich passe mich demnach eher der IDE an.

    Es gibt aber anscheinend sogar wissenschaftliche Abhandlungen darüber:

    Experiment setup

    Empirical study of 135 programmers and non-programmers. Subjects have to correctly identify a matching phrase (maximum of 3 words long) out of 4 similar phrases. The important variables researched:

    Correctness: whether the subject identified the correct phrase.
    Find time: time taken to identify the phrase.
    Training: how being a programmer affects the performance.

    Results

    Camel casing has a larger probability of correctness than underscores. (odds are 51.5% higher)
    On average, camel case took 0.42 seconds longer, which is 13.5% longer.
    Training has no statistically significant impact on how style influences correctness.
    Those with more training were quicker on identifiers in the camel case style.
    Training in one style, negatively impacts the find time for other styles.

    The paper concludes:

    Considering all four hypotheses together, it becomes evident that the camel case style leads to better all around performance once a subject is trained on this style. Training is required to quickly recognize such an identifier.

    der ganze Artikel

    ancient-pixel.com
    youtube.com/user/SebastianMerkl <<< ich freu mich über einen Besuch ;)
  • Aku_Ryou schrieb:

    Für mich w#re es wiederum

    Quellcode

    1. set_gl_camera_lookat

    ^^

    Also ich bevorzuge eigentlich underlines. Wenn ich c++ schreibe, schreibe ich allerdings iwie automatisch Funktionen und Klassen in camelCase. Lesbarkeitsprobleme habe ich bei keiner der Varianten. Mit underlines kann so ein Name zwar sehr lang werden, aber bla, Konventionen etc.
    Ich passe mich demnach eher der IDE an.

    Es gibt aber anscheinend sogar wissenschaftliche Abhandlungen darüber:

    Experiment setup

    Empirical study of 135 programmers and non-programmers. Subjects have to correctly identify a matching phrase (maximum of 3 words long) out of 4 similar phrases. The important variables researched:

    Correctness: whether the subject identified the correct phrase.
    Find time: time taken to identify the phrase.
    Training: how being a programmer affects the performance.

    Results

    Camel casing has a larger probability of correctness than underscores. (odds are 51.5% higher)
    On average, camel case took 0.42 seconds longer, which is 13.5% longer.
    Training has no statistically significant impact on how style influences correctness.
    Those with more training were quicker on identifiers in the camel case style.
    Training in one style, negatively impacts the find time for other styles.

    The paper concludes:

    Considering all four hypotheses together, it becomes evident that the camel case style leads to better all around performance once a subject is trained on this style. Training is required to quickly recognize such an identifier.

    der ganze Artikel

    Da stimme ich dir zu.. ein setter hat ein "set" als erstes Wort :thumbsup:

    Prinzipiell verwende ich den CamelCase-Style. Warum? Keine Ahnung. Für mich ist das schöner zu lesen, und in Programmiersprachen wie Java ist es einfach üblich.
    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Ergo: Je mehr Käse, desto weniger Käse.