You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by Jukka Zitting <ju...@gmail.com> on 2010/02/18 23:27:22 UTC
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
Re: PDFBox coding style
Posted by Ad...@swmc.com.
While I haven't contributed much code to the project, I'd just like to say
that I support this change. If/when I do update code, I can reformat the
file I'm working if the decision is made to switch to the standard Java
formatting.
--Adam
From:
Jukka Zitting <ju...@gmail.com>
To:
dev@pdfbox.apache.org
Date:
02/18/2010 14:29
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
? Click here to submit conditions
This email and any content within or attached hereto from Sun West Mortgage Company, Inc. is confidential and/or legally privileged. The information is intended only for the use of the individual or entity named on this email. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this email information is strictly prohibited, and that the documents should be returned to this office immediately by email. Receipt by anyone other than the intended recipient is not a waiver of any privilege. Please do not include your social security number, account number, or any other personal or financial information in the content of the email. Should you have any questions, please call (800) 453 7884.
Re: PDFBox coding style
Posted by nisen <ni...@gmail.com>.
Threre is a eclipse-formatter.xml in JempBox dir。I think we should do
the same as it.
--
nisen(English Name)/倪森(Chinese Name)
Blog: http://nisen.javaeye.com
Re: PDFBox coding style
Posted by Andreas Lehmkuehler <an...@lehmi.de>.
Hi,
Jukka Zitting schrieb:
> 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
I don't have a preferred coding style, as long as my IDE will do it mostly
automatically for me. ;-)
> [1] http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
>
> BR,
> Jukka Zitting
BR
Andreas Lehmkühler
Re: PDFBox coding style
Posted by Igor Podolskiy <ig...@ievvwi.uni-stuttgart.de>.
Hi,
> 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.
+1
I also spent a fair amount of time reformatting my originally Sun
styleguide formatted code (which is also what I'm used to) to current
PDFBox style as I prepared my patch... and I think there are better ways
to spend time than reformatting code :) Even if it mostly means tuning
Eclipse formatting settings.
But I also agree with Mel: IMHO the reformatting commits should be
reformmatting _only_, as they tend to generate big scattered diffs and
sifting through them looking for functional changes would be tedious.
Best regards
Igor
Re: PDFBox coding style
Posted by nisen <ni...@gmail.com>.
+1
2010/2/19 Martinez, Mel - 1004 - MITLL <m....@ll.mit.edu>
>
> Eclipse' formatting tools can be used to quickly apply most of the
> guidelines at once to a file. Very handy.
If Eclipse' formatting tools is used,the formatter profile should be
put in svn。If you use other IDE you'd commit your formatter profile
.So,everyone can begin work quickly。
the dir like next
codingstyle
+eclipse_formatter_profile.xml
+netbean_formatter_profile.xml
+readme.txt
--
nisen 倪森 from China
Blog: http://nisen.javaeye.com
Re: PDFBox coding style
Posted by Ted Dunning <te...@gmail.com>.
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.martinez@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.zitting@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
RE: PDFBox coding style
Posted by "Martinez, Mel - 1004 - MITLL" <m....@ll.mit.edu>.
+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.zitting@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