Code formatting

[jcannon-gplates]

Is there some sort of code formatting standard for gplately?

I only ask because a lot of the ptt directory got reformatted in this commit.

For example, much of the code in continent_contouring is harder for me to parse visually. I'm guessing it's a line length limit (like covered here in PEP 8). Also, it did add a lot of extra lines, which means more vertical scrolling is required to read the same amount of code.

For example,

grid_points_inside_merged_continent[continent.grid_points_inside_continent] = True

...got changed to:

grid_points_inside_merged_continent[
    continent.grid_points_inside_continent
] = True

And:

self.contouring_buffer_and_gap_distance_radians = contouring_buffer_and_gap_distance_radians

...got changed to:

self.contouring_buffer_and_gap_distance_radians = (
    contouring_buffer_and_gap_distance_radians
)

And:

continent_contouring_area_threshold_steradians = self.continent_contouring_area_threshold_steradians_function(age)
if (continent_contouring_area_threshold_steradians > 0 and
    contoured_continent.get_area() < continent_contouring_area_threshold_steradians):
        continue

...got changed to:

continent_contouring_area_threshold_steradians = (
	self.continent_contouring_area_threshold_steradians_function(age)
)
if (
	continent_contouring_area_threshold_steradians > 0
	and contoured_continent.get_area()
	< continent_contouring_area_threshold_steradians
):
	continue

[michaelchin]

I am using the 'black' formatter.

[jcannon-gplates]

I've started using this too. It seems most of the code files (that I've edited) are already in "black" format - likely from the automatic "formatOnSave" from your commits so far (since it formats the entire file on saving).

So we're probably pretty close to having the entire codebase in "black" format. Which is good because future commits will only show the actual changes made in the commits.

PS: Sounds like the "black" formatter doesn't have a "formatOnType" option (see here). But "formatOnSave" is fine for us now I think.

[jcannon-gplates]

In reference to your recent comment, do you think it's worth splitting one commit into two in these cases?

In other words, one commit is the actual code change and a second commit is the 'black' reformatting. Because I was quickly browsing through your changes the other day (out of curiosity) and it was a little hard to find the real changes.

I guess eventually the entire codebase will get 'black' reformatted (especially if we all use it).

[jcannon-gplates]

Or maybe there can be a one-off 'black' reformat of the entire code base, as a single big commit. After that, we all use the 'black' reformatter when committing. That way future commits will only show the "real" changes.

[michaelchin]

I found the formatting changes afterwards. I was surprised too. And I added the comments in honors of the original owner of that file.

I chose "black" randomly. If we have better choices, I am happy to use another one instead. The important thing is the team need to agree on the one formatter and use it.

Another option is create a github action and run "code formatting/checking" automatically.