Hi, I’m learning Julia right now and want to teach myself a good coding style right form the start. Is there a Julia design proposal similar to the PEP guidelines for python?
Not exactly, but there is this: Style Guide · The Julia Language
There are also some related style guides, like https://github.com/invenia/BlueStyle which is a bit more exhaustive, I belive.
17 Likes
Thank you!
If you’re also looking for more of a design document, you might find the original Julia paper interesting: https://arxiv.org/pdf/1209.5145.pdf . This is more about how Julia itself was designed, rather than advice for writing Julia code today.
2 Likes
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
There’s also the guide by @ExpandingMan: ExpandingStyle
2 Likes
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