Do you use code generation tools? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

Closed 3 months ago.

Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.

Do you use code-generation tools (aside from those used to generate proxies and from designers built-in to visual studio)?

What part(s) of your application do you generate?

Do you typically roll your own generator? If so, what type of generator do you write (asp templates, coddom etc.). If not, what 3rd party tools do you use?

I am currently working on a few different projects wich all use a custom code-generator that handles everything from generating the database structure, business entities, DAL, and BLL. I am curious about other peoples experiences are with these kinds of tools.

Answer 1

Home-brewed code generators work great for building unittest cases from end-user spreadsheets that contain examples of how it should work.

See Tooling to Build Test Cases for one example.

Answer 2

We have an in-house built code generator that takes care of database access. One writes stored procedures and gets corresponding methods abstracted in a gateway class.

We also generate web services in order to properly interface with Flash -- i.e. handling exception in a sane manner.

Finally we have an exception generator that takes away the drudgery of exception best practices (tons of constructors, etc...)

Answer 3

I've used one to generate serializable data objects which could be reformed across different platforms (windows, linux, solaris, mac, bsd, etc). It was an in-house solution.

Answer 4

I started rolling my own generators (data access, sprocs, etc) back when I was doing classic asp work (circa 2001). I slowly moved to CodeSmith, since it was much easier to deal with. I was still primarily just generating all the Data Access layer type stuff (including sprocs) for my .NET code.

A couple years ago, I made the jump from Macro Code Generation (i.e. CodeSmith) to Micro Code Generation.

The difference is that with CodeSmith I was generating huge swaths of code for my app, all generic, and all at once. This became problematic for edge cases and regenerating when changing the source for the template (i.e. table structure). I also ran into cases where there was a high inventory of carrying code that I wasn't using, but was generated from my template. Did all those methods work? Maybe, maybe not. Going in and cleaning up the generated code would have been a huge amount of work (i.e. after more than a year on the same codebase).

Micro Code Generation, in contrast, allows me to generate exactly the classes I need, in exactly the right scenario I want. The primary tool I use to do this is ReSharper. The way I do this is by writing my unit tests before writing my production code. In that scenario, ReSharper uses my Unit Test as a template to auto-generate the skeleton for the production code. Then it's just a matter of filling in the blanks.

For Data Access, I'm no longer generating anything. I've found that a good O/R M replaces everything I used to put in my data access layer (i.e. NHibernate). Given that, I will never write or generate another data access layer in my life (I refuse to).

Plus, I get the benefits of having a large unit test suite, among other things

Answer 5

Since Fog Creek Software's in-house language, Wasabi, has compile-time code generators built in, we use them to automatically create the meat of our entity classes that map to database tables. So instead of writing a class with a dozen different properties and methods, we can just write:

<ActiveRecord("Kiwi")> _
Class CKiwi
End Class

and CKiwi will have Load(ix As Int32), Commit(), and fields/properties for every column defined in its underlying schema for the Kiwi table. It keeps us from having to have huge O/R M libraries, but still allows us to quickly add a table to our products.

Answer 6

At a previous employer, we had a home-grown VB.NET application that would turn an XML Schema Definition file (XSD) into a static C++ library. This made it much easier to work with C++ data types (bool, std::string, etc.), and all of the interesting XML code was hidden inside of these generated classes.