[proposal] coding style for core (jenkins 2.0?)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
52 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[proposal] coding style for core (jenkins 2.0?)

Kanstantsin Shautsou-2
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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] coding style for core (jenkins 2.0?)

Mark Waite-2
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 <[hidden email]> 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 [hidden email].
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.

--
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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] coding style for core (jenkins 2.0?)

Arnaud Héritier
In reply to this post by Kanstantsin Shautsou-2
+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 <[hidden email]> 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 [hidden email].
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.



--
-----
Arnaud Héritier
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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] coding style for core (jenkins 2.0?)

nicolas de loof-2
I have to admit gofmt make it far simpler to contribute to go projects as nobody has to discuss code formatting rules. Enforcing the expected format is applied everywhere make it simpler. So +1 on applying such a formater to all code and apply automatically as part of PR review to ensure it has been followed.

That being said, I sometime get red eyes looking at Jenkins code base but this is not due to line indent or missing spaces before a bracket, but due to hundred @deprecated and obsolete libs being used :P

2015-10-26 16:32 GMT+01:00 Arnaud Héritier <[hidden email]>:
+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 <[hidden email]> 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 [hidden email].
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.



--
-----
Arnaud Héritier
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 [hidden email].
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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJz%3DrXfu_cWNX_yfY8Ds0iNcgWFBtC4211j_QOFb0HHRu-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] coding style for core (jenkins 2.0?)

Kanstantsin Shautsou-2
Example of sonar + github automatic integration https://github.com/jenkinsci/envinject-plugin/pull/73#issuecomment-143682168 . Such checks allowed not bother ourself with boring commenting on github-plugin/github-pullrequest-plugin

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/d80537f2-d4de-4628-bb8a-4aa51322a424%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] coding style for core (jenkins 2.0?)

Kirill Merkushev
In reply to this post by Kanstantsin Shautsou-2
example moderate checkstyle:
https://gist.github.com/lanwen/96feea5efdbb4ee86cad


понедельник, 26 октября 2015 г., 18:24:19 UTC+3 пользователь Kanstantsin Shautsou написал:
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/0e7adfc3-06c6-4445-acc4-de5477657498%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] coding style for core (jenkins 2.0?)

Jesse Glick-4
In reply to this post by Kanstantsin Shautsou-2
-0 I guess. I have never had any problem understanding anyone else’s
code because of their formatting choices, weird or not. It is the
logic that is the problem. Enforced code style, like discussions about
code style, has just been a distraction and waste of time in my
experience.

If you are going to set a coding standard, it must be enforced
mechanically by a standard Maven build, so contributors can fall into
line on their own time, without bothering reviewers.

And I think the “diff wall” is potentially a drag for years to come. I
still look through line-by-line history for the reasoning behind
historical decisions, sometimes going into imported Subversion history
(which alas is sometimes where the investigation ends, due to
Subversion’s poor merge tracking). Every time a line is changed for no
good reason, understanding the subtle and undertested assumptions in
Jenkins code becomes a little bit harder.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1RugOSs7i%2BRoE8xjn1yi4%3Dcq%3D39WqtERBy-V%3DeerZdtg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] coding style for core (jenkins 2.0?)

Nigel Magnay
In reply to this post by Mark Waite-2
-1.

Automated code formatting in general makes a total pigs breakfast of fluent APIs. 

I find it hard to get inside the heads of people that love to spend time worrying about how many spaces come before and after the brackets in an "if" statement. Sure, have some guidelines, make sure you don't do things like hungarian notation that add no value - but most arguments I've seen boil down to an 'appeal to authority'.


On Mon, Oct 26, 2015 at 3:31 PM, Mark Waite <[hidden email]> wrote:
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 <[hidden email]> 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 [hidden email].
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.

--
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 [hidden email].
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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83TEHkfG%2BiZQLj6QAQwm5N0FU3n9pONb4g%3DybfNrDfApoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] coding style for core (jenkins 2.0?)

Kanstantsin Shautsou-2
In reply to this post by Jesse Glick-4


On Monday, October 26, 2015 at 7:01:07 PM UTC+3, Jesse Glick wrote:
-0 I guess. I have never had any problem understanding anyone else’s
code because of their formatting choices, weird or not. It is the
logic that is the problem. Enforced code style, like discussions about
code style, has just been a distraction and waste of time in my
experience.
Because you know very well this code base and you do your own styling that mistakenly copied by other newcomers and ends in mess of styles. 
That's why automation check should save time and enhance quality. 

