> I would like to propose we move to a completely different coding standard
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?
> That puts us in a difficult spot where either the existing OMR code or the incoming JIT code needs to be reformatted
So we'd reformat both? Doesn't that just increase the likelihood of "introducing bugs just to satisfy the coding standard"?
> that can be automatically applied by a tool like clang-format:
I'm 100% onboard with automating as much of the existing standard as possible. Even if the automation provided 80-90% of the formatting, we'd be in a good pretty good place.
The purpose of a coding standard is to keep the code mostly consistent and to help to prevent logic errors. Many of the rules in the J9 standard came about because we wanted the code to be clear and easy to reason about - brackets everywhere, each line of code should do one thing, etc - so that readers could focus on the algorithms, not worry about understanding overly clever code. Looking at the existing OMR code (and for anyone that has access, the J9 source), it's clear that being pedantic about the formatting has never been the goal. Instead, it's been to make it easy to read and understand the code. (Reading > writing)
> 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).
The nice thing about standards is there are so many of them... so we'd introduce yet another variant? =P
> We still have a problem to solve, so let's try to focus on solving that problem.
Is the root problem that there is a lack of automation for the existing standard? Has anyone tried to automate 80-90% of the existing standard with clang-format?
--Dan
----- Original message -----
From: Mark Stoodley/Toronto/IBM@IBMCA
Sent by: omr-dev-bounces@xxxxxxxxxxx
To: omr-dev@xxxxxxxxxxx
Cc:
Subject: [omr-dev] our coding standard
Date: Mon, Aug 22, 2016 1:47 PM
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 |
| |
| |
