Should I store generated code in source control

Question

Saving it in source control is more trouble than it's worth.

You have to do a commit every time you do a build for it to be any value.

Generally we leave generated code( idl, jaxb stuff, etc) outside source control where I work and it's never been a problem

Put it in source code control. The advantage of having the history of everything you write available for future developers outweighs the minor pain of occasionally rebuilding after a sync.

Every time I want to show changes to a source tree on my own personal repo, all the 'generated files' will show up as having changed and need comitting.

I would prefer to have a cleaner list of modifications that only include real updates that were performed, and not auto-generated changes.

Leave them out, and then after a build, add an 'ignore' on each of the generated files.

Look at it this way: do you check your object files into source control? Generated source files are build artifacts just like object files, libraries and executables. They should be treated the same. Most would argue that you shouldn't be checking generated object files and executables into source control. The same arguments apply to generated source.

If you need to look at the historical version of a generated file you can sync to the historical version of its sources and rebuild.

Checking generated files of any sort into source control is analogous to database denormalization. There are occasionally reasons to do this (typically for performance), but this should be done only with great care as it becomes much harder to maintain correctness and consistency once the data is denormalized.

I would say that you should avoid adding any generated code (or other artifacts) to source control. If the generated code is the same for the given input then you could just check out the versions you want to diff and generate the code for comparison.

I call the DRY principle. If you already have the "source files" in the repository which are used to generate these code files at build time, there is no need to have the same code committed "twice".

Also, you might avert some problems this way if for example the code generation breaks someday.

No, for three reasons.

1. Source code is everything necessary and sufficient to reproduce a snapshot of your application as of some current or previous point in time - nothing more and nothing less. Part of what this implies is that someone is responsible for everything checked in. Generally I'm happy to be responsible for the code I write, but not the code that's generated as a consequence of what I write.

2. I don't want someone to be tempted to try to shortcut a build from primary sources by using intermediate code that may or may not be current (and more importantly that I don't want to accept responsibility for.) And't it's too tempting for some people to get caught up in a meaningless process about debugging conflicts in intermediate code based on partial builds.

3. Once it's in source control, I accept responsibility for a. it being there, b. it being current, and c. it being reliably integratable with everything else in there. That includes removing it when I'm no longer using it. The less of that responsibility the better.