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.
For more options, visit https://groups.google.com/d/optout.
