Uniform code style

[aurorarossi]

It fixes some typos and spaces.

[codecov]

Codecov Report

Merging #190 (00393ec) into master (4fce15b) will decrease coverage by 0.07%.
The diff coverage is 94.84%.

@@            Coverage Diff             @@
##           master     #190      +/-   ##
==========================================
- Coverage   97.47%   97.40%   -0.08%     
==========================================
  Files         109      109              
  Lines        6349     6468     +119     
==========================================
+ Hits         6189     6300     +111     
- Misses        160      168       +8     

[gdalle]

Hey @aurorarossi did you do this with JuliaFormatter or manually? Because it would be great to actually add a formatting check to the test suite with a consistent style (see #66). Gonna push this on your PR if that's OK

[aurorarossi]

I have the following settings on vsc:

• enabled Insert Final Newline
• enabled Trim Final Newlines
• enabled Trim Trailing Whitespace
• disabled Ignore Trim Whitespace.

Yes of course! You can add the JuliaFormatter here

[gdalle]

This is a great idea, thank you for starting it! I think the VSCode settings are less reliable than an explicit JuliaFormatter configuration (see here) with a well-known style like BlueStyle. Let's see how much of the code base it changes

[simonschoelly]

I think this PR also fixes so grammatical errors - now its a bit difficult to spot these parts with also these changes here - maybe we can make two PRs out of that?

[gdalle]

BlueStyle seems like the most well-established specification, whereas SciML is more recent. However JuliaFormatter cannot do it all, so we must tell contributors to adhere to the style guidelines in general. Should we add a badge to the README too?

[simonschoelly]

Any reason to prefer BlueStyle? (I am not yet familiar with these styles). We could also specify our own rules right?

[simonschoelly]

In any cases, most of the changes here seem to be sensible.

[gdalle]

I just use it because it's already well documented, so we can point contributors to the exhaustive specification by Invenia. We could make up our own rules but that would require explaining them to everyone in our docs.

Also, it's easier to contribute when you're already familiar with the style guide, which wouldn't be the case for Graphs-specific rules.

[gdalle]

My hot take is that the precise choice of style does not matter, as long as it's clear and easy to apply, and BlueStyle satisfies both criteria

[simonschoelly]

Maybe it makes sense to use some common style, as then people don't need to reconfigure their editor differently for every project.

[simonschoelly]

What about the default format by JuliaFormatter? Would that also be an option?

[gdalle]

The default format by JuliaFormatter is much less well-specified than BlueStyle. One of the perks of BlueStyle is that it also gives coherent writing advice to the contributors that cannot be enfored by a simple linter

[gdalle]

Maybe it makes sense to use some common style, as then people don't need to reconfigure their editor differently for every project.

Another perk of JuliaFormatter is that the formatting in the Julia extension for VSCode is based on it. And it takes into account the .JuliaFormatter.toml file at the root of the package to format each file according to the local specification (in our case style = "blue")

[gdalle]

I think this PR also fixes so grammatical errors - now its a bit difficult to spot these parts with also these changes here - maybe we can make two PRs out of that?

You're right, it's hard to spot but you can see them during code review if you filter by commit (to keep only the ones by @aurorarossi) and specify that you don't want to see whitespace modifications. I reviewed all of these changes and they look okay to me.

I just wanted to do code formatting in the same PR because if we merged @aurorarossi's PR alone it would have whitespace changes that are incoherent with the BlueStyle