4 ms·

These days all variables created by me, in any language, are in descriptive_snake_case. I just can't see any reason to use anything else.

by saturn 15y ago

mckoss 15y ago
Each language has its own conventions. I try to use the dominant convention for each so as to be more readable to the community of developers in that language. So, snake_case in Python and camelCase in JavaScript (with classes being initial Capital in both).
- vorg 15y ago
  For identifier 'snake_case' use '蛇写' For identifier 'camelCase' use '驼写'
div 15y ago
Consistency and familiarity would both be good reasons to me. Non camelCase variables and CamelCase classes in Java for instance would really feel out of place to me, whereas using the same case conventions for some ruby code would feel equally 'wrong'. When it comes to conventions like this, I don't think there's a substitute for having a "when in Rome" attitude. If you're writing some greenfield code, Rome is all the other projects in your language of choice. If you're adding some functionality to an existing piece of code, that existing piece of code is Rome.
- saturn 15y ago
  > I don't think there's a substitute for having a "when in Rome" attitude Yeah, this is a good point. I come across as gung-ho in the parent but I have to admit I do submit to the "when in Rome" effect. That said, if Rome is an absolute shambles, I might feel empowered to start anew ..
  - div 15y ago
    It's always very painful if a codebase is not internally consistent. I usually try to find some sort of dominant naming scheme to follow and clean up old code left and right, but yeah, sometimes starting anew can be the only sane thing to do.
hessenwolf 15y ago
Ugh... I just think camel case is so much prettier, but marks for being consistent.
- kabdib 15y ago
  Consistency is definitely the high-order bit. But then again, I have no problem going into a badly formatted hunk of code and fixing it. I have, on occasion, reformatted entire source directories because the original sources were so terrible.
Jach 15y ago
Ditto, with the exceptions of class names, projects not my own where I have to follow certain conventions, and in a Lisp-like languages. Dash beats underscore and I love question marks at the end of functions that return bools. I've also sucked long on the teat of dynamic type languages, so I've found that I care more about being able to decipher code's intent from reading it than what specific types are. For me, Python code is still more readable than C++ code no matter how many stylistic conventions on your C++ variables you make up.

These days all variables created by me, in any language, are in descriptive_snake_case. I just can't see any reason to use anything else.

by saturn 15y ago

These days all variables created by me, in any language, are in descriptive_snake_case. I just can't see any reason to use anything else.

mckoss 15y ago

Each language has its own conventions. I try to use the dominant convention for each so as to be more readable to the community of developers in that language. So, snake_case in Python and camelCase in JavaScript (with classes being initial Capital in both).

vorg 15y ago
For identifier 'snake_case' use '蛇写' For identifier 'camelCase' use '驼写'

div 15y ago

Consistency and familiarity would both be good reasons to me. Non camelCase variables and CamelCase classes in Java for instance would really feel out of place to me, whereas using the same case conventions for some ruby code would feel equally 'wrong'. When it comes to conventions like this, I don't think there's a substitute for having a "when in Rome" attitude. If you're writing some greenfield code, Rome is all the other projects in your language of choice. If you're adding some functionality to an existing piece of code, that existing piece of code is Rome.

saturn 15y ago
> I don't think there's a substitute for having a "when in Rome" attitude Yeah, this is a good point. I come across as gung-ho in the parent but I have to admit I do submit to the "when in Rome" effect. That said, if Rome is an absolute shambles, I might feel empowered to start anew ..
- div 15y ago
  It's always very painful if a codebase is not internally consistent. I usually try to find some sort of dominant naming scheme to follow and clean up old code left and right, but yeah, sometimes starting anew can be the only sane thing to do.

hessenwolf 15y ago

Ugh... I just think camel case is so much prettier, but marks for being consistent.

kabdib 15y ago
Consistency is definitely the high-order bit. But then again, I have no problem going into a badly formatted hunk of code and fixing it. I have, on occasion, reformatted entire source directories because the original sources were so terrible.

Jach 15y ago

Ditto, with the exceptions of class names, projects not my own where I have to follow certain conventions, and in a Lisp-like languages. Dash beats underscore and I love question marks at the end of functions that return bools. I've also sucked long on the teat of dynamic type languages, so I've found that I care more about being able to decipher code's intent from reading it than what specific types are. For me, Python code is still more readable than C++ code no matter how many stylistic conventions on your C++ variables you make up.