4 ms·

Speaking as someone who checks in other kinds of generated code. The tool, like any software, can have bugs/changes in behavior across versions. You don't want

by vruiz 8y ago

Speaking as someone who checks in other kinds of generated code. The tool, like any software, can have bugs/changes in behavior across versions. You don't want to introduce the chance of that happening without being audited in version control if you can easily avoid it.

taeric 8y ago
The tool should be referenced as a versioned dependency at build time. When it gets a new release, you do a new build. Complete with new tests. Anything you do that increases the time between the introduction of the bug and the finding of the bug will make it harder to actually fix it.
- jonathanlydall 8y ago
  In addition to my reply above about code-weaving, rather than the all or nothing approach that some code generation techiniques suffer, our tool allows proposed changes to be reviewed before you commit with writing the generated code to your disk. This allows developers to feel in control of what's changing in their code base during generation, rather than being worried that some custom code is going to get wiped out by code-gen without them realizing. In a past project I was on, we had our solution build process run T4 templates to generate code, and it significantly slowed down the build process. We feel code generation is something you explicitly do when you're "modelling", it's not something that's necessary to create a build nor should it create run-time dependency.
  - taeric 8y ago
    That attitude is ridiculously commendable, major kudos. My fear is typically around having "mixed edited" code. That is, code that is edited by hand and generated. I greatly prefer being able to know that the generated stuff is extended by language mechanisms and I will never really have even the ability to edit something that the generator will do. I have seen bugs in generated code, but I have always pushed to fix the generator, not just fixed the generated code. (That make sense?) And, reiterating because I feel it is important, your position is awesome. Thanks for sharing!

by vruiz 8y ago

taeric 8y ago

The tool should be referenced as a versioned dependency at build time. When it gets a new release, you do a new build. Complete with new tests. Anything you do that increases the time between the introduction of the bug and the finding of the bug will make it harder to actually fix it.

jonathanlydall 8y ago
In addition to my reply above about code-weaving, rather than the all or nothing approach that some code generation techiniques suffer, our tool allows proposed changes to be reviewed before you commit with writing the generated code to your disk. This allows developers to feel in control of what's changing in their code base during generation, rather than being worried that some custom code is going to get wiped out by code-gen without them realizing. In a past project I was on, we had our solution build process run T4 templates to generate code, and it significantly slowed down the build process. We feel code generation is something you explicitly do when you're "modelling", it's not something that's necessary to create a build nor should it create run-time dependency.
- taeric 8y ago
  That attitude is ridiculously commendable, major kudos. My fear is typically around having "mixed edited" code. That is, code that is edited by hand and generated. I greatly prefer being able to know that the generated stuff is extended by language mechanisms and I will never really have even the ability to edit something that the generator will do. I have seen bugs in generated code, but I have always pushed to fix the generator, not just fixed the generated code. (That make sense?) And, reiterating because I feel it is important, your position is awesome. Thanks for sharing!