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