This is obviously a point of taste, but for what it's worth I like Julia's approach. I am not a Fortran programmer, but being a scientific computing specialist I have likely been influenced by that culture - and there short "uninformative" names are the norm, rather than the exception.
I like the all lower case approach for the simple reason that it forces people to really think whether a long squished-together name is necessary. In one of my projects for example I have a function which was translated in one-to-one fashion from a C interface, and it reads "buildkernelfromsource." That is a really ugly name, now I could make this cleaner by calling it "buildKernelFromSource," now each of the grammatical units stick out in a much more readable way. However there is a lot of redundancy here, because the function accepts a string called "filename" and outputs something with type "Kernel." Why don't I just call this function "build" and let the types offer further documentation? Obviously this would be in addition to proper documentation and comments, and shouldn't stand alone as the sole indication of functionality. This is something I have yet to fix in the code, but I offer it as a simple example :) I find that in camelCase, it lets people be a little lazy with verbosity that otherwise could be removed. For my aesthetics I don't like it as much. On Friday, February 6, 2015 at 3:26:49 AM UTC-6, Steven Sagaert wrote: > > I prefer Java's camelcase: searchSortedLast: it's the same length as all > lower case but clearer. > > On Thursday, February 5, 2015 at 8:12:43 PM UTC+1, David James 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. >> >> >> >>