If you are going to set a coding standard, it must be enforced
mechanically by a standard Maven build, so contributors can fall into
line on their own time, without bothering reviewers.
See example of automated check https://github.com/jenkinsci/envinject-plugin/pull/73#discussion_r40529580 . I think maven checkstyle can't check diffs, so without reformatting all code this wouldn't work. That's why i proposed "apply for future changes" because new APIs getting old style randomness. 

And I think the “diff wall” is potentially a drag for years to come. I
still look through line-by-line history for the reasoning behind
historical decisions, sometimes going into imported Subversion history
(which alas is sometimes where the investigation ends, due to
Subversion’s poor merge tracking). Every time a line is changed for no
good reason, understanding the subtle and undertested assumptions in
Jenkins code becomes a little bit harder.
Strange that unsquashed PRs with 20 'fix typo' commits is not a problem.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a453bdf4-8d4c-4702-9231-ac2ac6bc18d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] coding style for core (jenkins 2.0?)

Jesse Glick-4
On Mon, Oct 26, 2015 at 12:44 PM, Kanstantsin Shautsou
<[hidden email]> wrote:
>> I have never had any problem understanding anyone else’s code because of their formatting choices
>
> Because you know very well this code base

How do you think I got to know (some of) the code base in the first
place? By fixing problems, and digging through history to see when and
why those problems were introduced.

> See example of automated check
> https://github.com/jenkinsci/envinject-plugin/pull/73#discussion_r40529580

Interesting, though sounds very painful to contribute to since you
must first file the PR, then go back and wait for the bot to ask you
to reformat. Much better to be able to repeatedly run a style checker
tool locally before committing. Not sure if there is any such tool
which is able to automatically skip lines already present in the
`master` branch or something like that.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2W0x5Q2NTAaZMQz4G5nvP9-6XTLKbTxP9VkFSvQML%2BvA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] coding style for core (jenkins 2.0?)

Kanstantsin Shautsou-2
On Oct 26, 2015, at 21:01, Jesse Glick <[hidden email]> wrote:

On Mon, Oct 26, 2015 at 12:44 PM, Kanstantsin Shautsou
<[hidden email]> wrote:
I have never had any problem understanding anyone else’s code because of their formatting choices

Because you know very well this code base

How do you think I got to know (some of) the code base in the first
place? By fixing problems, and digging through history to see when and
why those problems were introduced.
I do the same, but last year unsquashed+normal PRs + more random made everything worth.

See example of automated check
https://github.com/jenkinsci/envinject-plugin/pull/73#discussion_r40529580

Interesting, though sounds very painful to contribute to since you
must first file the PR, then go back and wait for the bot to ask you
to reformat. Much better to be able to repeatedly run a style checker
tool locally before committing. Not sure if there is any such tool
which is able to automatically skip lines already present in the
`master` branch or something like that.
- IDEA autoformat can be applied to selected block of code https://www.jetbrains.com/idea/help/code-style-and-formatting.html (not exactly what you want, but sometimes helps)
- I don’t know any PRs that was accepted without changes. Default formatted code usually fits into the most conservative styling.
- Rules can exist in checkstyle and be applied by any tool when it will supported.
- Logically only during PR you can do all changes because after, `diff wall` wouldn’t allow to touch committed code. It should not be so difficult to fixup commits.
- The same pain as Update Centre filtering for plugins that doesn’t have link to doc. You should release plugin, wait for metadata updates, debug all chain and only then understand what happened. But such not obvious flow was accepted for all 1k plugins. It even can’t say to email that something wrong.
- Local run will require huge amount of time and people always forgetting to run checks. PR is the only place where we can point to such things.
- Also comments in PR can be ignored ;)


--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/8fjvXGYbFJ4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2W0x5Q2NTAaZMQz4G5nvP9-6XTLKbTxP9VkFSvQML%2BvA%40mail.gmail.com.
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/D4B215A1-C73A-44A1-A04E-D9195C1F9325%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] coding style for core (jenkins 2.0?)

stephenconnolly
I think that the best way to do this is via an experiment in plugins... If we get a critical mass of plugins adopting a mostly similar set of rules then and only then should we think about applying them to core

