--
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-de...@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.
--
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-de...@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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-9pt%3DngEBMHTHSiO1nR6SK6rB8ycP2-HsgQJBXt%2B1EmHA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtG6XBYLGo8%3DE1dFEXMMY6ivV4qHzm%3DQhW3_pNOrm1JcxA%40mail.gmail.com.
-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.
On Oct 26, 2015, at 21:01, Jesse Glick <jgl...@cloudbees.com> wrote:On Mon, Oct 26, 2015 at 12:44 PM, Kanstantsin Shautsou
<kanstan...@gmail.com> 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 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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2W0x5Q2NTAaZMQz4G5nvP9-6XTLKbTxP9VkFSvQML%2BvA%40mail.gmail.com.
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-de...@googlegroups.com.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMx93kpHmwJyjLmBe-pmKTzC5haH%3DbGrca-3UqZMfegiug%40mail.gmail.com.
On Oct 26, 2015, at 22:34, Nigel Magnay <nigel....@gmail.com> 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).
--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83SVJT7d6TN07Xh_obV94Y09n84Mtb8T6u6gyZAZ%2BEHS%3Dw%40mail.gmail.com.
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
--
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-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHbxMpH1RTwRMiYuDj71pVi1fTSsUFbHTpEh%3DeYGMNezg%40mail.gmail.com.
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83TJO306gyDmEt_fVx88XVZK54gK7O3JhxqSFzDgLrn6Xg%40mail.gmail.com.
Both will be acceptable in styling. That lines are about logic that analysing tool can’t know.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/FF20FA21-AF8B-46EE-B8DF-10A9DEBA8921%40gmail.com.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83Q73VNYKWJWX2iP_0QA9z%3Dy%3DpbDPBHMy0tQJ%2BX6Ley1Ng%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHxPmXuDzResjM2PZx04p94khB55O2n4auEoUf9wdY_sA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/D7807A3C-0F85-4CD8-A1DB-6E907B2CCA90%40fortysix.ch.
// @formatter:off
periodFormatter = new PeriodFormatterBuilder() .printZeroAlways() .appendDays().appendSuffix("d ") .appendHours().appendSuffix("h ") .appendMinutes().appendSuffix("m") .toFormatter();
// @formatter:on
You describe things with a very broad brush. Earlier you extrapolated from a request to format code into a comment about management measuring the irrelevant. Now you're declaring that the benefits my team of 10+ (using extreme programming as our methodology, pair programming everything, test driven development, etc.) found from automated code formatting over multiple years of working together should be ignored because "auto-code formatters are evil". The sole specific example you offer is that calls to fluent API's aren't we'll preserved by automatic code formatters.Can you offer other concrete examples of cases (preferably in the existing code) where an automatic formatter will have a serious negative impact?
When I look at the git-client-plugin source code, I find relatively few cases of the fluent calls being badly damaged by an automatic formatter. There are many fluent calls, but most of them will be untouched by an automatic formatter.There is a trade-off between the simplicity of automatically maintained code format (with occasional sub-optimal formatting as a result of the automation) and the work I must do on every pull request to not make code formatting consistency worse in the two plugins I maintain.
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/286490ff-5ad8-49a5-af41-da2bf0a7ff3b%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/0B1AB425-AD96-404C-8857-83DD2D9837C8%40gmail.com.
Am 02.11.2015 um 14:54 schrieb Kanstantsin Shautsou <kanstan...@gmail.com>:<sorry-for-offtopic>http://techbeacon.com/zombie-code-when-maintainability-goes-out-window
</sorry-for-offtopic>
--
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-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9063c95b-b8b2-42b9-87e5-a63fd0c8ce06%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1595bf88-3802-4f7d-a691-e2d2b149947a%40googlegroups.com.
Well, yeah, but I guess the thing is:
> "We *try* to *loosely* follow"
Might have left a lot (too much?) of room for debate :).
--
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-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/d0a010d2-54c6-4b24-a1d5-76aa4692c3fe%40googlegroups.com.
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6jf9JYzrezqRLobmyz13qmyxUGm5XjxPrdD8zcxxC_CQ%40mail.gmail.com.
JFYI, latest checkstyle version (with latest maven-checkstyle) supports more flexible configurations like allow inline if’s without brackets.
Different types of inline annotations (configuration 1.3 DTD). http://checkstyle.sourceforge.net/releasenotes.html
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/B95A8E77-94F7-4E9D-8253-08CF6971019B%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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2QF7BgnazAaf6w2p_N2Fcu5bGoGgvSFbQUo9DSdsvpxQ%40mail.gmail.com.
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/33067c26-6b0a-482c-9523-a723e0518adb%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8326ef25-1a2e-47c2-b00e-3f7053a7a49f%40googlegroups.com.
On Dec 21, 2015, at 13:22, Raquel Pau Fernández <raqu...@gmail.com> wrote:1) Ok, no problem, but I think that code style is really related with static analysis tools, because these tool will be able to validate or fix your code style.
2) I understand that you need to validate exactly what are your conventions before setting them as part of your project. After that, your trust in the tool like you trust in code editors.
3) I have readed the suggested PR you send me, but I can't completely understand yet. XStream, as far as I know, uses the readResolve when it is dealing with the ObjectOutputStream and according the official Java documentation, just Serialiable and Externalizable elements can use readResolve. So, I don't understand why those classes that contain readResolve do not implement Serializable. Anyway, these are the Jenkins conventions/code style :-) and it is what I think that should be defined in somewhere.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/abf1c0d0-f627-42af-8409-335ff0888831%40googlegroups.com.
XStream does not require use of the `Serializable` marker interface.
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?