The gotchas of changing generated code
Most developers spend the majority of their time reading code, and more often it's someone else's.
Sometimes you may get to work on a greenfield project where you know all the code yourself but that is unusual.
So usually when your reading someone else's code, you are often trying to understand the intent of the code and how it fits into the architecture.
Following a practice of using "Intention revealing names"
Can help the developer that follows after you to understand the buildings block of your code.
Often that means that they can read the signature of the code and then not have to read
every
single
line
of
the
code.
So, the aim is not to surprise the developer.
Certain frameworks help with that.
In the Java space, Maven has a standard for setting up projects in a standard way.
Tests go in one folder, resources in another. Libraries always come from "Lib".
One of the things it has a standard for is generated code. Code that is generated is placed in a standard folder in the build and recreated each time so that it is not stale, and prevents the developer from trying to change it.
So developers using maven to generate code aren't surprised by the standard behaviour.
Code that is generated goes into a "gen" standard folder. Usually the code has comments in the file to indicated it's generated and not to change it.
//
// This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, v2.2.8-b130911.1802
// See <a href="https://www.dhirubhai.net/redir/general-malware-page?url=http%3A%2F%2Fjava%2esun%2ecom%2Fxml%2Fjaxb">https://www.dhirubhai.net/redir/general-malware-page?url=http%3A%2F%2Fjava%2esun%2ecom%2Fxml%2Fjaxb</a>
// Any modifications to this file will be lost upon recompilation of the source schema.
// Generated on: 2016.02.28 at 03:27:10 PM IST
//
In the case of IIB, we aren't supported in the same way by the tools and process.
For compute (and filter nodes), the tool generates standard code for "CopyMessageHeaders" and "CopyEntireMessages".
When these are generated, they don't include any "hints" that they are generated. So developers have to just "know" from experience that they are provided by the tool.
So this is where we want to ensure that we don't surprise the developer that comes after us.
If every single "CopyMessageHeaders" and "CopyEntireMessages" does the same thing, as its name suggests, then we aren't going to spend time reading each and everyone of them.
We can easily catch out our fellow developers out by surprising them, and by changing one of these implementations. Breaking the rule of "not changing generated code" we can easily surprise them and potentially introduce bugs and complexity by changing one of these routines. They'll never find it until they look through each and every implementation until they find the one that's different, that's creation the unexpected behaviour.
Not a good use of our developers time and energy (or a great way to spend your IT budget).
To help with preventing this issue, we have added a new rule to our MB-Precise product.
R375 - The generated procedure CopyMessageHeaders has been modified (WMB)
This will flag when the standard generated code has been modified.
If you have a standard where you do change the "CopyMessageHeaders" procedure for each node, then perhaps a better option would be to provide the changed procedure with a new name.
Such as
CREATE PROCEDURE CopyMessageHeadersAndAddSpecialBehaviour() BEGIN
DECLARE I INTEGER 1;
DECLARE J INTEGER;
SET J = CARDINALITY(InputRoot.*[]);
WHILE I < J DO
SET OutputRoot.*[I] = InputRoot.*[I];
SET I = I + 1;
END WHILE;
SET Environment.Value.X = 1;
END;
So that the developer knows that the code has additional functionality not covered by the standard "CopyMessageHeaders".
If you are interested in finding out more about this rule, our product or were interested in a demonstration, please drop me an email to:
Or contact me via the contact page on our website.
Regards
Richard
#IIB #SonarQube #WMB #DevOps