+1 for having a consistent style if that will help produce clear and meaningful diffs +1 if that style can be implemented in eclipse's code formatter, so I can use contrl-shift-f to format my code according to the standard
+0 on what style we use, and whether we use tabs or spaces +1 as long as the style allows for more than 80 characters on a line(I vote for 120) +1 for Jenkins nagging me if i check in code that isn't formatted properly Dan Bress Software Engineer ONYX Consulting Services ________________________________________ From: Adam Taft <[email protected]> Sent: Tuesday, March 17, 2015 4:35 PM To: [email protected] Subject: Re: lack of consistent formatting - how do others clean this up? Whitespace is a holy war and should be avoided. Concern over two space or four space indents, tabs, etc. is not relevant and adds no value (concern with spacing is a form of muda). Diffs and other change evaluations can ideally be done without care for whitespace. This is an easy option for most diff tools. Sun + 4 space indents seems to be the "norm" for NiFi. I like Sean's second proposal for using jenkins as a nag toward more consistent formatting. There are code formatting options in each IDE to help as well. But ultimately, I don't think a lot of effort should be spent on this. Developers should just be mindful, as with any other type of contribution, that they should conform to the lay of the land. I personally prefer tabs over spaces for my indents (I could rant why this is "correct" -- again, holy war). But if I'm contributing to NiFi, I'm using 4 space indents, because that's what is normal for the project. Two cents. Adam On Tue, Mar 17, 2015 at 2:29 PM, Sean Busbey <[email protected]> wrote: > Set a coding standard (sun + 2 space indents is common), then use > checkstyle to complain when things don't match. It helps when you can > provide IDE formatting configurations that match your chosen coding > standard. > > Some of the bigger projects use a jenkins precommit bot that checks (among > other things) that the checkstyle violations don't go up with a proposed > patch. The bot comments on the jira and the committers decide if any > violations need to get fixed. Personally, I like this approach better than > e.g. trying to fail the build with checkstyle because it allows incremental > improvement. > > On Tue, Mar 17, 2015 at 1:02 PM, Joe Witt <[email protected]> wrote: > > > Folks, > > > > It was brought up to me by a contributor the other day that our lack > > of consistent formatting makes reviewing true changes difficult. I > > see it myself quite often. There are difference between formatting in > > Eclipse/Netbeans/manual VI/etc.. > > > > I am assuming there are good plugins to just automate this sort of > > stuff. What do you all think as a good way to go about this? > > > > Thanks > > Joe > > > > > > -- > Sean >