On Monday 26 October 2015, Kanstantsin Shautsou <[hidden email]> wrote:
On Oct 26, 2015, at 21:01, Jesse Glick <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;jglick@cloudbees.com&#39;);" target="_blank">jglick@...> wrote:

On Mon, Oct 26, 2015 at 12:44 PM, Kanstantsin Shautsou
<<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;kanstantsin.sha@gmail.com&#39;);" target="_blank">kanstantsin.sha@...> wrote:
I have never had any problem understanding anyone else’s code because of their formatting choices

Because you know very well this code base

How do you think I got to know (some of) the code base in the first
place? By fixing problems, and digging through history to see when and
why those problems were introduced.
I do the same, but last year unsquashed+normal PRs + more random made everything worth.

See example of automated check
https://github.com/jenkinsci/envinject-plugin/pull/73#discussion_r40529580

Interesting, though sounds very painful to contribute to since you
must first file the PR, then go back and wait for the bot to ask you
to reformat. Much better to be able to repeatedly run a style checker
tool locally before committing. Not sure if there is any such tool
which is able to automatically skip lines already present in the
`master` branch or something like that.
- IDEA autoformat can be applied to selected block of code https://www.jetbrains.com/idea/help/code-style-and-formatting.html (not exactly what you want, but sometimes helps)
- I don’t know any PRs that was accepted without changes. Default formatted code usually fits into the most conservative styling.
- Rules can exist in checkstyle and be applied by any tool when it will supported.
- Logically only during PR you can do all changes because after, `diff wall` wouldn’t allow to touch committed code. It should not be so difficult to fixup commits.
- The same pain as Update Centre filtering for plugins that doesn’t have link to doc. You should release plugin, wait for metadata updates, debug all chain and only then understand what happened. But such not obvious flow was accepted for all 1k plugins. It even can’t say to email that something wrong.
- Local run will require huge amount of time and people always forgetting to run checks. PR is the only place where we can point to such things.
- Also comments in PR can be ignored ;)


--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/8fjvXGYbFJ4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;jenkinsci-dev%2Bunsubscribe@googlegroups.com&#39;);" target="_blank">jenkinsci-dev+unsubscribe@....
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2W0x5Q2NTAaZMQz4G5nvP9-6XTLKbTxP9VkFSvQML%2BvA%40mail.gmail.com.
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 <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;jenkinsci-dev%2Bunsubscribe@googlegroups.com&#39;);" target="_blank">jenkinsci-dev+unsubscribe@....
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/D4B215A1-C73A-44A1-A04E-D9195C1F9325%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
Sent from my phone

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMx93kpHmwJyjLmBe-pmKTzC5haH%3DbGrca-3UqZMfegiug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] coding style for core (jenkins 2.0?)

Nigel Magnay
> That's why automation check should save time and enhance quality. 

It only “enhances quality” if you agree with the idea that a set of arbitrary syntactic checkstyle rules spat out by tooling represents “quality” rather than merely “conformity". The truth is ‘quality’ is rather hard to measure - particularly in an automated way - and we’re left with the old management adage that those who can’t measure what they want, end up wanting what they can measure. This is why poor managers often clock-watch and obsess as to whether their staff turn up in a suit & tie or not.

e.g: JDK7 has, according to SonarQube, over 100,000 “Major, Critical or Blocking” issues.  IMO, that says much more about the value of SonarQube than the quality of the JDK (which, incidentally, has an almost entirely uniform code style).

If a PR ‘fails’ from a bunch of checkstyle rules, you’re effectively asking the original author to expend additional effort on ‘conformity’. The time cost delivers zero end-user value, and meanwhile you’re piling up inventory — risking yet more rework in the event of a merge conflict, or the author simply giving up (after all, he’s given this code to you for free). Software development these days claims to be all about being agile - and yet the above is practically the ‘lean’ textbook example of waste.

Having a clean history - not having to dig through commits that did nothing to change the semantics (merely dicked about with the whitespace) - turns out to be far more important now that tooling has moved to the state when histories become actually useful. Which is why ideas from old-school coding standards (like making variable names line up horizontally  - which actually really does improve readability) are basically dropped (because this makes a single character change potentially ripple to several unrelated lines, polluting the history and potentially making merges harder).


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83SVJT7d6TN07Xh_obV94Y09n84Mtb8T6u6gyZAZ%2BEHS%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] coding style for core (jenkins 2.0?)

