giraph-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Homan <jgho...@gmail.com>
Subject Re: Order of imports
Date Sun, 01 Jul 2012 22:26:43 GMT
There needs to be special configuration for devs to support these new
restrictions, if they are going to go in (-1 otherwise).  And yes,
Eclipse will need to be supported automatically as well.  As for
NetBeans... well, there may be some wiggle room there.


On Sun, Jul 1, 2012 at 3:25 PM, Alessandro Presta <alessandro@fb.com> wrote:
> I think we can also just include the pre-configured files in the .idea/
> folder in the project root. I can find out how that works.
>
> On 7/1/12 11:20 PM, "Hyunsik Choi" <hyunsik@apache.org> wrote:
>
>>If IDE configurations should be provided, they can be available from the
>>web page. For example, the section 'Generating Patches' in the home (
>>http://giraph.apache.org) would be good place.
>>
>>--
>>Hyunsik Choi
>>
>>On Mon, Jul 2, 2012 at 7:15 AM, Alessandro Presta <alessandro@fb.com>
>>wrote:
>>
>>> I don't think we currently have IDE configurations in the repo. We
>>>should
>>> do that. I can see how that works for IntelliJ IDEA. Anyone using
>>>Eclipse?
>>>
>>> On 7/1/12 11:06 PM, "Hyunsik Choi" <hyunsik@apache.org> wrote:
>>>
>>> >That seems a great idea. In addition to the order of imports, it will
>>>be
>>> >better if all coding convention is included in both IDE configurations.
>>> >
>>> >--
>>> >Hyunsik Choi
>>> >
>>> >On Mon, Jul 2, 2012 at 3:13 AM, Avery Ching <avery.ching@gmail.com>
>>> wrote:
>>> >
>>> >> I think uniformity is good.  I think as long as IDE's support our
>>>rules
>>> >> (as Alessandro mentioned) this can only be better.  We can continue
>>>this
>>> >> discussion per GIRAPH-230.
>>> >>
>>> >> Avery
>>> >>
>>> >>
>>> >> On 7/1/12 8:35 AM, Alessandro Presta wrote:
>>> >>
>>> >>> I think we should strive to make the signal-to-noise ratio of our
>>> >>>diffs as
>>> >>> high as possible, while at the same time enforce a certain level
of
>>> >>> uniformity.
>>> >>> Besides, we already have a bunch of conventions for imports in
>>> >>> checkstyle.xml, so this is straightforward.
>>> >>> IDEA (and I'm pretty sure Eclipse too) can organize your imports
>>>given
>>> >>>a
>>> >>> set of rules, and there are also Checkstyle plugins that run checks
>>> >>>while
>>> >>> you're coding.
>>> >>>
>>> >>> On 6/30/12 6:43 AM, "Jakob Homan" <jghoman@gmail.com> wrote:
>>> >>>
>>> >>>  My thought is that after reviewing a lot of patches, I honestly
>>>don't
>>> >>>> care about the imports... If your IDE can do something sensible
>>>with
>>> >>>> them, that's great.  But they have no effect on the code or
add any
>>> >>>> extra effort to the code reviews.
>>> >>>>
>>> >>>>
>>> >>>> On Fri, Jun 29, 2012 at 10:34 PM, Avery Ching <aching@apache.org>
>>> >>>>wrote:
>>> >>>>
>>> >>>>> It's not silly at all.  I suggest that we add some checkstyle
>>>rules
>>> >>>>>for
>>> >>>>> enforcing our convention as well.
>>> >>>>>
>>> >>>>>
>>> >>>>>http://checkstyle.sourceforge.**net/config_imports.html<
>>> http://checkst
>>> >>>>>yle.sourceforge.net/config_imports.html>
>>> >>>>>
>>> >>>>> I like AvoidStarImport, RedundantImport, UnusedImports,
and (most
>>> >>>>> related to
>>> >>>>> this question) ImportOrder.
>>> >>>>>
>>> >>>>> Any thoughts?
>>> >>>>>
>>> >>>>> Avery
>>> >>>>>
>>> >>>>> On 6/29/12 8:23 AM, Alessandro Presta wrote:
>>> >>>>>
>>> >>>>>> Hi all,
>>> >>>>>>
>>> >>>>>> Kind of a silly concern, but nevertheless:
>>> >>>>>>
>>> >>>>>> IntelliJ IDEA does a great job at optimizing imports
for you.
>>>While
>>> >>>>>> doing
>>> >>>>>> so, it also insists in reorganizing them following some
logic.
>>> >>>>>> Since it's not nice to have a patch dirtied by imports
reordering
>>> >>>>>>every
>>> >>>>>> time a different person touches a class, it could be
a good idea
>>>to
>>> >>>>>> come up
>>> >>>>>> with a convention and configure our IDEs accordingly.
>>> >>>>>>
>>> >>>>>> Example (blank lines matter):
>>> >>>>>>
>>> >>>>>> org.apache.giraph.*
>>> >>>>>>
>>> >>>>>> org.*
>>> >>>>>>
>>> >>>>>> com.*
>>> >>>>>>
>>> >>>>>> javax.*
>>> >>>>>> java.*
>>> >>>>>>
>>> >>>>>> Or any variation you prefer.
>>> >>>>>>
>>> >>>>>> If there is agreement we can update the code conventions.
>>> >>>>>>
>>> >>>>>> Alessandro
>>> >>>>>>
>>> >>>>>>
>>> >>
>>> >>
>>>
>>>
>

Mime
View raw message