Check out JuliaFormatter is you want style enforcement as part of your linting/CI process. The already mentioned Blue Style and the YASGuide are probably the most popular “official” styles.
4 Likes
I am myself partial to the JuMP style guide. It is based in the Julia style guide and the Google style guide:
In some cases, the JuMP style guide diverges from the Julia style guide. All such cases will be explicitly noted and justified.
The JuMP style guide adopts many recommendations from the Google style guides.
My preferred guidance is:
The Julia style guide recommends avoiding underscores “when readable”, for example, haskey, isequal, remotecall, and remotecall_fetch. This convention creates the potential for unnecessary bikeshedding and also forces the user to recall the presence/absence of an underscore, e.g., “was that argument named basename or base_name?”. For consistency, always use underscores in variable names and function names to separate words.
9 Likes
Is that really an issue? How many cases are there of underscores in Base? Seems like you can mostly assume there is no underscore, the few cases really stand out.
Imho, if your function name has underscores, refractor, or come up with a better name.
I really like the naming convention in Base, it forces you to think long and hard about names, and not throw together three keywords describing your function with _ between them. It leads to better names.
3 Likes
@dnldlg - I hope you don’t mind but I edited the title of your post for additional clarity.
Originally read it as you were wondering about proposing changes to Julia but I see what you mean by asking more about a style guide.
Cheers and best of luck with your learning! 
1 Like
Is that really an issue?
Yes, in my opinion it is, and I disagree with you in every point.
How many cases are there of underscores in Base?
- Cloning Julia repository and calling
git grep 'function [a-z0-9]\+_.*'inside it will give pages and pages of names with underscores. One can argue that many are for internal use but, if the core developers frequently use underscores internally, does not this mean they help comprehension?
Imho, if your function name has underscores, refractor, or come up with a better name.
- It is, to me, absolutely ridiculous that your advice is to refactor or come up with a better name. First, not every function can be described with a single word, second, if you gonna use more than one word why not use an underscore? I see no advantage between the same name without underscores.
it forces you to think long and hard about names
-
Using underscores does not hinder creating better names. You can think long and hard about a name and if it ends up comprising two or more words then using an underscore is always better in my opinion. You may argue that the value is in forcing the user to consider better names, and that giving up the underscore is worth this extra nudge, to this I would answer: (1) you will find many users are impervious to this forcing effect and the result are horrendous names (that would be slightly better if underscores were allowed); (2) suggesting against underscores does not only nudge in the direction of good names but may also nudge people farther away from good names if the names are the most intuitive ones but look silly when mashed together.
-
Finally, I am not a native English speaker and I have difficulties understanding non-underscored names. Not every non-native speaker will have the same issue, but I think the choice to not use underscores ends up (unintentionally) disadvantaging an already disadvantaged group.
- Just a complement, to strengthen the JuMP guidance main argument. Not having English as my first language and knowing many languages (C/C++, Java, Ruby, Julia, Haskell, etc…) will make your memory to get a little tired. If I do remember the name of a function without checking the references (making me more productive) the last thing I want is to put a code to run and 30 seconds after be greeted by an error just because I misremembered if it had or not a underscore (and where). It is a common productivity problem for me.
I stand by my arguments.
9 Likes
I agree with the sentiment that underscores can aid comprehension. In the past, I have followed the stricture that names should avoid underscores, and not with the best outcomes, I am afraid.
6 Likes
You’re entitled to your opinion, and to choosing whatever identifiers you prefer.
I’m just really happy that Base, and many others nudge us towards concise names. And, it is “the power of nudging” I am thinking of. Both the nudge towards clean and concise names in Base, and the nudge towards long, meandering names encouraged by the snake_case style. Long names make code hard to read.
Internal names should be as ugly as they want. They are the nuts and bolts and circuitry sitting under the smooth, shiny surface. Ugly names tell me that I’m looking under the hood.
(BTW, also non-native speaker here.)
1 Like
I have only one last thing to say to you: isstructtype.
4 Likes
That name serves its purpose: I’ve never used that function, and probably won’t 
Is it too late to make Julia variable names insensitive to underscores and letter case, like Nim does? That might help solve the debate 
(Kidding, that’s definitely not an option now 
)
1 Like
Just out of curiosity, why nobody seems to use camelCase any more ? I like it :-/
While this guide does, in fact, exist, it has some highly idiosyncratic and off-kilter guidelines. I don’t think it should be held up as a ‘standard example’, it’s more of a list of ‘conversation starters.’
What exactly do you mean by not using camelCase anymore? Most style guides suggest struct type names to be in camelCase. It is just not adopted for local identifiers.
Well, I happen to think it’s very sensible. To each their own, I guess 
This is a great example of how it is impossible to agree on style guides, even between experienced programmers. I am, as made exceedingly clear above, against DNF’s position of “no underscores in identifiers”. However, I do agree with DNF that ExpandingStyle is not very sensible, and the own author admits suggesting that “single characters are ideal” “[…] is likely to be one of the more controversial aspects of this style guide […]”. It is maybe the more important point I disagree with it, but I disagree with ExpandingMan’s guide on many other less relevant things.
2 Likes
I believe the case suggested for type name is actually PascalCase (as opposed to camelCase, where the first letter is lowercase).
It is possible, but ExpandingMan’s guide actually refers to it as `Upper camel-case’.
I was speaking more generally than Julia, but still in Julia… if UpperCamelCase (or PascaleCase) is used for structs/consts, why not keep the same convention with camelCase for the other variables instead of using _ ? (but again, more in general I see more and more usage of underscores than camelcases)
I suppose the idea is to make the distinction very apparent. If PascalCase is used for module and type names, FULL_UPPERCASE is used for the name of constants, and snake_case is used for variables/field and function names, then it is very apparent to what you are looking just by the casing of the identifier. We could probably blend camelCase into the mix attributing it to some group of identifiers. However, I find camelCase kinda awkward, it is strange to use it for identifiers that may start with an acronym (or continue to one), it is indistinguishable of snake_case if the identifier has only one word, and it is slightly less readable (but not much). So, I believe the main problem is that is kinda of a choice if you gonna have snake_case or camelCase (because of one-word identifiers the two do not coexist well), and snake_case ended up winning the fight.
5 Likes