Re: [omr-dev] our coding standard

["Keith Campbell" <keithc@xxxxxxxxxx>]

There are elements of OMR's documented coding style that aren't about formatting: I assume this discussion is not about changing those (at least not at this point).

Another factor that I think should guide our choice of formatting style is ease of adoption. Being an eclipse project, I think a reasonable formatting style might be the default CDT formatting preferences: that way new users (that use eclipse) don't have to do anything to get the right formatting set up.

Whatever we choose, I'd like to see it explicitly captured: .settings/org.eclipse.cdt.core.prefs would be committed to the repository.

-Keith

Mark Stoodley---2016-08-22 13:47:40---We've been working with what was primarily the J9 coding standard for a few months now, but we're a

From: Mark Stoodley/Toronto/IBM@IBMCA
To: omr-dev@xxxxxxxxxxx
Date: 2016-08-22 13:47
Subject: [omr-dev] our coding standard
Sent by: omr-dev-bounces@xxxxxxxxxxx

---

We've been working with what was primarily the J9 coding standard for a few months now, but we're about to enter a new chapter in the project with IBM about to contribute the OMR JIT technology (about 600KLOC).

Because it was developed by a completely different team, the OMR JIT has used a very different coding standard than the rest of the J9 technology.

That puts us in a difficult spot where either the existing OMR code or the incoming JIT code needs to be reformatted (I don't want two different coding standards). The current standard cannot be applied automatically (nor can the incoming JIT coding standard), and that means we risk introducing bugs just to satisfy the coding standard. On top of this issue, I would like to make the two following observations about our current coding standard:
        1) we spend a lot of design review time and effort on coding standard adherence
        2) the complexity of the current coding standard will be, if it hasn't been already, an inhibitor to on-boarding new project members

I would like to propose we move to a completely different coding standard that can be automatically applied by a tool like clang-format: maybe something like LLVM or WebKit. With a tool automatically applying the formatting, the risk of new bugs being introduced is low whereas the benefit of a unified, consistent, and automatically enforced coding standard is high.

We don't have to apply the exact same standard (if we went with LLVM, for example, we might want to be more conservative on C++11 features). But I think it should be automatically applied, even automatically as part of code check-in for review.

Thoughts?

Let's try not to descend into quasi-religious arguments about rule X or rule Y. There is no perfect coding standard and any new coding standard we pick will be both better and worse than the current coding standard for both OMR and the incoming JIT code.

We still have a problem to solve, so let's try to focus on solving that problem.

Mark Stoodley		8200 Warden Avenue
Senior Software Developer		Markham, L6G 1C7
IBM Runtime Technologies		Canada
Phone:	+1-905-413-5831
e-mail:	mstoodle@xxxxxxxxxx
We cannot solve our problems with the same thinking we used when we created them - Albert Einstein

_______________________________________________
omr-dev mailing list
omr-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/omr-dev