sqoop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Veena Basavaraj <vbasava...@cloudera.com>
Subject Re: Sqoop 2 JAVA coding guidelines
Date Tue, 02 Dec 2014 03:04:44 GMT
Very well articulated Gwen.

So the question is
#1. Should we start using code standards?
#2, if we do, what is the best way to enforce it?





Best,
*./Vee*

On Mon, Dec 1, 2014 at 6:39 PM, Gwen Shapira <gshapira@cloudera.com> wrote:

> 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 <jarcec@apache.org>
> 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 <vbasavaraj@cloudera.com>
> 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 <qian.a.xu@intel.com>
> 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:vbasavaraj@cloudera.com]
> >>> Sent: Monday, December 01, 2014 10:09 AM
> >>> To: dev@sqoop.apache.org
> >>> 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 <qian.a.xu@intel.com>
> 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:gshapira@cloudera.com]
> >>>> Sent: Monday, December 01, 2014 8:46 AM
> >>>> To: dev@sqoop.apache.org
> >>>> 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
> >>>> <vbasavaraj@cloudera.com>
> >>>> 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*
> >>>>
> >>>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message