All generated code should also be free of all compiler warnings and errors as reported by common utilities such as FindBugs, CheckStyle, and PMD. The entire starting project (i.e. maven archetype) should be easily created and should generate and compile and run and pass all generated tests immediately out of the box. Unit and integration tests should be generated from the input model and contain reasonable defaults for all data values (i.e. using mock objects) while still being easily modifiable. There should be a very clear separation of artifacts that are generated every time from those that are generated once (stubbed out implementations), in order to make updates and synchronizations between multiple users within a source code control system as easy as possible.

Jack’s point about avoiding lock-in was not so much about mixing hand code and generated code, but about the flexibility of allowing developers to understand and maintain the generated code if needed. This primarily encompasses how the code looks, where the code is generated, and scenarios including the absence of the code generator during enhancements or maintenance.

You are correct, best practices dictate generated code should contain such syntax and reside in separate folders (and Skyway is no different). However, there are valid use-cases for developers to blend hand code and generated code. For example, code generators that only generate stubs. Another example we have seen is in team development where you have more experienced team developers working with less experienced developers. The overall concept of avoiding lock-in is to allow this flexibility so that any developer in any scenario can use the code after it is generated.

Comment from Ben Gillis:
> #7, Generated artifacts should be indistinguishable from those that would be written by hand

Not sure I follow this one.
My auto-gen’d code goes in a separate file with a header over it saying it is auto-gen’d, “do not edit” warning.

Rule: no mixing of auto-gen’d code and manual code in the same file.

It keeps the framework specifics out of my Java code. This kind of pattern is very useful to abstract out the specifics of the framework/deployment/platform plumbing and allow for development of the core business logic with only Java developers and do not need framework/deployment/platform specialist knowledge and skill across the whole team.

The naming must abstract enough that it does leak in any framework/deployment/platform specific grammar into your code.

That’s one of my annoyances, albeit very minor, with some of the new Java Annotations. The packaging and naming of them are leaking framework grammar into our code, i.e. javax.ejb.persistence.Entity. This implicitly leaks into the code grammatically that the POJO is a ejb3 entity. They should have kept the namespace and naming agnostic to something like java.lang.annotations.Persistable, then it would not have leaked into POJO and let the deployment environment determine the persistable framework, i.e. ejb3 if it was deployed into an ejb3 container or JDO or SQLMap, etc.