Another approach is to submit two patches to a bug report, one without format changes and one with. Both would have identical function changes.
If people like the functional changes, the reformatted version could be applied if not too many patches are outstanding on that particular file. It should be pretty easy to scan for conflicts. This minimizes the need to rebase patches all the time and reformats files as they are changed, thus focusing the reformatting on commonly changed files. On Thu, Feb 18, 2010 at 3:02 PM, Martinez, Mel - 1004 - MITLL < m.marti...@ll.mit.edu> wrote: > +1 > > The sun conventions are excellent and what I've always tried to follow. > Unfortunately, not always possible when diving into an existing codebase > and > a group with existing standards that are different. > > Eclipse' formatting tools can be used to quickly apply most of the > guidelines at once to a file. Very handy. > > I would recommend though, that any reformats to bring source into > conformance with new conventions be done discrete of any functional > feature/bug changes. > > I.E. > > > 1) Create a Jira issue specifically for 'code hygiene' for this task. > 2) Reformat a file or files. > 3) Commit them without making any functional changes. > > This way, when looking for functional differentials, they will be easy to > find and identify in diff comparisons and not masked within a ton of > hygiene > changes. > > Cheers, > > Mel > > -----Original Message----- > From: Jukka Zitting [mailto:jukka.zitt...@gmail.com] > Sent: Thursday, February 18, 2010 5:27 PM > To: dev@pdfbox.apache.org > Subject: PDFBox coding style > > Hi, > > Following up from a comment made in private. > > I suppose I'm not the only one who finds the current PDFBox coding > style inconvenient. All the other Java projects I'm working with > follow close approximations of the classic Sun Java coding conventions > [1]. PDFBox doesn't, which makes the code harder to read and write at > least for me. > > It's not too big an issue and I can certainly live with the current > coding style, but I'm wondering if there would be enough support to > consider a gradual migration to a more standard style. > > [1] http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html > > BR, > > Jukka Zitting > -- Ted Dunning, CTO DeepDyve
