Re: [omr-dev] our coding standard

["Mark Stoodley" <mstoodle@xxxxxxxxxx>]

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