Kanstantsin Shautsou-2
In reply to this post by stephenconnolly
That leads to situation that people hacking things in plugins instead of extending/fixing core. Plugins usually copy-pasting examples from core (personally i copied as is jelly hacks and protected methods like getDefaultParamaeters from JobMixin) and that situation goes into loop. Imho core should be example for all project and not vice versa.

On Oct 26, 2015, at 22:20, Stephen Connolly <[hidden email]> wrote:

I think that the best way to do this is via an experiment in plugins... If we get a critical mass of plugins adopting a mostly similar set of rules then and only then should we think about applying them to core

On Monday 26 October 2015, Kanstantsin Shautsou <[hidden email]> wrote:
On Oct 26, 2015, at 21:01, Jesse Glick <<a href="javascript:_e(%7B%7D,'cvml','jglick@cloudbees.com');" target="_blank" class="">jglick@...> wrote:

On Mon, Oct 26, 2015 at 12:44 PM, Kanstantsin Shautsou
<<a href="javascript:_e(%7B%7D,'cvml','kanstantsin.sha@gmail.com');" target="_blank" class="">kanstantsin.sha@...> wrote:
I have never had any problem understanding anyone else’s code because of their formatting choices

Because you know very well this code base

How do you think I got to know (some of) the code base in the first
place? By fixing problems, and digging through history to see when and
why those problems were introduced.
I do the same, but last year unsquashed+normal PRs + more random made everything worth.

See example of automated check
https://github.com/jenkinsci/envinject-plugin/pull/73#discussion_r40529580

Interesting, though sounds very painful to contribute to since you
must first file the PR, then go back and wait for the bot to ask you
to reformat. Much better to be able to repeatedly run a style checker
tool locally before committing. Not sure if there is any such tool
which is able to automatically skip lines already present in the
`master` branch or something like that.
- IDEA autoformat can be applied to selected block of code https://www.jetbrains.com/idea/help/code-style-and-formatting.html (not exactly what you want, but sometimes helps)
- I don’t know any PRs that was accepted without changes. Default formatted code usually fits into the most conservative styling.
- Rules can exist in checkstyle and be applied by any tool when it will supported.
- Logically only during PR you can do all changes because after, `diff wall` wouldn’t allow to touch committed code. It should not be so difficult to fixup commits.
- The same pain as Update Centre filtering for plugins that doesn’t have link to doc. You should release plugin, wait for metadata updates, debug all chain and only then understand what happened. But such not obvious flow was accepted for all 1k plugins. It even can’t say to email that something wrong.
- Local run will require huge amount of time and people always forgetting to run checks. PR is the only place where we can point to such things.
- Also comments in PR can be ignored ;)


--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/8fjvXGYbFJ4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to <a href="javascript:_e(%7B%7D,'cvml','jenkinsci-dev%2Bunsubscribe@googlegroups.com');" target="_blank" class="">jenkinsci-dev+unsubscribe@....
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2W0x5Q2NTAaZMQz4G5nvP9-6XTLKbTxP9VkFSvQML%2BvA%40mail.gmail.com.
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 <a href="javascript:_e(%7B%7D,'cvml','jenkinsci-dev%2Bunsubscribe@googlegroups.com');" target="_blank" class="">jenkinsci-dev+unsubscribe@....
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/D4B215A1-C73A-44A1-A04E-D9195C1F9325%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
Sent from my phone

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/8fjvXGYbFJ4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMx93kpHmwJyjLmBe-pmKTzC5haH%3DbGrca-3UqZMfegiug%40mail.gmail.com.
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/264DD823-92E1-4C43-98E4-AFD73FDE44AF%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] coding style for core (jenkins 2.0?)

stephenconnolly
In reply to this post by Nigel Magnay
On 26 October 2015 at 19:34, Nigel Magnay <[hidden email]> wrote:

