CamelCase? snake_case? Something else? And why?

  • dengismceo
    link
    fedilink
    arrow-up
    10
    ·
    4 years ago

    :snake: SNAKE_CASE_GANG :snake:

    it has the best readability. and i spend most of my time in c or python. and i hate hitting shift ;)

  • DessalinesA
    link
    fedilink
    arrow-up
    9
    ·
    4 years ago

    Doesn’t matter to me, but I like that rust has built in enforcement of consistent naming conventions for functions, traits, etc.

  • nromdotcom
    link
    fedilink
    arrow-up
    8
    ·
    4 years ago

    I like whatever the accepted standard is for the language I’m using at the time.

    So for python and ruby we’re talking snake_case variables and PascalCase classes, for javascript camelCase variables and PascalCase constructors, for go camelCase for unexported and PascalCase for exported.

    Don’t really see how one might have a personal favorite that they apply to all languages equally.

    • Adda
      link
      fedilink
      arrow-up
      1
      ·
      4 years ago

      Exactly this. I have lacked this comment here and was surprised no one has mentioned it earlier. One might prefer one format over the other, whenever there is a standard though, one should immediately switch to it and stick with the standard for the given language. Not what the discussion asked for though, so that might be the reason.

  • t_var_s
    link
    fedilink
    arrow-up
    6
    ·
    4 years ago

    snake_case for variable names because they seem to be holding something in their underscores. camelCase for functions because verbNoun looks good. PascalCase for classes because it looks like it’s a level above that needs to be instantiated before getting used.

  • Serge Tarkovski
    link
    fedilink
    arrow-up
    5
    ·
    4 years ago

    My primary programming language has been Python since 2008, so the answer is obvious. Though I like consistency even more, so CamelCase is also ok when used everywhere.

  • ☆ Yσɠƚԋσʂ ☆
    link
    fedilink
    arrow-up
    6
    arrow-down
    2
    ·
    4 years ago

    Kebab case hands down, it’s as readable as snake case, but easier to type. Unfortunately, it’s rarely seen outside Lisps.

    • Ravn
      link
      fedilink
      arrow-up
      5
      ·
      4 years ago

      Also looks neater and more streamlined. I find snake case gives the feeling of everything being a bit imbalanced with all those underscores weighing everything down.

    • ksynwa
      link
      fedilink
      arrow-up
      2
      ·
      4 years ago

      Yeah you’re right it is much easier to type. Wish more languages had this.

  • Talkless
    link
    fedilink
    arrow-up
    2
    ·
    4 years ago

    I use CamelCase::likeQtDoes(), probably just because Qt does so, as 99% work done by using Qt library.

  • Vorthas
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    PascalCase or camelCase (note the capitalization of the first letter, that’s the difference between the two) basically always.

  • Smiling_Tut@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Once I was checking somebody’s code against a coding style and asked him why he capitalised a certain identifier that wasn’t a type. His reply was along these lines: This word is a German noun. In the German language all nouns are capitalised. It is better to have the identifier look like the real word, because it uses less cognitive resources. Your IDE can tell you about the nature of the identifier. Your name should only reflect how it is used.

    I kinda liked the idea (and maybe forced him to conform to the rule, I don’t remember). In the end I’ve come to appreciate, when you can use identifiers that really look like normal text.

    eat_French_cheese(new Le_Curé_Nantais()); {Not a memory leak - the cheese is properly consumed/destroyed by fnc}

    And I hate if the compiler allows to have different identifiers that only differ in case. E.g. “RailsExpr” and “railSexPR” shouldn’t be allowed coexist in the same code. (Neither should indentation with tabs and indentation with space coexist in the same file).