poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allison, Timothy B." <talli...@mitre.org>
Subject RE: style guidelines?
Date Mon, 01 Jun 2015 11:46:12 GMT
Too late to be useful, but sounds great.  Thank you!

P.S. I found that Intellij's autocorrect-style function broke XWPFRelation because it moved
the initialization of _table to after the initialization of its contents...leading to an NPE...ha!

-----Original Message-----
From: Dominik Stadler [mailto:dominik.stadler@gmx.at] 
Sent: Saturday, May 30, 2015 7:20 AM
To: POI Developers List
Subject: Re: style guidelines?


I though about performing an automatic cleanup via Eclipse tooling at
some point, this would fix some of the inconsistencies across the
whole source and should provide a bit more consistency, albeit a full
automated reformatting is probably too much as it would make some code
less readable.

A big downside of this is that patches done with previous version
likely will not apply cleanly any more and everybody who has local
changes will have to do manual merges, however doing it once in a big
step is probably less hassle then doing it bit by bit as part of
multiple commits.

What do you think, would now be a good time to do some of these
changes? I would at least apply @Overrides/@Deprecated everywhere,
remove trailing whitespaces, adjust intendation, organize imports,
remove unnecessary casts, ... and a few others, all can be done easily
via the Eclipse "clean up" support.

About Imports:

I removed the automatic adjustment of imports some time ago because
with multiple people working on the code it usually ends up in a
change-ping-pong where devs apply "their" style every time they change
the file and thus the imports are changed to one style and then to
another. CTRL-SHIFT-O in Eclipse allows to organize the imports on

Usually I try to not have to think about the imports much. Fortunately
Eclipse has support in the CTRL-1 shortcut to let one choose the class
to import without having to go up. With some special settings in
Eclipse it should also work for the junit-assertions, e.g. try CTRL-1
on an assertTrue that is not imported yet will suggest to import


On Fri, May 29, 2015 at 11:33 PM, Andreas Beeker <kiwiwings@apache.org> wrote:
> Thank you, David and Tim.
> Before I ask you to go a bit more into detail, I wanted to add a few of my motivation
points -
> everything is minor and I can live without it, but when choosing between wildcards and
full import,
> I tend towards wildcards:
> - when writing junit4 test, every time I use a new assertXYZ, I have to switch to the
>   add a * to the static Assert import and then go back to the code.
> - If we receive patches, the imports don't always match - using wildcards might help
with it
>   (yes, very weak point)
> - We used to have organize imports on save in the Eclipse settings, some day this vanished
>   not sure why, I thought it's because of the keeping the order of the imports the same
>   to change less lines in the commit.
>   If we decide to omit wildcards, I'd prefer to activate that setting again.
>> It's much easier to debug that way ...
> I haven't noticed a difference in debugging in Eclipse - is there one?
>> and to ensure that I have the exact ones
> I know there are ambiguities - e.g. I don't like it, when similar classes have the same
name (e.g. Shape) -
> but this is more an issue of class design. One could also argue in contrast, if the classes
can't be
> imported uniquely with wildcards, there's something dodgy in their naming ...
> and we'd find out earlier, before users will notice it, as we can't control their namespace
>> In the ooxml classes, it makes it easier to confirm that I'm triggering the classes
that we need downstream in ooxml-schemas for Tika.
> So there are cases where the ooxml-lite task is doing its job not correct?
> Would the classloader load all the wildcards? - this would be a definite no-go for wildcards.
> I could imagine, that it doesn't fetch indirect references (e.g. enum classes),
> but that would happen either way.
> Andi.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org

To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org

To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org

View raw message