http://en.wikipedia.org/wiki/CamelCase: --- begin quote --- CamelCase (or camel case) ... is the practice of writing compound words or phrases in which the elements are joined without spaces, with each element's initial letter capitalized within the compound and the first letter either upper or lower case—as in "LaBelle", "BackColor", or "iPod". --- end quote --- The following is my opinion about CamelCase in general, excluding its usage for Oracle object names which would become all-capital in data dictionary (unless enclosed in double quotation marks). I wonder if it's true that people that regularly read Chinese or German (or ancient Latin) find CamelCase less offending. In these languages, meaningful tokens (words in most languages, characters in Chinese) are often concatenated with no separators. Due to this constant subconscious training, CamelCase should not be a big issue, because the training is the more rigorous reading of "nocasewords". But I acknowledge that long CamelCase words are slower to read. That leads to another point. A procedure name in programming code only (not a name for an Oracle database object, which is flattened to all capital unless in double quotes) is usually short. In illustrating the point that a CamelCase name is hard to read, people use very long names as examples in a sentence-context. For one, the extra brain power to read a short CamelCase name is minimal, and the brevity probably has the beneficial effect of focusing your eyesight into a dot or at least a solid token better than if the string contains underscores; in fact, the white space above "_" disrupts the image as a solid token. I believe the brain works better if the string only needs to be understood as a single solid token, and the shorter the string and the less white space, the more it becomes solid and closer to a dot. Secondly, examples citing a long CamelCase string are sentences. The brain works differently when you're in linear sentence-reading mode. But in programming code reading mode, you don't literally read linearly, but back and forth, up and down, repeatedly. A token, as short as possible, as close to a dot or solid spot as possible (but not too short so as to compromise its meaning), is desired in this context. Because of repeated non-linear reading, GetAreaSize() may take even less time for the brain to process than get_area_size() every time your eyes are on it. Nevertheless, the differences stated above are small. So other rules become more important, e.g. consistent naming convention, etc. Ref: http://www.freelists.org/post/oracle-l/CamelCase-For-Procedures-Names,19