>>21
Why? I'm not saying I shouldn't, just asking why. I never thought objects being created at run-time are so different from objects created at write-time.
I guess I don't really have a good answer to that. Personal preference I guess.
Regarding Hungarian notation, it detracts from the readability and maintainability of the code far more than it adds to it; it's usually obvious from the context what type something is, and Hungarian notation breaks down with polymorphism in OO languages anyway. That's why I don't use it.
>> The reason for this ambiguity is just because you use lower_case. lower_case and camelCase are mutually exclusive because of the ambiguity with single words.
I use lower_case, CamelCase and UPPER_CASE, which are perfectly compatible (since I don't declare UPPER_CASE constants only one character long).
Oops, that should read lower_case and shitCase are mutually exclusive. Obviously lower_case and CamelCase are not mutually exclusive.
I like shitCase and CamelCase because they look very similar, but the capitalization of the first letter is very obvious. Suppose I have a multi-word class, like MultiWordObject. I might declare a pointer it like so:
MultiWordObject* multiWordObject;
To me that looks a lot more consistent than:
MultiWordObject* multi_word_object;
In your coding style, where you don't make a clear distinction between variables and classes, you can't even use the same name for the class and the instance of it.