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