Preferences

Kerrnigan’s law seems to apply:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?


Agreed. Although it's also a bit worse than that for coding exclusively with macros. You have to add an extra degree of complexity for any additional code generator you add to your toolchain, when that path comes into play for debugging. Since we whole-buffalo'ed this situation, that's 100% of the code you could possibly need to debug.
Yes, precisely, that's when all that cleverness will come back to bite you hard.

"Which line was that again? Oh... "

Pics up the phone, dials.

"Honey, I won't be home in time for dinner."

Yup. This is why I have a pretty hard set of rules about introducing code generation and DSL's into a team project:

0. Code generators are to be used hand-in-hand with the coding process.

1. Code generation must happen pre-build, using tooling supplied or documented thoroughly in the project repo.

2. Code generator code and its most recently generated output are checked in alongside the rest of the project.

3. "No humans allowed" inside generated code areas/files.

4. Direct and intermediate output (if applicable) from code generators must be human readable. Proper code formatting is strongly advised.

5. This does not apply to lightweight templates, generics, and other first-class language features. It _does_ apply to DSL implementations and heavyweight template designs that are not already provided by a 3rd party library. Even then, please consider the above path instead.

The above, while restrictive, flattens the project ecosystem down to human-readable and fungible parts. If the worst happens, generated code can still be hotfixed/hacked back into service, without having to fuss with generator internals.

I can guarantee that if you start looking at random, you will find the right line within the 43 guesses

This item has no comments currently.