4 ms·
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
by 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 agoIt'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.