> On Oct 26, 2015, at 22:34, Nigel Magnay <[email protected]> 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 > <https://groups.google.com/d/topic/jenkinsci-dev/8fjvXGYbFJ4/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to > [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83SVJT7d6TN07Xh_obV94Y09n84Mtb8T6u6gyZAZ%2BEHS%3Dw%40mail.gmail.com > > <https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83SVJT7d6TN07Xh_obV94Y09n84Mtb8T6u6gyZAZ%2BEHS%3Dw%40mail.gmail.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <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/62F9BBBD-3241-419D-A720-61C034D269ED%40gmail.com. For more options, visit https://groups.google.com/d/optout.
