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:[email protected]] Sent: Saturday, May 30, 2015 7:20 AM To: POI Developers List Subject: Re: style guidelines? Hi, 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 demand. 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 junit.Assert.*. Dominik. On Fri, May 29, 2015 at 11:33 PM, Andreas Beeker <[email protected]> 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 imports > 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 and > 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 optimization > >> 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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
