It seems such a small thing, but optional squished case bugs me. In fact, it is the one blemish <http://en.wikipedia.org/wiki/The_Birth-Mark> on Julia that bugs me most. (Of course, that's pretty high praise for a language if the thing you like least about it is a naming convention.)
Squished case *is* readable in many cases, and I do like keeping IDs short. But it's the *optional* part that's the real issue in my mind. One of the values of having an established convention should be that you don't have to think about it. You just follow it mechanically and it won't distract you from the real work at hand. Having a convention to prefer squished case, but use underscores for longer IDs involves making a *judgement call* for every ID, and that's the real shame. Squished case can't reasonably be used for everything. I've personally adopted an "always opt for underscores" approach. Just as a matter of personal taste, I've always liked lowercase initial camel case, and have wondered why that was never on the table for Julia. In any case, I've developed a taste for underscores (which used to hurt my eyes to look at) On Thu, Feb 5, 2015 at 2:53 PM, Mike Innes <mike.j.in...@gmail.com> wrote: > An underscore is basically the only option here, seeing basically every > other operator imaginable is taken. > > Still, I'm personally happy with the current convention of underscore_case > alongside squished case where it doesn't hurt readability. > > I agree that things like `searchsortedlast` could probably be made a bit > clearer but short things like `isequal` are almost less readable (to me at > least) when they're made longer. The other thing that's nice about the > squished case option is that it does encourage you to avoid underscores, > i.e. by choosing a name that's concise and clear to begin with, ideally in > one word. > > I'm sure opinions will vary, but just throwing my two cents in. > > On 5 February 2015 at 19:12, David James <davidcja...@gmail.com> wrote: > >> Hello, >> >> The title of this post is "Moving Past a Squished Case Convention" not >> "Moving Pastas Quiche...". :) >> >> The Julia standard library tends to use the "squishedcase" notation. >> Being concise is great for mathematical functions, like sin, cos, and ln. >> However, it is cognitively harder for people for "compound" function names; >> e.g. "searchsortedlast". Such a naming convention flies in the face of real >> programming experience. It makes programming harder for people. >> >> There are many sane ways to name functions. Lisps tend to use hyphens, >> others often use underscores. R libraries use a non-standard mix [1]. >> Interestingly, the Julia parser code itself uses hyphens; e.g. >> prec-assignment and prec-conditional: >> https://github.com/JuliaLang/julia/blob/master/src/julia-parser.scm >> >> It would be a shame for squishedcase to persist as the language reaches >> 1.0. What are some possible ways to address this problem without breaking >> compatibility in the short-run? >> >> I see a possible solution. Choose a character and encourage its use to >> break apart words; e.g. -, _, or a middot (·) [2]. Make it highly >> recommended but non-breaking until 1.0. Deprecate >> functionsusingsquishedcase. >> >> Julia is great overall but lacking in this way. Let's make it better. >> >> Sincerely, >> David >> >> [1] >> http://stackoverflow.com/questions/1944910/what-is-your-preferred-style-for-naming-variables-in-r >> >> [2] The middot is relatively unobtrusive and doesn't take up much space >> horizontally, e.g. search·sorted·last. It is also useful for variables >> representing compound units; e.g. N·m. >> >> >> >> >
