I'm a proponent of automated code formatting. If we're describing a coding style in the "CONTRIBUTING" file, why not let a tool enforce that coding style on each compile of the code?
Automated code formatting has the down-side that there is a one-time "diff wall" which is created when the automated formatting is introduced. I think the time savings later in maintainers not having to enforce the coding style by inspection (read and remind about white space changes, complain about missing braces, etc.) easily repays the cost of the "diff wall". Mark Waite On Mon, Oct 26, 2015 at 9:24 AM Kanstantsin Shautsou < [email protected]> 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 [email protected]. > 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. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtG6XBYLGo8%3DE1dFEXMMY6ivV4qHzm%3DQhW3_pNOrm1JcxA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
