Style and form in generated code

[honey the codewitch]

Nice. I used to write tools like that back when i was doing this professionally. Part of me misses it. Part of me is glad i don't have to deal with that crap anymore. :laugh:

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

[dywanex192]

.

[Sander Rossel]

Just make sure to add some attributes so designers know not to check the code for style issues. I think the GeneratedCodeAttribute does that in .NET. Nothing is worse than having some blue information and yellow warning icons for stuff you can't change X|

Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly

[honey the codewitch]

Fair enough. I always mean to but sometimes I forget. Lately I've been pretty hardcore about warnings and documentation but I forget those silly messages.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

[honey the codewitch]

The thing is, I don't know that I can easily add that feature. All this really is is some code to help you write code generators. It's not a code generator. It's an attempt to make the codedom not kill your fingers, and actually make it vaguely readable.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

[Sander Rossel]

If you generate code that I can't touch, but that will sit around in my project you owe it to all that's good and holy to add that attribute. God kills a puppy every time you generate production code without that attribute :(

Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly

[honey the codewitch]

That's true but this is not a code generator. It's just a wrapper for the codeDom. It's up to the user of it to add that attribute

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

[Mycroft Holmes]

I gave up many years ago attempting to write a silver bullet code generator. I use a start and end token, anything inside the tokens is fair game for the ClassBuilder, if I need to customise some code I move it outside the tokens. I find this an excellent compromise that allows ClassBuilder to do the grunt work and I only have to do the custom stuff. I run screaming from any proposed rules engine solution although I have written a number of them over the years I have never been satisfied with the results.

Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP

[Marc Clifton]

I agree, except that I've never experienced a code generation tool that actually handles all the edge cases, which means I end up generating the code once and manually tweaking it as needed. Yeah, that's bad I suppose, but what are you going to do when years later nobody can even figure out what the tool was that generated to code to begin with? :~

Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX Calls

[Stuart Dootson]

I've had experiences with parser code generated by [Antlr](https://www.antlr.org/) (version 2, not the current one) and controller code generated from Simulink diagrams. My main feels from those are: 1. Comments documenting traceability from the source specification to the generated code are very useful when debugging (which I've had to do in both cases) 2. Use variable names that reflect the names used in the source specification, for similar reasons as 1. 3. Personally, I'd prefer not to see `goto`s, because I find they make code comprehension harder, but that's just *my* opinion. And no, I never modify generated code - that's never a sustainable route to take.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

[honey the codewitch]

That's fair, although compilable state machines basically require gotos as they become spaghetti that's impossible to represent with nested loops and such. What I do in my FSM code, is I created code to render state machine graphs as jpgs so I can see them. Each state is labeled. Each jump label matches the label in the diagram. Each arrow in the diagram matches a jump. It's about the best one can hope for.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

[Stuart Dootson]

Fair enough - the other approach for finite automata (from my fading memory of using Yacc, back in the day) is to use a table driven approach, which is even less scrutable than using `goto`s! Antlr, as it generates recursive descent parsers, is pretty well suited to the 'generate structured code' thing, although I think the later versions generate table driven code for improved performance...

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

[honey the codewitch]

Agreed. I use table driven code generally for the same reason ANTLR does - performance. I've noticed that large state machines run faster table driven than compiled. Some of my projects however, generate both. =) I've tried generating compiled parsers as well, and the performance was a dog. I won't write code that generates those anymore. It's like giving someone a lit firecracker - there's nothing good that will come of it and it will blow up in someone's face.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

[kalberts]

I learned table driven state machines by studying the ITU X.225 Session Layer Protocol. I don't think this can be understood by any other technique! It is extremely complex, but the tables give you a fast way to see what happens next, in any state, when whatever happens. Most of all: You become aware of all protocol error situations in a very lucid way. I was so fascinated by this extremely compact, extremely complete, extremely fast lookup way of describing a protocol, and I have never understood why not "everybody" uses this format. Well, I guess I do know... Almost all programmers I have met prefer to delay error handling, robustness, exceptional cases until the main body of the code is in place. "Agile" insistutionalizes this approach: Defer whatever can be deferred, get "something" up and running as fast as possible. Developing state tables forces you to consider all possibilites, handle all cases (or at least: An empty square means "This error is not yet being handled, or it is fatal". Thorough understanding of what you are developing is more or less a contradiction to agile philosophy.

[Gary Wheeler]

