Adopt style guide

[sethaxen]

It would be nice to early on adopt an existing style guide so the conventions are well established. I use Invenia's Blue Style for my repos. JuliaFormatter.jl's defaults match Blue Style pretty well.

[mschauer]

I feel strongly about https://github.com/jrevels/YASGuide/issues/13#issue-484616702, otherwise I feel flexible

[sethaxen]

I feel strongly about jrevels/YASGuide#13 (comment), otherwise I feel flexible

Hmm, I definitely prefer spaces around *. Less whitespace makes it much harder for me to read code. Somehow I don't have an issue with no space around ^, probably because visually it's really unique.

Is the rule basically spaces around + but all other operators have no spacing?

I feel pretty strongly about https://github.com/invenia/BlueStyle#module-imports. Module imports/exports/using should be in the top file of the package so the API and dependencies are obvious. import should be avoided, and packages should in general overload using the dot syntax i.e.

Base.eltype(x) = ... # good

import Base: eltype
eltype(x) = ... # bad

If a function/constant/struct not in the standard library is used, it should be prefixed by the module name. If it's used so much that that would make the code cluttered, then it can be explicitly included in the top file for clarity with (using ModuleName: functionname). This makes it a lot easier to track whether a function was correctly overloaded or where the used functionality is coming from.

[mschauer]

By convention, we tend to space operators more tightly if they get applied before other nearby operators.

https://docs.julialang.org/en/v1/manual/mathematical-operations/

[cscherrer]

I'm very on-the-fence about style guides. They're a good thing in principle, but it seems to sometimes be a pedantic slippery slope. I'd be strongly in favor of anything that can be automated, like JuliaFormatter.jl in vscode, and maybe a few other guidelines.

I do have some maybe unusual preferences, like I'd rather have exports near the function definition than in a giant list. I'm never going to read through the list, but if I'm thinking about a particular function, it's helpful to see whether it's exported. But it's not such a strong preference.

I could go either way on things like operator spacing, but hopefully it can automated so it doesn't take a lot of time or attention.

I agree that Base.eltype(x) = ... style is much better than eltype(x) = ....

[gdalle]

Bumping this to say that in my (ongoing) docs revamp, I'm trying to generally adhere to JuliaFormatter / BlueStyle, especially by grouping imports and exports

[cscherrer]

Thanks @gdalle . I'd be very open to a PR to automate this in github actions