-
Notifications
You must be signed in to change notification settings - Fork 141
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
Conversation
Available style codifications:
@musm seems to have style thoughts in this comment #917 (comment). Perhaps he would like to codify them via JuliaFormatter. |
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. |
Absolutely, this can wait until the queue is low. |
I resolved the merge conflict. |
Rebased since the format tests were failing. |
e64a8be
to
d30d342
Compare
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( |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep
There was a problem hiding this comment.
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
db4ce0f
to
f21e94a
Compare
For this pull request, we should primarily focus on getting the settings to |
2a1ce34
to
5194686
Compare
This should be the case (I've renamed the 2nd commit to show that I only ran Why twice ? To check that formatting is idempotent, so that we don't run into formatting subtleties. |
b1d4830
to
d0ccd75
Compare
can we increase the default line length to 120 or 140?
|
My personal preference is for YAS instead of the blue style wrt to the alignment of functions and nesting: |
e24d969
to
df52615
Compare
They are not perfect, but imo the worst you can do is being inconsistent across the repo. |
I'm not against this change, but I disagree in that I don't think inconsistency is the worst you can do. |
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. |
There was a problem hiding this 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.
Agreed, back to |
Exactly, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Closer...
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( |
There was a problem hiding this comment.
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/properties.jl
Outdated
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) |
There was a problem hiding this comment.
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.
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. |
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. |
We just need a easy to remember reference for "before_formatting" in case we find other situations where the formatting got worse. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved pending CI
I am planning to rebase and merge this. |
I'd recommend squash + merge next time |
Thanks for the help and valuable comments towards better code quality 💯 |
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. |
By the way, it seems that HDF5 upstream also recently started doing automatic formatting using |
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:HDF5.jl/test/plain.jl
Line 438 in ccdb3e9
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 :HDF5.jl/src/datasets.jl
Line 320 in ccdb3e9
, and
HDF5.jl/src/datasets.jl
Line 332 in ccdb3e9
making this hard to follow (inconsistent).
The declarations like:
HDF5.jl/src/groups.jl
Line 115 in ccdb3e9
are hard to read and it would be IMO better if they could be split into multiple lines such as
HDF5.jl/src/readwrite.jl
Line 247 in ccdb3e9
(basically break on a specific margin / line width).
The indentation is inconsistent e.g.
HDF5.jl/src/api/helpers.jl
Line 299 in d6ecf42
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
andtest
directories (for the end users), but this could be extended to other directories likegen
(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).BlueStyle
+ tweaks in.JuliaFormatter
).