3 ms·

The only useful naming convention was described by Bjarne Stroustrup in his C++ book: "capitalize type names, don't capitalize anything else". If you want to p

The only useful naming convention was described by Bjarne Stroustrup in his C++ book: "capitalize type names, don't capitalize anything else". If you want to prefix your private members with "_", you are using the wrong IDE (or the wrong language, like here: http://news.ycombinator.com/item?id=826119 http://news.ycombinator.com/item?id=826119). If you want to prefix sanitized variable names with "s", you should find a better way of sanitizing them and read less of Joel. If you want to name hard-working method like "DistinctRequests", remember that you are "hiding behind your names" and contradicting yourself at once.

clawrencewenham 17y ago
Everybody Always Has The Wrong Language (tm)
ajross 17y ago
Your second point makes sense only if everyone who reads your code only does so in your preferred IDE. That kind of tool dependence is unhealthy. For myself, I rather like things like the prepended underscore (or m_*, the microsoft convention for object members) because it makes up for a shortcoming of C++ and its derivatives: there are multiple non-local scopes for symbols, and it's not always obvious which one you mean. Is that unbound variable a class member? static class member? top-level member of a namespace? global? Having prefixes that make this obvious can be really helpful. Now, that's secondary to the point of whether this scoping rule is a good idea. I'm generally of the opinion that it's not, and that languages (e.g. python) which force object scoping to be explicit are more readable. But that's just because "self.field" is 1:1 with the "_field" convention from C++.
silentbicycle 17y ago
Sometimes issues like this are less about the language than the code conventions for a company/project, though. If (for example) prefacing variables with a _ is a short convention for saying, "While the language we're using doesn't enforce private variables, we only expect this to be used internally, and will feel free to make major changes to it. Consider yourself warned.", that's still highly useful. Of course, if you have such conventions, be consistent.
euroclydon 17y ago
I like using _name for private variables, because when I have a constructor that accepts that value, I can do this: MyClass(string name) { _name = name; }
Periodic 17y ago
I believe a lot of this is just an attempt to make up for what the language lacks, in this case it lacks stronger scoping and typing systems. It would be a bit of a pain to create a SanitizedString type for a sanitized string that is only used in two functions, but this is a good compromise between speed and efficiency. It may not always be the right trade off, but that's how trade offs work. Granted, the SanitizedString type is checked by the compiler, while the s* variable name is checked by the programmer, each having its own problems.

clawrencewenham 17y ago

Everybody Always Has The Wrong Language (tm)

ajross 17y ago

Your second point makes sense only if everyone who reads your code only does so in your preferred IDE. That kind of tool dependence is unhealthy. For myself, I rather like things like the prepended underscore (or m_*, the microsoft convention for object members) because it makes up for a shortcoming of C++ and its derivatives: there are multiple non-local scopes for symbols, and it's not always obvious which one you mean. Is that unbound variable a class member? static class member? top-level member of a namespace? global? Having prefixes that make this obvious can be really helpful. Now, that's secondary to the point of whether this scoping rule is a good idea. I'm generally of the opinion that it's not, and that languages (e.g. python) which force object scoping to be explicit are more readable. But that's just because "self.field" is 1:1 with the "_field" convention from C++.

silentbicycle 17y ago

Sometimes issues like this are less about the language than the code conventions for a company/project, though. If (for example) prefacing variables with a _ is a short convention for saying, "While the language we're using doesn't enforce private variables, we only expect this to be used internally, and will feel free to make major changes to it. Consider yourself warned.", that's still highly useful. Of course, if you have such conventions, be consistent.

euroclydon 17y ago

I like using _name for private variables, because when I have a constructor that accepts that value, I can do this: MyClass(string name) { _name = name; }

Periodic 17y ago

I believe a lot of this is just an attempt to make up for what the language lacks, in this case it lacks stronger scoping and typing systems. It would be a bit of a pain to create a SanitizedString type for a sanitized string that is only used in two functions, but this is a good compromise between speed and efficiency. It may not always be the right trade off, but that's how trade offs work. Granted, the SanitizedString type is checked by the compiler, while the s* variable name is checked by the programmer, each having its own problems.