+1 I'm "praying" for documented coding rules in Jenkins for so many years.
I don't want to enforce anything but at least to have them to:
* allow contributors to follow them if they can/want (and they should like
to follow them to propose readable PRs which are easily accepted)
* allow maintainers to reformat code of contributions without asking
anything
If the IDE configuration if provided at least for eclipse and IJ it will
cover a large part of the developers and it won't be a nightmare each time
you are opening a file and for a simple change you need to guess how the
code is formatted.
On Mon, Oct 26, 2015 at 4:24 PM, Kanstantsin Shautsou <
kanstantsin....@gmail.com> wrote:
> Every time i open core code to fix something my eyes become red because of
> unreadable code. The same i heard many times as bad argument for jenkins on
> conferences.
> This doesn't cause any backward compatibility issues and cherry-pick
> shouldn't be a problem for LTS because near 2.0 LTS i think will be handled
> in different way.
>
> My proposal is to chose some coding style and follow it in future.
> "Any code style" rule today led to hardly readable code:
> - Mess of spaces vs tabs: bad diffs
> - Annotation mess: when i'm reading code i expect access modifiers to be
> as keywords on start of line. Project may have different annotations and
> eyes can't jump to everybody known keywords.
> - Line width: scrolling code extremely inconvenient (imho even 120
> sometimes not enough, but producing >150 enforces scrolling).
> - Random spaces around if/for, looks like some developers coded from
> calculators. All IDEs can auto format code (i also lasy to type spaces in
> right places, but i usually auto-reformat before commits).
> - {} braces for if/for bodies: enough to make bug one time to understand.
>
> Many experienced developers already added rules in their plugins and imho
> for core something neutral can be chosen. Imho oracle coding style is the
> most used and can be adopted. For example Stephen C. already has documented
> variant that mostly matches Oracle code style.
> - Code will be more attractive for newcomers.
> - Will allow automate checks.
> WDYT?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/06b5602c-2f6a-4cbe-91ab-bfdb23f3f2c4%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/06b5602c-2f6a-4cbe-91ab-bfdb23f3f2c4%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-9pt%3DngEBMHTHSiO1nR6SK6rB8ycP2-HsgQJBXt%2B1EmHA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
