|
No one claimed that she's a good witch
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I'm certainly not. =D
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.
|
|
|
|
|
But sharing is caring.
|
|
|
|
|
I've just developed a little class to greatly abbreviate building CodeDOM trees. I'll probably publish a Tip & Trick on it once I've used it for what I'm using it for. I like to dogfood things before I post them if possible.
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.
|
|
|
|
|
You see, that's what I mean.
|
|
|
|
|
|
I concur - do what you like in generated code - it's generated, not for reading or modifying!
Just don't forget the big "Keep your stinking paws of this code you dirty ape!" notice at the top!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
As long as the generation tool is capable enough that I never have to hand edit its results I really don't care what all is inside the sausage factory. When the generation falls short and I need to hand-edit the results or worse write a fix tool, the nastier the generated output is the more I'll hate the guilty party.
The flip side is when it is simultaneously simple enough in scope and capable enough in function to ingest my modifications without problem for round trip modifications (*cough*WinForm Designer*cough*) that I'll fall in love and still be mourning not having anything equivalent in newer projects (web, wpf, uwp, android, ios) years later.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Round tripping was cool even if it wasn't perfect. It was the (almost) perfect solution to providing VB6 style designer functionality without making it opaque like VB6 did.
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.
|
|
|
|
|
I'm too do a lot of generated code (mostly JS as today)...
The only comment I add is a warning about the changes one thinks to make - futile (especially when I minimize the generated code )...
I try to generate optimized code, so I will use variables for constants I reuse in the code, others will be in-place...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
I try to generate somewhat "portable", optimized code in that order. By portable in .NET i mean code dom constructs that work for most if not all languages. Sometimes that means trading against optimization but it's usually worthwhile if you're making a tool for general purpose use like a parser generator, as long as the hit isn't that big, or somewhere time critical.
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.
|
|
|
|
|
I have an app that generates models and (optionally) viewmodels from stored procs in the seleted database.
In both entity types, I give the user the opportunity to specify namespaces, and base classes (that the generator does not create).
All generated model and viewmodel entities are generated as public partial , and all properties are virtual, with a comment that reminds the coder that the model/viewmodel in question is generated, and that any changes to the generated file(s) will be lost if they regenerate the entity, and further, and changes should be made to either a partial extension file, or inside an deriving class.
For the record, my app does it better than the ado.net project template, and is SIGNIFICANTLY less buggy or finicky. Beyond that, once you click the generate button, it creates all of the entities in less than 5 seconds in a database with over 200 stored procs.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
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.
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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?
|
|
|
|
|
I've had experiences with parser code generated by Antlr (version 2, not the current one) and controller code generated from Simulink diagrams. My main feels from those are:
- 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)
- Use variable names that reflect the names used in the source specification, for similar reasons as 1.
- 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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|