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

Code formatting standards #17

Closed
GraxCode opened this issue Jul 21, 2019 · 3 comments
Closed

Code formatting standards #17

GraxCode opened this issue Jul 21, 2019 · 3 comments

Comments

@GraxCode
Copy link
Contributor

CFR does have some small flaws at code formatting.

Examples that i found:

new line before imports / extends
space between ... in method parameters ("Object ... objects" instead of "Object... objects")
no new line after label definition (block0: for (...))

@leibnitz27
Copy link
Owner

A fair point, but styles are subjective - I mention in https://github.com/leibnitz27/cfr/blob/master/contributing.md - I'm not massively bothered about coding styles where there's any disagreement in the wild, given that (if you're particular about that sort of thing) it's trivial to run eg google-format-java over output (with your own personal preferences set).

Re labels - due to the nature of the beast, CFR is occasionally going to generate a lot more labels than you'd find in production code - I find condensing like that a readability bonus.

@leibnitz27
Copy link
Owner

leibnitz27 commented Jul 23, 2019

I've had a wander trying to actually find a single style guide that explicitly mention varargs ellipsis. Google java doesn't actually seem to care.

https://rules.sonarsource.com/java/RSPEC-3878 is the only one I found, and this has the extra explicit space!

I have to confess, I prefer it, for no particular reason, (though perhaps that's my c++ talking).

@leibnitz27
Copy link
Owner

I'm going to close this - it's a minor subjective stylistic issue which can easily be patched up with a formatting tool. While this may seem a little aribtrary given #167 , that is more of an intrustive change, which is harder for a trivial style checker to apply.

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

No branches or pull requests

2 participants