>> That's why automation check should save time and enhance quality.
>
> It only “enhances quality” if you agree with the idea that a set of
> arbitrary syntactic checkstyle rules spat out by tooling represents
> “quality” rather than merely “conformity". The truth is ‘quality’ is rather
> hard to measure - particularly in an automated way - and we’re left with the
> old management adage that those who can’t measure what they want, end up
> wanting what they can measure. This is why poor managers often clock-watch
> and obsess as to whether their staff turn up in a suit & tie or not.
>
> e.g: JDK7 has, according to SonarQube, over 100,000 “Major, Critical or
> Blocking” issues.  IMO, that says much more about the value of SonarQube
> than the quality of the JDK (which, incidentally, has an almost entirely
> uniform code style).
>
> If a PR ‘fails’ from a bunch of checkstyle rules, you’re effectively asking
> the original author to expend additional effort on ‘conformity’. The time
> cost delivers zero end-user value, and meanwhile you’re piling up inventory
> — risking yet more rework in the event of a merge conflict, or the author
> simply giving up (after all, he’s given this code to you for free). Software
> development these days claims to be all about being agile - and yet the
> above is practically the ‘lean’ textbook example of waste.
>
> Having a clean history - not having to dig through commits that did nothing
> to change the semantics (merely dicked about with the whitespace) - turns
> out to be far more important now that tooling has moved to the state when
> histories become actually useful. Which is why ideas from old-school coding
> standards (like making variable names line up horizontally  - which actually
> really does improve readability) are basically dropped (because this makes a
> single character change potentially ripple to several unrelated lines,
> polluting the history and potentially making merges harder).

And `git blame --first-parent -w` becomes much more important when
tracking and tracing changes...

Once you start down the `--first-parent` route you then realize that
all this fussing over squashing commits is a waste of time, there is
no need to squash commits... the only need is to fix the GitHub UI so
that people who are not CLI ninjas can gain the benefit...

Please everyone start pestering GitHub to add the support for
--first-parent and -w on the git blame and git log web pages... if
it's just my request sitting in their in box it may take a while... if
everyone asks for it... well they should fix it faster.

>
>
> --
> 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 [hidden email].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83SVJT7d6TN07Xh_obV94Y09n84Mtb8T6u6gyZAZ%2BEHS%3Dw%40mail.gmail.com.
>
> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMzHC%3D5XoSwFwy5YfLhxsZX%3Djo%2BWPK-zdGb9zk5uvq91Gw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] coding style for core (jenkins 2.0?)

Kanstantsin Shautsou-2
In reply to this post by Nigel Magnay

On Oct 26, 2015, at 22:34, Nigel Magnay <[hidden email]> wrote:

> That's why automation check should save time and enhance quality. 

It only “enhances quality” if you agree with the idea that a set of arbitrary syntactic checkstyle rules spat out by tooling represents “quality” rather than merely “conformity". The truth is ‘quality’ is rather hard to measure - particularly in an automated way - and we’re left with the old management adage that those who can’t measure what they want, end up wanting what they can measure. This is why poor managers often clock-watch and obsess as to whether their staff turn up in a suit & tie or not.
Sorry, i’m not a master in English. I sure that such things will finally end with quality (FB analyser attempt was successful?).

e.g: JDK7 has, according to SonarQube, over 100,000 “Major, Critical or Blocking” issues.  IMO, that says much more about the value of SonarQube than the quality of the JDK (which, incidentally, has an almost entirely uniform code style).
Feel free to investigate why they have so many “issues”, whether they tuned default profiles and etc.

If a PR ‘fails’ from a bunch of checkstyle rules, you’re effectively asking the original author to expend additional effort on ‘conformity’.
This is consistency and readability.
The time cost delivers zero end-user value, and meanwhile you’re piling up inventory — risking yet more rework in the event of a merge conflict, or the author simply giving up (after all, he’s given this code to you for free).
I will repeat answer that i said personally to you some time ago. When i see that contributor is newbie and can’t solve something i’m picking his changes with rework. That’s what Oleg do in core when PR author can’t do some changes and disappear. Note that happens always and not because of styling changes.  If you can’t make such primitive thing, then it indicator that you may fail in code.
 Software development these days claims to be all about being agile - and yet the above is practically the ‘lean’ textbook example of waste.
I know your methodology: don’t use static analysers, don’t do changes with PRs, don’t fix problems in upstream, do hacks, no tests.

