Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add formatting check action and apply an initial format #984

Merged
merged 6 commits into from
Aug 5, 2022

Conversation

t-bltg
Copy link
Contributor

@t-bltg t-bltg commented Jul 5, 2022

This PR is a proposition in order to add consistency across the source and test files (after #983 (comment)).

The tests are hard to read because the @testset blocks are not indented:

@testset "h5d_fill" begin

requiring (spurious) manual addition of comment such as end # testset "Test h5d_fill.

The source files mixes both function ... end and one liner function declarations like :

function create_external_dataset(parent::Union{File,Group}, name::AbstractString, filepath::AbstractString, t, sz::Dims, offset::Integer=0)

, and
read_dataset(dset::Dataset, memtype::Datatype, buf, xfer::DatasetTransferProperties=dset.xfer) =

making this hard to follow (inconsistent).

The declarations like:

move_link(src::Union{File,Group}, src_name::AbstractString, dest::Union{File,Group}, dest_name::AbstractString=src_name, lapl::LinkAccessProperties = LinkAccessProperties(), lcpl::LinkCreateProperties = LinkCreateProperties()) =

are hard to read and it would be IMO better if they could be split into multiple lines such as
Base.similar(

(basically break on a specific margin / line width).

The indentation is inconsistent e.g.

return _has_h5p_set_file_locking
which uses 3 spaces instead of 4 (https://docs.julialang.org/en/v1/manual/style-guide/).

I'll stop there with the examples, my point being that I don't care which style convention is used (this is very opinionated), as long as it is consistent across all source files.

Currently in this repo, no style guidelines are provided for developers, inducing wasted time on style discussions (e.g. #983 (comment) or #917 (comment)).

If needed, formatting auto-generated files can be omitted by adding #! format: off to a file header (e.g. gen/gen_wrappers.jl -> src/api/functions.jl) ?

I propose that we only apply formatting to src and test directories (for the end users), but this could be extended to other directories like gen (to be discussed ?).

All the current inconsistencies can be handled in an automated manner using a formatting check action (auto format PRs should be avoided, because they pollute the git history: we should instead use (blocking or non blocking) checks for PRs, see the added .github/workflows/Format-check.yml action).

  • discuss which stylistic conventions are to be used (I'd vote for BlueStyle + tweaks in .JuliaFormatter).

@mkitti
Copy link
Member

mkitti commented Jul 5, 2022

Available style codifications:

@musm seems to have style thoughts in this comment #917 (comment). Perhaps he would like to codify them via JuliaFormatter.

@mkitti
Copy link
Member

mkitti commented Jul 5, 2022

To merge this, I would like to try to clear the pull request queue as much as possible. Merging this will require significant work to make those branches work again.

@t-bltg
Copy link
Contributor Author

t-bltg commented Jul 5, 2022

Merging this will require significant work to make those branches work again.

Absolutely, this can wait until the queue is low.

@mkitti
Copy link
Member

mkitti commented Jul 19, 2022

I resolved the merge conflict.

@t-bltg
Copy link
Contributor Author

t-bltg commented Jul 19, 2022

Rebased since the format tests were failing.

@t-bltg
Copy link
Contributor Author

t-bltg commented Aug 3, 2022

I think it's time to go forward on this one (recent PR queue is low). @musm, what do you think ?

return Attribute(attrid, file(parent))
end

# generic method
write_attribute(attr::Attribute, memtype::Datatype, x) = API.h5a_write(attr, memtype, x)
# specific methods
function write_attribute(attr::Attribute, memtype::Datatype, x::AbstractArray)
length(x) == length(attr) || throw(ArgumentError("Invalid length: $(length(x)) != $(length(attr)), for attribute \"$(name(attr))\""))
length(x) == length(attr) || throw(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This shouldn't be a one liner

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean we should manually convert to plain if ... end, right ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's do this after this pull request

@t-bltg t-bltg force-pushed the fmt branch 2 times, most recently from db4ce0f to f21e94a Compare August 3, 2022 18:14
@mkitti
Copy link
Member

mkitti commented Aug 3, 2022

For this pull request, we should primarily focus on getting the settings to .JuliaFormatter.toml correct. I should be able to pull master, check out .JuliaFormatter.toml, apply the formatting, and see almost no diff to this branch. Other stylistic changes should be reserved for other pull requests.

@t-bltg t-bltg force-pushed the fmt branch 2 times, most recently from 2a1ce34 to 5194686 Compare August 3, 2022 20:22
@t-bltg
Copy link
Contributor Author

t-bltg commented Aug 3, 2022

I should be able to pull master, check out .JuliaFormatter.toml, apply the formatting, and see almost diff to this branch.

This should be the case (I've renamed the 2nd commit to show that I only ran format(["src", "test"]) twice after creating the .JuliaFormatter configuration file (1st commit in this PR)).

Why twice ? To check that formatting is idempotent, so that we don't run into formatting subtleties.

@musm
Copy link
Member

musm commented Aug 5, 2022

can we increase the default line length to 120 or 140?
I think the following addition is what's needed.

margin = 120

@musm
Copy link
Member

musm commented Aug 5, 2022

My personal preference is for YAS instead of the blue style wrt to the alignment of functions and nesting:
https://domluna.github.io/JuliaFormatter.jl/stable/yas_style/#Differences-from-DefaultStyle

@t-bltg t-bltg force-pushed the fmt branch 2 times, most recently from e24d969 to df52615 Compare August 5, 2022 21:41
@t-bltg
Copy link
Contributor Author

t-bltg commented Aug 5, 2022

In general, I'm not crazy about auto-formatters I think sometimes it makes code less clear than originally written, but I appreciate the consistency.

They are not perfect, but imo the worst you can do is being inconsistent across the repo.

@musm
Copy link
Member

musm commented Aug 5, 2022

I'm not against this change, but I disagree in that I don't think inconsistency is the worst you can do.
Base Julia is inconsistent across the whole repo and the style does vary depending on who wrote what.

@musm
Copy link
Member

musm commented Aug 5, 2022

In general, everything looks fine, I'm just debating if we should switch back to blue, some of the changes with YAS are indeed annoying.

Copy link
Member

@mkitti mkitti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of the indentation looks excessive. I think this is due to YAS.

gen/gen_wrappers.jl Outdated Show resolved Hide resolved
src/datasets.jl Outdated Show resolved Hide resolved
src/datasets.jl Outdated Show resolved Hide resolved
src/datasets.jl Outdated Show resolved Hide resolved
src/dataspaces.jl Outdated Show resolved Hide resolved
@t-bltg
Copy link
Contributor Author

t-bltg commented Aug 5, 2022

Some of the indentation looks excessive. I think this is due to YAS.

Agreed, back to blue.

@t-bltg
Copy link
Contributor Author

t-bltg commented Aug 5, 2022

Base Julia is inconsistent across the whole repo and the style does vary depending on who wrote what.

Exactly, JuliaLang/julia should have a format auto-check for PRs, and stick to an arbitrary style.
Those are good coding practices everyone should adopt.
Unfortunately, a PR to julia would be pointless (0% chance of being merged) given the flame wars it would trigger.

Copy link
Member

@mkitti mkitti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Closer...

src/file.jl Outdated Show resolved Hide resolved
test/readremote.jl Outdated Show resolved Hide resolved
return Attribute(attrid, file(parent))
end

# generic method
write_attribute(attr::Attribute, memtype::Datatype, x) = API.h5a_write(attr, memtype, x)
# specific methods
function write_attribute(attr::Attribute, memtype::Datatype, x::AbstractArray)
length(x) == length(attr) || throw(ArgumentError("Invalid length: $(length(x)) != $(length(attr)), for attribute \"$(name(attr))\""))
length(x) == length(attr) || throw(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's do this after this pull request

src/file.jl Show resolved Hide resolved
src/file.jl Show resolved Hide resolved
Comment on lines 313 to 318
if name === :local_heap_size_hint
API.h5p_get_local_heap_size_hint(p)
elseif name === :track_order
get_track_order(p)
else
class_getproperty(superclass(GroupCreateProperties), p, name)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused why it modified this and not some of the others below.

src/properties.jl Outdated Show resolved Hide resolved
src/typeconversions.jl Outdated Show resolved Hide resolved
@mkitti
Copy link
Member

mkitti commented Aug 5, 2022

Maybe we should just merge and revert some of this manually. I think we should also add a preformatting tag unless we want to release before merging this.

@mkitti
Copy link
Member

mkitti commented Aug 5, 2022

Ok, I think we're close enough. I'm going to make a few manual changes to turn off formatting in some sections, and then merge.

@musm
Copy link
Member

musm commented Aug 5, 2022

Ok, I think we're close enough. I'm going to make a few manual changes to turn off formatting in some sections, and then merge.

SGTM

Do we need a pre-tag, maybe just the commit is good enough.

@mkitti
Copy link
Member

mkitti commented Aug 5, 2022

We just need a easy to remember reference for "before_formatting" in case we find other situations where the formatting got worse.

Copy link
Member

@mkitti mkitti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved pending CI

@mkitti
Copy link
Member

mkitti commented Aug 5, 2022

I am planning to rebase and merge this.

@mkitti mkitti merged commit 259763f into JuliaIO:master Aug 5, 2022
@musm
Copy link
Member

musm commented Aug 6, 2022

I'd recommend squash + merge next time

@t-bltg t-bltg deleted the fmt branch August 6, 2022 06:18
@t-bltg
Copy link
Contributor Author

t-bltg commented Aug 6, 2022

Thanks for the help and valuable comments towards better code quality 💯

@t-bltg t-bltg mentioned this pull request Aug 6, 2022
@mkitti
Copy link
Member

mkitti commented Aug 7, 2022

I'd recommend squash + merge next time

I intentionally chose not to squash here since t-bltg explicitly tried to divide up his work into three distinct, atomic commits. Perhaps I should have squashed my commits together.

@mkitti
Copy link
Member

mkitti commented Aug 8, 2022

By the way, it seems that HDF5 upstream also recently started doing automatic formatting using clang-format:
https://github.com/HDFGroup/hdf5/blob/develop/.clang-format

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants