11–20 of 64 posts
I'd dread to think of what naming conventions would look like if they were modeled after Japanese. You can write the same exact word as ひとごみ, 人ごみ, 人込み, 人混み, 人込, or even ヒトゴミ if you're feeling bold.
If I write a sentence in ALL CAPS, I’M YELLING AT YOU. if i write a sentence in lowercase i am maybe laid back or aloof.
A sentence written in all hiragana might represent a toddler speaking. A sentence written in all katakana might represent a foreigner speaking broken Japanese (ouch!).
Usually, hiragana is used for grammatical purposes, such as particles and conjugations. But for some reason, laws and contracts use katakana instead. In a hypothetical Japanese programming language, which one should they pick? In university I had to learn this strange language called Doolittle[1] which uses Japanese but dodges the grammar particle issue by using spaces and symbols, which I found to be terribly confusing. I would love to see an attempt at a Japanese programming language that is closer to how the spoken language works.
This only scratches the surface. There are even more ways to represent arbitrary syllables, such as with arbitrary kanji (ateji) or even more complex systems like Kanbun. And of course there are many levels of simplification and variation within Chinese characters.
My point is that I don’t think this is inherently a Western thing, even if it ended up that way. It’s interesting to ponder how a non-Western language’s programming conventions could look like. Sometimes it’s even a real issue: see languages like Go where uppercase is semantically meaningful and therefore it is impossible to export Eastern symbols.
[1]: https://en.wikipedia.org/wiki/Dolittle_(programming_language...
You could avoid stuff like get/set, but that's pretty low-hanging fruit compared to the explosion of things when you have 3 components referencing from top to bottom, each with a 8+ character variable. Preserving context is expensive in writing and reading. Assuming the reader has a shared context is required to shorten many things, however. This can backfire and make things worse than writing things fully.
Example, you could shorten mMaxTextureSize to maxSize or maxTexture or something. It entirely depends on what the reader knows coming in and what other variables exist or may exist in the future. In the other example, "getCurrentContext()->getLimits()" could be shortened to "Context()->Limits()" assuming there is only context property available is the current one. In both examples, I have to make assumptions on what the reader knows and both the existing and future code which, as mentioned before, can backfire completely.
> Someone had to translate GL_MAX_TEXTURE_SIZE into mMaxTextureSize. I fail to see how the fact that the Latin alphabet has upper and lower case is to blame for this. This is more about the coding standards the author has to abide to than anything else. If your coding standard would require you to name the property MMAXTEXTURESIZE instead of mMaxTextureSize, would there be any less busy work?
Notice all this busy work
Also is author pushing for everyone should follow one standard? Hard to say what he is asking for.
Maybe I'm being dense, but I fail to see the point. The code has the exact same sequence of tokens in all cases, just with different names for the constant. The fact that a Ctrl+F doesn't find all related uses seems to be the only argument and it doesn't convince me. The article does not provide an alternative solution, or a discussion of the upsides of different naming conventions (e.g. knowing that ALL_CAPS is almo…
All in all, the upper/lower case problem does not seem to be that much of a waste of man-years.