Having a clean history - not having to dig through commits that did nothing to change the semantics (merely dicked about with the whitespace) - turns out to be far more important now that tooling has moved to the state when histories become actually useful. Which is why ideas from old-school coding standards (like making variable names line up horizontally  - which actually really does improve readability) are basically dropped (because this makes a single character change potentially ripple to several unrelated lines, polluting the history and potentially making merges harder).
JDK code is very well documented and readable.
Interesting, how do you dig core history with not squashed PRs today (but it parallel thread).



--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/8fjvXGYbFJ4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83SVJT7d6TN07Xh_obV94Y09n84Mtb8T6u6gyZAZ%2BEHS%3Dw%40mail.gmail.com.
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/62F9BBBD-3241-419D-A720-61C034D269ED%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] coding style for core (jenkins 2.0?)

Mark Waite-2
In reply to this post by stephenconnolly


On Mon, Oct 26, 2015 at 1:21 PM Stephen Connolly <[hidden email]> wrote:
I think that the best way to do this is via an experiment in plugins... If we get a critical mass of plugins adopting a mostly similar set of rules then and only then should we think about applying them to core


I volunteer to experiment with a branch of the git client plugin as a first candidate.  I'd limit the formatting to newer files and files that I've created myself so that the "diff wall" won't be as difficult.  Older files with wildly divergent formatting styles will remain that way as part of the first phase of the experiment.
 
That will give a chance to evaluate Nigel's concern for the impact on fluent API calls (since there are several fluent interfaces in the git client plugin).

Mark Waite

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHbxMpH1RTwRMiYuDj71pVi1fTSsUFbHTpEh%3DeYGMNezg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] coding style for core (jenkins 2.0?)

Nigel Magnay
You don't need to trial automatic code formatting it to know it's going to produce a terrible result.

Trivial example 101. Which is the more easily parseable to the human eye?

periodFormatter = new PeriodFormatterBuilder()
                .printZeroAlways()
                .appendDays().appendSuffix("d ")
                .appendHours().appendSuffix("h ")
                .appendMinutes().appendSuffix("m")
                .toFormatter();

or

periodFormatter = new PeriodFormatterBuilder().printZeroAlways().appendDays()
                          .appendSuffix("d ").appendHours().appendSuffix("h ")
                          .appendMinutes().appendSuffix("m").toFormatter();


I know which I'd rather be faced with when maintaining code.

On Mon, Oct 26, 2015 at 9:55 PM, Mark Waite <[hidden email]> wrote:


On Mon, Oct 26, 2015 at 1:21 PM Stephen Connolly <[hidden email]> wrote:
I think that the best way to do this is via an experiment in plugins... If we get a critical mass of plugins adopting a mostly similar set of rules then and only then should we think about applying them to core


I volunteer to experiment with a branch of the git client plugin as a first candidate.  I'd limit the formatting to newer files and files that I've created myself so that the "diff wall" won't be as difficult.  Older files with wildly divergent formatting styles will remain that way as part of the first phase of the experiment.
 
That will give a chance to evaluate Nigel's concern for the impact on fluent API calls (since there are several fluent interfaces in the git client plugin).

Mark Waite

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHbxMpH1RTwRMiYuDj71pVi1fTSsUFbHTpEh%3DeYGMNezg%40mail.gmail.com.

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83TJO306gyDmEt_fVx88XVZK54gK7O3JhxqSFzDgLrn6Xg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] coding style for core (jenkins 2.0?)

Kanstantsin Shautsou-2
Both will be acceptable in styling. That lines are about logic that analysing tool can’t know.
or 
periodFormatter = new PeriodFormatterBuilder().printZeroAlways().appendDays().appendSuffix("d ").appendHours().appendSuffix("h ")                        .appendMinutes().appendSuffix("m").toFormatter();
<——— scroll ——---->

P.S. Am i alone who receives emails from Nigel with small blue font?
On Oct 27, 2015, at 01:02, Nigel Magnay <[hidden email]> wrote:

You don't need to trial automatic code formatting it to know it's going to produce a terrible result.

Trivial example 101. Which is the more easily parseable to the human eye?

periodFormatter = new PeriodFormatterBuilder()
                .printZeroAlways()
                .appendDays().appendSuffix("d ")
                .appendHours().appendSuffix("h ")
                .appendMinutes().appendSuffix("m")
                .toFormatter();

or

periodFormatter = new PeriodFormatterBuilder().printZeroAlways().appendDays()
                          .appendSuffix("d ").appendHours().appendSuffix("h ")
                          .appendMinutes().appendSuffix("m").toFormatter();


