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

Style guidelines #28

Open
stil4m opened this issue Oct 29, 2016 · 13 comments
Open

Style guidelines #28

stil4m opened this issue Oct 29, 2016 · 13 comments
Labels

Comments

@stil4m
Copy link
Owner

stil4m commented Oct 29, 2016

There should be style guidelines for the Java code to minimize the changes.

These should at least address:

  • Import order
  • Use of * imports
  • Amount of whitespace between methods and fields.

Should the repo contain a settings file/JAR, or just some guidelines?

@tubbynl
Copy link
Contributor

tubbynl commented Oct 31, 2016

I agree, i tried to keep it to a minimum (disable save-actions formatting in eclipse).

What IDE do you use because i am considering switching IDE?

@tubbynl
Copy link
Contributor

tubbynl commented Oct 31, 2016

btw; a bit offtopic but can i expect @stil4m or @jcassee at jfall?

@stil4m
Copy link
Owner Author

stil4m commented Nov 1, 2016

Nope. Study and work have priority at this moment.

@jcassee
Copy link
Contributor

jcassee commented Nov 1, 2016

@tubbynl Sorry, not this year.

@tubbynl
Copy link
Contributor

tubbynl commented Nov 14, 2016

your whitespace settings are?

  • Spaces only
  • Indentation/tab size: 2

or perhaps we could conform to some styleguide already out there; example: https://google.github.io/styleguide/javaguide.html

i'm not really specific on these things just that it's practical to be in sync in order to prevent unneeded merge conflicts.

@stil4m
Copy link
Owner Author

stil4m commented Nov 14, 2016

I think I have it on 4 spaces. I want to cover this with a checkstyle config, which will run with CI. I already have a local branch for this.

I'm not sure if we should take all the guidelines or differ on some. 100 columns seem a bit harsh IMHO.
Other file types such as JSON are not addressed, but need to be accounted for as well.

I'm kinda swamped ATM with work and a master program, thus this will not have much prio at the moment. For now I will run a formatter after each release manually (most optimal with the available time/time to fix this ATM).

@tubbynl
Copy link
Contributor

tubbynl commented Nov 14, 2016

the example was more of an indication; i mostly try to use the default Java conventions but with some changes (200 line width and space-only indentation on 4 characters).

i've already set auto-formatting off on this project so it doesn't interfere too much :)

tnx for merging my pull-requests btw :)

@stil4m
Copy link
Owner Author

stil4m commented Nov 14, 2016

Not a optimal solution, but this is a link to my Code Style settings from Idea: https://cloudup.com/cG-oeKjS5uC

Maybe you can enable it for this project (for the time being)

@tubbynl
Copy link
Contributor

tubbynl commented Nov 14, 2016

for the record; java-wise your CodeStyle settings only specify the import-counts to start using .* imports both on 99

the rest is standard IntelliJ (also the import order differ for IntelliJ and Eclipse sadly :/ )

@jcassee
Copy link
Contributor

jcassee commented Nov 14, 2016

@tubbynl It is possible to instruct IntelliJ to use Eclipse's import order, I think.

@tubbynl
Copy link
Contributor

tubbynl commented Nov 14, 2016

The problem was the other way around (me using eclipse ordering imports differently)

tubbynl added a commit to tubbynl/mollie-api that referenced this issue Nov 15, 2016
@stil4m
Copy link
Owner Author

stil4m commented Jan 26, 2017

Does anybody have experience with this library or something similar.

I've been using elm-format extensively and I like the simplicity of 'I do not bother with the style, it just looks nice'.

@tubbynl
Copy link
Contributor

tubbynl commented Jan 26, 2017

nope,

but if you currently use elm-format i think that makes the most sense, i mostly think collaboration/less diffs is more important than some-person-s-code-style-preference :)

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

No branches or pull requests

3 participants