I need to say, since aleays I am using 160 chars and final everywhere by convention (Eclipse does that for me automatically), so this is pretty fine and familiar to me. Also, this is not just "some" code, this is an API spec, and I think it would be good that the API is "as final [in the sense of 'pretty clear'] as it can" if you know what I mean. ;-) Others chime in! We need more opinions! :-) -Markus From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of arjan tijms Sent: Samstag, 24. Februar 2018 16:32 To: jaxrs developer discussions Subject: Re: [jaxrs-dev] Checkstyle Settings / Code Format Conventions Hi, 160 chars IMHO is good to have as “exception”, meaning devs should normally strive to have less chars on a line (like 120, or even less), but occasionally using up to 169 when really needed is okay.160+ would almost always be too much. Final params everywhere is technically quite nice, but also very noisy and it’s by far not generally applied in other projects. Code with these *everywhere* feels slightly foreign. So I think it’s therefore better not to have these. Arjan Tijms
On Saturday, February 24, 2018, Christian Kaltepoth <christian@xxxxxxxxxxxx> wrote: Hi all, basically I was trying to address issue #587 which is about the 984 Checkstyle errors we are getting with the current configuration. My idea was to remove the rules which are violated _very_ often, because in this case they are most likely trying to enforce a coding style, which the original authors of the code didn't _want_ to follow. Therefore, it doesn't make any sense to enforce them, especially because they are hiding the real issues. First of all, the number of violations actually increases to 2,515 after updating the checkstyle-maven-plugin to the latest release, so actually this is the number we are starting from. The Checkstyle rules I adjusted/removedare the following: - Maximum line length of 120 characters (183 violations)
- I adjusted this threshold to 160 characters which fixes all violations. However, I agree that 160 feels too high. But there are some lines violating the 120 rule which are very difficult to format differently. See the long URLs in the Status enum for an example.
- Maybe we could just set it to 140 to remove _most_ violations? 140 may be OK considering today's screen resolutions.
- Method parameters should be final (406 violations)
- Although I like this pattern, it wasn't used for the API in the past. So I don't think that we should enforce it now. Especially as this change may not be binary compatible.
- Whitespace around "<" and ">" tokens (1847 violations)
- This rule is violated for almost all cases of generics usage like List<String>, so I guess it is safe to disable this one.
Let me know what you think. I'll create a pull request for the Checkstyle update at the weekend followed by individual pull requests for the config file adjustments if we agree on these changes. 2018-02-23 19:05 GMT+01:00 Markus KARG <markus@xxxxxxxxxxxxxxx>: Hello Fellow Committers, Christian noticed that the Checkstyle settings are different from the actual Code formatting, so many files fail this check. It would be good if we find a concensus about the actually wanted style and then either fix the files, or fix the checkstyle config. For example: Line lenght is set to 120 but some files are 160. Christian, maybe you can chime in here and propose the wanted changes in detail. :-) You comments please! :-) -Markus _______________________________________________ jaxrs-dev mailing list jaxrs-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
-- |