-- One change at a time. Not five, not three, not ten. One and only one.
- Why? Because it limits the blast area of the change. If we have a
- regression, it is much easier to identify the culprit commit than if
- we have some composite change that impacts more of the code.
-
-- Include a link to the JIRA story for the change. Why? Because a) we
- want to track our velocity to better judge what we think we can
- deliver and when and b) because we can justify the change more
- effectively. In many cases, there should be some discussion around a
- proposed change and we want to link back to that from the change
- itself.
-
-- Include unit and integration tests (or changes to existing tests)
- with every change. This does not mean just happy path testing,
- either. It also means negative testing of any defensive code that it
- correctly catches input errors. When you write code, you are
- responsible to test it and provide the tests that demonstrate that
- your change does what it claims. Why? Because without this we have no
- clue whether our current code base actually works.
-
-- Minimize the lines of code per CR. Why? If you send a 1,000 or 2,000
-LOC change, how long do you think it takes to review all of that code?
-Keep your changes to < 200-300 LOC, if possible. If you have a larger
-change, decompose it into multiple independent changess. If you are
-adding a bunch of new functions to fulfill the requirements of a new
-capability, add them separately with their tests, and then write the code
-that uses them to deliver the capability. Of course, there are always
-exceptions. If you add a small change and then add 300 LOC of tests, you
-will be forgiven;-) If you need to make a change that has broad impact or
-a bunch of generated code (protobufs, etc.). Again, there can be
-exceptions.
-
- **NOTE:** Large change requests, e.g. those with more than 300 LOC
- are more likely than not going to receive a -2, and you'll be asked
- to refactor the change to conform with this guidance.
-
-- Do not stack change requests (e.g. submit a CR from the same local branch
- as your previous CR) unless they are related. This will minimize merge
- conflicts and allow changes to be merged more quickly. If you stack requests
- your subsequent requests may be held up because of review comments in the
+- One change at a time. Not five, not three, not ten. One and only one. Why?
+ Because it limits the blast area of the change. If we have a regression, it
+ is much easier to identify the culprit commit than if we have some composite
+ change that impacts more of the code.
+
+- Include a link to the JIRA story for the change. Why? Because a) we want to
+ track our velocity to better judge what we think we can deliver and when and
+ b) because we can justify the change more effectively. In many cases, there
+ should be some discussion around a proposed change and we want to link back
+ to that from the change itself.
+
+- Include unit and integration tests (or changes to existing tests) with every
+ change. This does not mean just happy path testing, either. It also means
+ negative testing of any defensive code that it correctly catches input
+ errors. When you write code, you are responsible to test it and provide the
+ tests that demonstrate that your change does what it claims. Why? Because
+ without this we have no clue whether our current code base actually works.
+
+- Minimize the lines of code per CR. Why? If you send a 1,000 or 2,000 LOC
+ change, how long do you think it takes to review all of that code? Keep your
+ changes to < 200-300 LOC, if possible. If you have a larger change, decompose
+ it into multiple independent changess. If you are adding a bunch of new
+ functions to fulfill the requirements of a new capability, add them
+ separately with their tests, and then write the code that uses them to
+ deliver the capability. Of course, there are always exceptions. If you add a
+ small change and then add 300 LOC of tests, you will be forgiven;-) If you
+ need to make a change that has broad impact or a bunch of generated code
+ (protobufs, etc.). Again, there can be exceptions.
+
+ **NOTE:** Large change requests, e.g. those with more than 300 LOC are
+ more likely than not going to receive a -2, and you'll be asked to
+ refactor the change to conform with this guidance.
+
+- Do not stack change requests (e.g. submit a CR from the same local branch as
+ your previous CR) unless they are related. This will minimize merge conflicts
+ and allow changes to be merged more quickly. If you stack requests your
+ subsequent requests may be held up because of review comments in the