I know which I'd rather be faced with when maintaining code.

On Mon, Oct 26, 2015 at 9:55 PM, Mark Waite <[hidden email]> wrote:


On Mon, Oct 26, 2015 at 1:21 PM Stephen Connolly <[hidden email]> wrote:
I think that the best way to do this is via an experiment in plugins... If we get a critical mass of plugins adopting a mostly similar set of rules then and only then should we think about applying them to core


I volunteer to experiment with a branch of the git client plugin as a first candidate.  I'd limit the formatting to newer files and files that I've created myself so that the "diff wall" won't be as difficult.  Older files with wildly divergent formatting styles will remain that way as part of the first phase of the experiment.
 
That will give a chance to evaluate Nigel's concern for the impact on fluent API calls (since there are several fluent interfaces in the git client plugin).

Mark Waite

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHbxMpH1RTwRMiYuDj71pVi1fTSsUFbHTpEh%3DeYGMNezg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/8fjvXGYbFJ4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83TJO306gyDmEt_fVx88XVZK54gK7O3JhxqSFzDgLrn6Xg%40mail.gmail.com.
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/FF20FA21-AF8B-46EE-B8DF-10A9DEBA8921%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] coding style for core (jenkins 2.0?)

Nigel Magnay

Both will be acceptable in styling. That lines are about logic that analysing tool can’t know.

​Bingo.

"Automatic code formatters"​ don't know the semantics of what they're formatting, so you apply them end up with gigantic concatented lines (sometimes split to 80 columns, as if we're still producing punched cards). 

This is clearly worse than the "unformatted" case - where the author has carefully aided the maintainer by splitting on semantically distinct sections.

By all means, have some IDE defaults that can be picked up (e.g: spaces or tabs, tabstops, whether to use '*' imports or not), but auto-code formatters are evil.
 
or 
periodFormatter = new PeriodFormatterBuilder().printZeroAlways().appendDays().appendSuffix("d ").appendHours().appendSuffix("h ")                        .appendMinutes().appendSuffix("m").toFormatter();
<——— scroll ——---->

P.S. Am i alone who receives emails from Nigel with small blue font?


On Oct 27, 2015, at 01:02, Nigel Magnay <[hidden email]> wrote:

You don't need to trial automatic code formatting it to know it's going to produce a terrible result.

Trivial example 101. Which is the more easily parseable to the human eye?

periodFormatter = new PeriodFormatterBuilder()
                .printZeroAlways()
                .appendDays().appendSuffix("d ")
                .appendHours().appendSuffix("h ")
                .appendMinutes().appendSuffix("m")
                .toFormatter();

or

periodFormatter = new PeriodFormatterBuilder().printZeroAlways().appendDays()
                          .appendSuffix("d ").appendHours().appendSuffix("h ")
                          .appendMinutes().appendSuffix("m").toFormatter();


I know which I'd rather be faced with when maintaining code.

On Mon, Oct 26, 2015 at 9:55 PM, Mark Waite <[hidden email]> wrote:


On Mon, Oct 26, 2015 at 1:21 PM Stephen Connolly <[hidden email]> wrote:
I think that the best way to do this is via an experiment in plugins... If we get a critical mass of plugins adopting a mostly similar set of rules then and only then should we think about applying them to core


I volunteer to experiment with a branch of the git client plugin as a first candidate.  I'd limit the formatting to newer files and files that I've created myself so that the "diff wall" won't be as difficult.  Older files with wildly divergent formatting styles will remain that way as part of the first phase of the experiment.
 
That will give a chance to evaluate Nigel's concern for the impact on fluent API calls (since there are several fluent interfaces in the git client plugin).

Mark Waite

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHbxMpH1RTwRMiYuDj71pVi1fTSsUFbHTpEh%3DeYGMNezg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/8fjvXGYbFJ4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83TJO306gyDmEt_fVx88XVZK54gK7O3JhxqSFzDgLrn6Xg%40mail.gmail.com.
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/FF20FA21-AF8B-46EE-B8DF-10A9DEBA8921%40gmail.com.

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83Q73VNYKWJWX2iP_0QA9z%3Dy%3DpbDPBHMy0tQJ%2BX6Ley1Ng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
123