We're definitely in the realm of opinions here. =) Very little objective fact to prefer one coding standard to another.... other than that one is the standard used by the existing community and current code base. Given your stated preference to have a single coding standard (and that the JIT will be changing anyway), why is something from an external community "better" than what we've agreed on previously?
This feels like optimizing for a hypothetical community at the expense of the actually community we currently have. And selfishly, this complicates my team's lives as J9 won't be changing its coding standard for reasons similar to those Kim already stated. If OMR changes, we'll have multiple standards to deal with - one for internal code and one for OMR. Sadness.
--Dan
----- Original message -----
From: Mark Stoodley/Toronto/IBM@IBMCA
Sent by: omr-dev-bounces@xxxxxxxxxxx
To: omr developer discussions <omr-dev@xxxxxxxxxxx>
Cc:
Subject: Re: [omr-dev] our coding standard
Date: Tue, Aug 23, 2016 2:13 PM
Daniel Heidinga <Daniel_Heidinga@xxxxxxxxxx> writes:
> I don't follow the logic here. The J9 standard was already
> adopted through discussions on the various github issues and
> matches the existing code base. It developed to address the
> kinds of bugs / issues that the J9 team found when developing
> code. What is the benefit of moving to a completely different
> standard than the one that half the OMR developer community
> uses day to day?
I completely understand your position, Dan, given that you're part
of that half. But there's a whole other half of this community that
does not use that coding standard and an entire world of people who
may not want to learn yet another 1,444 lines (of markdown)
describing our coding standard, no matter how well motivated the
various rules may be.
I think the benefit would be to make the project more welcoming both
to people who are part of the community as well as those who aren't
yet a part of it. Reuse and consolidated effort are very important
to Eclipse OMR. We need to walk it as well as say it, and coding
standard (to me) doesn't feel like a place where we need to walk
alone. That's an opinion, which is why I initiated this discussion
to see whether others agreed with it or not.
> So we'd reformat both? Doesn't that just increase the likelihood
> of "introducing bugs just to satisfy the coding standard"?
Manual changes increase the likelihood of bugs. I would rather use
an automatic tool with a commonly used style format on all of
our code base than to use the same tool with a style format of our
own unique design on something more than half our code base. The
difference in risk doesn't feel that all that different, but having
a unified common code standard benefits the community, as you observed
yourself :) .
--mark
