Regarding applying the changes: I think we want to have good balance between few goals: 1. Minimize risk of changes by having a well defined scope 2. Make reviewing easier 3. Ease of cherry-picking 4. Ease of incrementally improving code quality
Our current process leans toward the first three goals, but discourages small improvements by adding quite a bit of process around them. I'd like to see us a bit more open toward small code improvements that do not add significant risk to the project. Spelling of variable names, import order, indentation, comment readability, etc. I believe it will lead to better code in the long term, without significant drawbacks. Gwen On Mon, Dec 1, 2014 at 6:17 PM, Jarek Jarcec Cecho <[email protected]> wrote: > Thank you for putting the coding guidelines together Veena. I’ve read the > page and I don’t see anything concerning. I have to admit that I did not read > the whole Google guideline so I’m wondering if there are any huge differences > between current (albeit unwritten) rules and the proposed Google guidelines? > > I’ve added/edited the content a bit, trying to put some small comments > without changing the semantics of the page. I have following larger points: > > 1) Line size > > The “General Rules” section specifies that the “Column limit can be 80 or 100 > characters”, the subsection “ Column Limit and Line Wrapping” is stating only > “100” and then suggesting that we could also drop any line limits. I would > suggest to synchronize those places together as it seems quite confusing. > > I would personally vote to not have any sharp limit for maximum line size. We > have 80 characters limit in Sqoop 1 and it makes code very hardly readable at > some places, so I like the Kafka wording “no maximum size, but be reasonable”. > > 2) Applying the changes > > Considering that we might introduce some changes against current (unwritten) > rules, I think that we should talk about how we’re going to enforce the > coding guidelines going forward. This is not a question for new files as > those should obviously follow them. I’m more interested to discuss how we’re > going to handle changes in current files. As we are trying to keep each patch > focusing on given functionality and we’re discouraging unrelated changes, I > would propose to discourage people to enforce those rules in existing files > if that would mean to significantly refactor the file just for the purpose of > being compliant with our code guidelines. > > This of course doesn’t mean that people should not follow the guidelines at > all (new content should follow them) or that we’re going to stick to the old > formatting forever (on large file refactoring it would be OK to apply such > changes). I’m just worried about introducing a lot of unnecessary changes > just to keep in sync with coding guidelines. > > Jarcec > >> On Nov 30, 2014, at 6:29 PM, Veena Basavaraj <[email protected]> wrote: >> >> Qian, >> >> I think we both are on the same page. >> >> I just wrote the guidelines wiki to to come up with the code style. >> >> One we all vote on the wiki, we can formulate those rules as IDE specific >> files, like the one you attached for intelliJ >> >> Hope it clears the confusion now. >> >> >> >> >> Best, >> *./Vee* >> >> On Sun, Nov 30, 2014 at 6:20 PM, Xu, Qian A <[email protected]> wrote: >> >>> Hi Veena, >>> >>> A code guideline will definitively help both developers and reviews to >>> contribute code better. I'd suggest apply code style to new code >>> contribution first. >>> >>> --Qian (Stanley) Xu >>> >>> -----Original Message----- >>> From: Veena Basavaraj [mailto:[email protected]] >>> Sent: Monday, December 01, 2014 10:09 AM >>> To: [email protected] >>> Subject: Re: Sqoop 2 JAVA coding guidelines >>> >>> Thanks Qian, I will attach it, do you have any comments on the guidelines? >>> We should all vote for the wiki guidelines before we attach the formatter. >>> >>> Please send an email to the dev@ list asking permission to edit the wiki. >>> >>> >>> >>> >>> Best, >>> *./Vee* >>> >>> On Sun, Nov 30, 2014 at 5:59 PM, Xu, Qian A <[email protected]> wrote: >>> >>>> Hi there. >>>> >>>> I don’t have the privilege to add attachment to Wiki , so I've >>>> attached code formatter of IntelliJ (v13.1). I hope this helps. >>>> >>>> --Qian (Stanley) Xu >>>> >>>> >>>> -----Original Message----- >>>> From: Gwen Shapira [mailto:[email protected]] >>>> Sent: Monday, December 01, 2014 8:46 AM >>>> To: [email protected] >>>> Subject: Re: Sqoop 2 JAVA coding guidelines >>>> >>>> I think its a great idea to document the coding standards that already >>>> exist for this project. >>>> It can be frustrating to new contributors to have to guess their way >>>> around our un-written expectations. >>>> >>>> Gwen >>>> >>>> On Sun, Nov 30, 2014 at 2:05 PM, Veena Basavaraj >>>> <[email protected]> >>>> wrote: >>>>> Hey all, >>>>> >>>>> Since a few months I have been contributing to Sqoop2, I do notice a >>>>> lack of style guide for sqoop2 code. >>>>> >>>>> I have started a wiki highlighting things for developers to follow. >>>>> >>>>> https://cwiki.apache.org/confluence/display/SQOOP/Sqoop+2+Coding+Gui >>>>> de lines I prefer the google java style guide to begin with. >>>>> >>>>> Please add your comments in the comments section on things you would >>>>> like to have, so we can iterate over this in the coming few weeks >>>>> and settle down to a standard that every one can use in their IDE. I >>>>> am happy to create a formatter XML for eclipse as per these rules >>>>> and attach it to the wiki. >>>>> >>>>> >>>>> >>>>> Best, >>>>> *./Vee* >>>> >>> >
