<i>&quot;Well camel-case does reduce the length of the identifier without sacrificing clarity&quot;</i><p>I think camelCase easily beats underscores, but I also think it can reduce clarity a bit as soon as one uses abbreviations or mnemonics that commonly are written in all caps in identifiers.<p>Do you name your class IoChannel or IOChannel? For some, the former is a channel on a moon of Jupiter.<p>Do you name your variable classId or classID? For some, the former is related to Freud, so one could expect to see classEgo and classSuperego, too.<p>Made up examples? Yes, but I don&#x27;t think you can fully ignore aesthetics; I find that camelCasing such terms as ID, IO, XML and HTML in identifiers sacrifices clarity. &#x27;Id&#x27; in particular makes me cringe whenever I see it (yes, that makes me a bit of a snob, but I simply cannot get used to it). That certainly applies to cases where a common abbreviation also is a word or easily read as such.<p>On the other hand, I also think keeping such abbreviations all uppercase in CamelCase identifiers sometimes &quot;doesn&#x27;t look right&quot;, and &quot;doesn&#x27;t look right&quot; aka &quot;aesthetically ugly&quot; distracts me from understanding code.<p>Also, the argument that &quot;showing more&quot; implies &quot;more practical&quot; isn&#x27;t that strong. If it did, we could take an idea from colorForth and remove spaces, replacing them by color or font changes. We also could use multiple statements on a line.<p>I think I would prefer a language that allowed hyphens and punctuation in identifiers (the latter are really useful for such conventions as using a trailing &#x27;?&#x27; to indicate a method that tests a Boolean condition, a trailing &#x27;!&#x27; to indicate methods that mutate their arguments. I also like the Dylan convention of using asterisks to indicate class names.<p>That is &#x27;think&#x27;, though, because I don&#x27;t use one for practical reasons such as the availability of libraries.