At least we skipped cumtrapz…
13 Likes
I don’t particularly like lower camelCase. It looks like an identifier rear-ended another one, and got scrunched up. There’s a lack of symmetry that is much better for upper CamelCase, and it appears to lend extra emphasis to certain parts of the identifier that don’t necessarily deserve it, like
timeOfArrival
That seems all wrong, like you’re pronouncing it while sitting on a bus in Northern Norway.
time_of_arrival
is much better, with even emphasis.
snake_case is encouraged in Julia for compound names, but it is also a red flag. If your code is full of snake_case function names, it’s a sign that you should maybe refactor some of them into smaller parts. It’s good in that way, you should force yourself to consider how to make names concise, not too obscure, not too long, generic if possible (x is a great name in generic code.)
(The best name in the above example is, btw
toa
)
But you are of course free to use camelCase as much as you like 
5 Likes
Having a quick scan of some of my functions with more than one underscore, I have check_bounds_pars(), check_bounds_df(), and get_drug_order(). I don’t think any of those are excessive, even though the first two are definitely related.
I know that lowerCamelCase does look a bit odd (although I prefer it for my username), but UpperCamelCase always looks like a type, so if functions and variables started being written that way, it would start to get confusing!
Oh, yeah, I’m definitely not advocating upper CamelCase for variable/function names, just saying that it’s not as problematic as lower camelCase in general.
As if coming up with a meaningful and descriptive name was not difficult enough in itself …
This is the challenge: meaningful, descriptive and short! Remember, a long descriptive name can make that identifier clearer, buts hurts the overall readability of entire code.
Note that the recommendation against underscore names comes from the Julia base language itself — and isn’t as applicable to end-user code. The key difference is that Julia and its stdlibs are trying to be as generically applicable to lots of different types, and that’s where the red flag is most helpful. Writing a generic library? Then, yeah, spend lots of time thinking about names and make them short and well-factored. Writing specific analysis code? Be verbose and specific!
9 Likes
I think that there is always a tradeoff with legibility and verbosity, also for end-user analysis code. For generic code it’s just easier to lean towards brevity, since there is little inherent meaning in the variable names.
But even for specific analysis code, especially if it is ‘dense’ with many, perhaps complicated operations, overly long names turn the code into a jungle.
The solution I prefer is to try to identify operations that are ‘abstract’ and separate them out, they can have brief identifier names in them, and then (in the best of all worlds) only some data structures, and a top level ‘script’ with some simple function calls, contain verbose names.
It is very easy to read, but creates a bit of a problem with - operator. Unless you love parenthesis and prefix notation.
1 Like
I do. 
3 Likes
Unfortunately we still have std.
4 Likes
I do not know if it is why I am not a native English speaker but Base.atexit always bug me “ate… xit, no this cannot be right, a tex it? but this has nothing to do with latex, what would it even mean? is this some word I do not know? is ‘atex’ a verb? OHHH I am dumb.”.
Also, the predicates starting with is and having no underscore no matter what, I am looking at you two isstructtype and issingletontype, one could expect that if the next word starts with s a underscore would be welcome…
Also, I have to find yet someone that convinces me that JuMP reasoning about always using underscores is not the most reasonable thing I have ever seen.
7 Likes
CamelCase for modules and structs, snake_case for functions gives a quick, visual identifier of what you are dealing with. It’s consistent and immediate.
Plus, that’s what Ruby does, which is objectively a really pretty language. And I am ready to fight anyone who says otherwise 
4 Likes
I still, really, really regret adopting Googles R Style Guide a couple of years ago, because of
Google prefers identifying functions with
BigCamelCaseto clearly distinguish them from other objects.
Never again will I write functions in CamelCase, especially not as a German native speaker.
Julias default style works well for me, except for the occasional hard decision to use “_” or to concatenate.
4 Likes