Hmm. I only have one case in recent memory of generated code where I wrote the generator. I agree that comments are not terribly useful, as long as you're always using the generator to update the generated code. In the past, I've had the generator include the original text as a comment in the generated stuff as a debugging aid for the generator itself. Constants depend upon the purpose of the generator and the generated code. In some cases it's simpler to have the compiler compute constant values at compile time than it is to have the generator compute them. I've not had [what I consider] a reasonable use for goto _label_ in the last 20 years or so. That said, I do use break or continue fairly regularly.

honey the codewitch wrote:

ow many of you hate me for this, and who agrees with me here?

Don't worry. We have burned a heretic at the stake in days and days [stomps a smoldering ember at his feet].

Software Zen: delete this;

[honey the codewitch]

Gary Wheeler wrote:

We have burned a heretic at the stake in days and days

:laugh: I use gotos for two reasons 1) state machine code, although these days i typically do table driven so it's moot. But while loops and such aren't really feasible. I could bore you with some pictures as to why. However, for all my state machines i can generate pretty pictures that graphically and precisely reflect the code that is generated to the point where you can directly see how they line up. The visual aid really helps. 2) To get around a codeDom limitation - it doesn't have break. So I've had to refactor my reference implementations of the code I intend to generate to remove breaks. I've done crazy things like set my i var inside a for loop to int.MaxValue-1 (whatever that works out to be) in my generated code to break the loop. If I can't use a for loop, and I must break, I'll use a goto.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

[honey the codewitch]

I render my state machines to images. As seen in the article images here: How to Build a Regex Engine in C#[^] That's also how I learned how these FA state machines work. These visual aids are invaluable. God bless GraphViz. =) I use it under the hood for my state machine rendering code. It helps when I'm debugging them immensely.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

[kalberts]

(These figures don't display in Firefox ... Why am I still using that browser? IE11 can handle them, though!) Sure, blobs and arrows are nice for getting an overview. But only up to a certain complexity. I don't think I would want to learn X.225 from a complete blobs and arrows diagram for the full protocol. Maybe for smaller subsets of the state transitions. In such diagrams, you usually do not get an overview of error handling; they are definitely best suited for a more or less linear state flow and events that are "well behaved", they come as expected. Obviously you have alternate linear sequences from an initial to a final state, and loopbacks, but in the sample figures there is not one case of crossing lines (transitions). in a large model where you have defined various sorts of exception/error handling, you couldn't hope for avoiding crossing lines. So you simplify the logic, providing a general introduction to the FSM through the figures. But to see the full works, you must go to the state tables. Actually, I was working on a GraphViz plugin for VisualStudio to make such figures based on the state tables, handled by another plugin, for editing table squares index by state/event, specifying entry conditions (predicates), actions, and next states, as well as tables of predicate definitions and action routines, covering all the requiremets for the X.225 state machine. I had the design ready for a selection mechanism for graphing a selected subset of the state transitions, which labels to add to the graph etc.; your project could contain multiple graph descriptions for different purposes. This was primarity for teaching FSM programming at a Tech University. But then I switched jobs, so the project was never completed. Maybe I should pick it up as a hobby project. Would be fun!

[honey the codewitch]

I ran into that problem too (in chrome) - turn off your ad blocker for this site (adds are minimal, unobtrusive here) That FSM thing would be fun. I've been kind of doing a subset of it for character based machines. Although I want to extend it to handle the state machines in LR parser tables. Those are PDAs so they're a bit more complicated - they have a stack.

When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.

[MSBassSinger]

I am updating a NuGet package that, as an ancillary function, generates SQL and C# code. I tend to agree with your post, but do have a couple of deviations.

Quote:

it's almost always stupid to try to support generated code that a user has modified

"Almost" being the key word here. By generating stored procedures, C# POCO classes, and C# manager/factory classes that tie the SPs and POCO instance creation together, I save the developer a lot of time on the initial creation of the classes and SQL code. If the developer wishes to change them to suit his or her particular approach, it still takes less time than writing the code themselves from scratch, especially with "find and replace" in the IDE. The only downside is if the developer has so many changes as to have to re-generate the SPs, POCOs, or factory classes, then any manual edits have to be redone. Good planning can avoid most, if not all, of that.

Quote:

Commenting the generated code is pointless

I find it useful to add comments in my generated C# code so 1) Intellisense can show brief explanations of methods and parameters, 2) The user can understand why I coded something the way I did. I find it useful to add comments to my generated T-SQL code so the developer understands why I coded that way, and what value there is to it. That said, yes it does take more of my time, but I want to give any users my NuGet packages have some additional info. I even do sample WinForms apps and a readme Word document to assist. Senior developers might not need them, but less experienced developers might benefit.