Stefan: I completely agree with the philosophy of using IDs to evaluate whether or not your code is properly factored, but it seems to me the naming convention question is orthogonal: a squished id isn't much shorter, and is more often than not less readable, than its underscore-delimited counterpart. In fact, having an underscore count for an ID may be a better indicator of its candidacy for refactoring than simply length.
Yes, yes. I'm worrying about the brand of nails used to build the bikeshed. On Thu, Feb 5, 2015 at 3:29 PM, Stefan Karpinski <[email protected]> wrote: > The general philosophy is that for user code, having underscores in names > is fine, especially when the name refers to a composite thing. In Base > Julia, we consider long names with underscores to be a library design smell > that suggests that we're exposing something that's not sufficiently atomic. > The example of searchsortedlast and searchsortedfirst is in line with this > – I've never liked these names and would generally prefer to simply have > searchsorted returning a range from the first to last index where the value > occurs (which is an empty range when the value does not occur at all). > > On Thu, Feb 5, 2015 at 2:53 PM, Mike Innes <[email protected]> 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 <[email protected]> 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. >>> >>> >>> >>> >> >
