X Tutup
Skip to content

Fix #21: Adopt .editorconfig file and reformat#103

Merged
olivergondza merged 10 commits intoopenstack4j:masterfrom
olivergondza:editorconfig
Dec 15, 2020
Merged

Fix #21: Adopt .editorconfig file and reformat#103
olivergondza merged 10 commits intoopenstack4j:masterfrom
olivergondza:editorconfig

Conversation

@olivergondza
Copy link
Copy Markdown
Member

@olivergondza olivergondza commented Nov 13, 2020

Suggesting particular .editorconfg and reformatting the code to match: https://github.com/olivergondza/openstack4j/blob/editorconfig/.editorconfig

Whitespace ignoring diff: https://github.com/openstack4j/openstack4j/pull/103/files?w=1

@olivergondza
Copy link
Copy Markdown
Member Author

@openstack4j/reviewers, please take a look. Thanks!

@olivergondza
Copy link
Copy Markdown
Member Author

@manuelmazzuola, I would especially appreciate your feedback...

Copy link
Copy Markdown
Member

@manuelmazzuola manuelmazzuola left a comment

Choose a reason for hiding this comment

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

The project contains some scripts, yaml files, xml like files and the editorconfig file itself so I would add some rules for those files

editorconfig

[.editorconfig]
ij_editorconfig_align_group_field_declarations = false
ij_editorconfig_space_after_colon = false
ij_editorconfig_space_after_comma = true
ij_editorconfig_space_before_colon = false
ij_editorconfig_space_before_comma = false
ij_editorconfig_spaces_around_assignment_operators = true

some for scripts

[{*.bash,*.zsh,*.sh}]
ij_shell_binary_ops_start_line = false
ij_shell_keep_column_alignment_padding = false
ij_shell_minify_program = false
ij_shell_redirect_followed_by_space = false
ij_shell_switch_cases_indented = false

for yml files

[{*.yml,*.yaml}]
indent_size = 2
ij_continuation_indent_size = 2
ij_yaml_keep_indents_on_empty_lines = false
ij_yaml_keep_line_breaks = true

and xml like files

[{*.jhm,*.xslt,*.xul,*.rng,*.xsl,*.xsd,*.ant,*.tld,*.fxml,*.wsdl,*.jrxml,*.xml,*.jnlp,*.pom}]
indent_style = tab
ij_smart_tabs = true
ij_xml_block_comment_at_first_column = true
ij_xml_keep_indents_on_empty_lines = false
ij_xml_line_comment_at_first_column = true

ij_formatter_on_tag = @formatter:on
ij_formatter_tags_enabled = false
ij_smart_tabs = false
ij_wrap_on_typing = false
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggested change
ij_wrap_on_typing = false
ij_wrap_on_typing = false
ij_visual_guides = 80,120

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Good point we can make sure this is turned on for people. 120 mark should be enough, though

.editorconfig Outdated
ij_wrap_on_typing = false

[*.java]
# ij_java_align_consecutive_assignments = false
Copy link
Copy Markdown
Member

@manuelmazzuola manuelmazzuola Nov 19, 2020

Choose a reason for hiding this comment

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

Why these rules are commented?
I suggest uncommenting all the commented lines

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

That is a good point as without being as explicit as we can be, the result will always be a blend of .editorconfig and IDE config.

@pjdarton
Copy link
Copy Markdown
Contributor

So, I generally agree with the reformatting - I've not gone through it in extreme detail, but it looks ok (in github's WebUI anyway).
...just confirm that you're not mandating the use of tabs, right? I'm very much a spaces person 😛

My only concern is that, while I'm generally in favour of standardising stuff, including code layout ... I'm only in favour when it's dead easy to conform to such restrictions.
e.g. in my career, at one employer, Eclipse was the IDE-of-choice and "CheckStyle" was used (complete with some custom-written rules) to enforce layout & code style ... but Eclipse was configured with a code-formatting style that meant that just pressing ctrl-shift-F would fix 99% of transgressions. It meant that conformity was easily achieved and this worked well.
...but an overly-restrictive code-formatting system that's hard to master may discourage folks from creating / submitting PRs.

So, I'd want anything like this to have automated checks, and ones that'd show any "ignorant, but trying to contribute" folks what the objections were and what they needed to do to make the code perfect ... especially as I'm likely to be one of those "ignorant, but trying to contribute" people myself.
i.e. we want high standards ... but with a very low barrier to entry.

@manuelmazzuola
Copy link
Copy Markdown
Member

I'm only in favour when it's dead easy to conform to such restrictions.
pressing ctrl-shift-F would fix 99% of transgressions. It meant that conformity was easily achieved and this worked well.
...but an overly-restrictive code-formatting system that's hard to master may discourage folks from creating / submitting PRs.

How is overly-restrictive?
As you said doing a ctrl-shift-f or a ctrl-alt-l is enough, it's not hard to master.
It is now hard to master, without a proper guideline for the code-formatting.

but with a very low barrier to entry.

I don't think that this is a barrier, completely the opposite, is a tool to help novice and expert programmers to format code correctly and encourage people to open PRs.

@pjdarton
Copy link
Copy Markdown
Contributor

It can be overly restrictive if there isn't a discoverable and well-documented method of reformatting the code.
e.g. I use Eclipse a lot, many of my colleages use IntelliJ, there's a thousand other alternatives ... and few of these will automatically know what to do with this editorconfig/.editorconfig file - this tech is sufficiently new that it's not "something that everyone knows".

So, sure, lets do this ... but if we're going to police it (and we need to if we want those rules to be followed!) then any build errors/warnings need to tell folks both what's wrong and where they can find out about the tech behind the warning, otherwise folks who don't know about this already won't discover it.
i.e. you know this, I know about this, but we need to make it sufficiently "discoverable" that anyone else working on this code will be told about it too.

@bboyHan
Copy link
Copy Markdown
Contributor

bboyHan commented Nov 24, 2020

IntelliJ IDEA is a good IDE. I also use it .

@olivergondza
Copy link
Copy Markdown
Member Author

Thanks for your input, folks. Let me integrate this ASAP, so we can reflect this in new MRs.

@olivergondza
Copy link
Copy Markdown
Member Author

...just confirm that you're not mandating the use of tabs, right? I'm very much a spaces person stuck_out_tongue

Nope, @manuelmazzuola have suggested that for XML only, but I urge us to stick to spaces.

@olivergondza olivergondza merged commit ab6f593 into openstack4j:master Dec 15, 2020
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.

4 participants

X Tutup