Hi Brian,
IMO, these kinds of discussions are all about aesthetics and almost always
devolve to arguments
that go nowhere, at least nowhere productive.
I know there have been a number of discussions over the many years of this
project, involving
Janne and others. Whether we love the current formatting or not, I would be
loath to let *anyone*
(including myself) go in and modify the code's formatting according to
their own whims. It's simply
not an appropriate thing for a single member of an open source team to do,
unless that team
member happens to have some demonstrable authority in the project that
might permit them to
dictate the aesthetics of the project's code, and then it'd still be
questionable. I for one don't have
any reason to believe your code would be any "tighter" than anyone else's.
This isn't a matter of
anyone's ability, nor is this because nobody has been willing to step up to
the plate, it's a matter
of respect for the work that has been put into the project. This might have
been a useful subject
when the project was still new, but Janne has long ago defended his choices
and I'm fine with that.
So if I had my way I might format it somehow differently than it is now,
and likely different than
you. Yes, there's more vertical whitespace than is necessary, and I don't
happen to like the extra
linebreaks around the curly braces. But it's not my project. Other projects
I've submitted code
to have different "standards". For myself (and in the Neocortext code base)
I try to comply to
the Sun/Java standard. JSPWiki has its own, and it's relatively consistent
across the project. I
think consistency across the entire codebase is more important than any
individual's desires, so
I'm happy to comply to the standards of the project. I'd even advocate
refactoring classes that
didn't match the current formatting to match the rest of the project rather
than introduce some
questionably "improved" formatting in only a few classes.
One of my coworker's quipped a relevant haiku:
Code is poetry
the compiler doesn't care.
So I can't say that "shaking the tree" on a project that's gone through as
much as this one
(going back over a decade) is (frankly) much appreciated.
Nothing personal. Just not a productive conversation IMO.
Ichiro
On Thu, Feb 13, 2014 at 6:12 AM, Brian Burch <br...@pingtoo.com> wrote:
> When I first started working on patches for tomcat several years ago, I
> found their code standards quite extreme compared to my personal
> preferences. As time has passed, I've come to appreciate their rules and
> adopted many (not all) for my own projects.
>
> As I've started working on jspwiki, I must confess to a feeling of shock
> when seeing some of the classes for the first time. I'll even confess to
> doing a "hatchet job" on 3 or 4 before I could feel comfortable reading the
> code and exploring possible changes. Even debugging under netbeans with a
> wide screen and small font can be difficult with so little actual code
> visible at once.
>
> I don't want to upset anyone who has worked hard on this project, but what
> would be the reaction to some "clean up only" patches?
>
> I'm thinking only of removing multiple spaces (inherited from tab
> replacement, or just to align variables of different lengths), removing
> trailing white space, removing unnecessary or confusing empty lines,
> getting rid of /n between if and {, putting angle brackets around single
> line if statements, that sort of thing.
>
> If you all love it how it is, then I'll learn to do so too. On the other
> hand, if tighter code is on your wish list, I'd be pleased to help when
> working on a class for some other reason. If you already have a checkstyle
> configuration that you'd like to converge on, I'd like to see it.
>
> Sorry for shaking the tree!
>
> Best intentions from...
>
> Brian
>
