Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
CODE PROJECT For Those Who Code
  • Home
  • Articles
  • FAQ
Community
  1. Home
  2. The Lounge
  3. Style and form in generated code

Style and form in generated code

Scheduled Pinned Locked Moved The Lounge
designai-codingbusinesstutorialquestion
42 Posts 20 Posters 4 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • honey the codewitchH honey the codewitch

    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.

    J Offline
    J Offline
    Jorgen Andersson
    wrote on last edited by
    #14

    But sharing is caring. ;-)

    Wrong is evil and must be defeated. - Jeff Ello

    honey the codewitchH 1 Reply Last reply
    0
    • J Jorgen Andersson

      But sharing is caring. ;-)

      Wrong is evil and must be defeated. - Jeff Ello

      honey the codewitchH Offline
      honey the codewitchH Offline
      honey the codewitch
      wrote on last edited by
      #15

      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.

      J 1 Reply Last reply
      0
      • honey the codewitchH honey the codewitch

        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.

        J Offline
        J Offline
        Jorgen Andersson
        wrote on last edited by
        #16

        You see, that's what I mean.:)

        Wrong is evil and must be defeated. - Jeff Ello

        D 1 Reply Last reply
        0
        • honey the codewitchH honey the codewitch

          I almost as a matter of course involve code generation in my larger projects. So that means I'm dealing with a lot of generated code. Typically, I don't design my generated code for manual modification. I design the tool that generates it to be customizable. Ergo, the tool will make the code do what you want. Change the tool parameters to change the code but leave the code alone. The reason being is it's almost always stupid to try to support generated code that a user has modified and for extremely complicated code, like parse tables, dfa tables, or business rule tables that have a lot of conditionals and branching. So the code is a black box. And because of *that* I throw a lot of traditional design assumptions out the window, or go meta with them. Comments are an example: Commenting the generated code is pointless. Commenting the code that generates the code is project-critical Constants are another example. It doesn't matter if you use hard coded values in your generated code if the values are const in the code that generates *it*. Generating private constants just adds to code size with not much upside. The exception is long constant strings. And gotos are totally acceptable, especially in state machine code, and in the absence of cross language CodeDom loop break statements. (CodeDom only supports for() and no while() nor do while(), no break, no continue. How many of you hate me for this, and who agrees with me here? :cool: I'm just curious.

          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.

          realJSOPR Offline
          realJSOPR Offline
          realJSOP
          wrote on last edited by
          #17

          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

          honey the codewitchH 1 Reply Last reply
          0
          • realJSOPR realJSOP

            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

            honey the codewitchH Offline
            honey the codewitchH Offline
            honey the codewitch
            wrote on last edited by
            #18

            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.

            1 Reply Last reply
            0
            • J Jorgen Andersson

              You see, that's what I mean.:)

              Wrong is evil and must be defeated. - Jeff Ello

              D Offline
              D Offline
              dywanex192
              wrote on last edited by
              #19

              .

              1 Reply Last reply
              0
              • honey the codewitchH honey the codewitch

                I almost as a matter of course involve code generation in my larger projects. So that means I'm dealing with a lot of generated code. Typically, I don't design my generated code for manual modification. I design the tool that generates it to be customizable. Ergo, the tool will make the code do what you want. Change the tool parameters to change the code but leave the code alone. The reason being is it's almost always stupid to try to support generated code that a user has modified and for extremely complicated code, like parse tables, dfa tables, or business rule tables that have a lot of conditionals and branching. So the code is a black box. And because of *that* I throw a lot of traditional design assumptions out the window, or go meta with them. Comments are an example: Commenting the generated code is pointless. Commenting the code that generates the code is project-critical Constants are another example. It doesn't matter if you use hard coded values in your generated code if the values are const in the code that generates *it*. Generating private constants just adds to code size with not much upside. The exception is long constant strings. And gotos are totally acceptable, especially in state machine code, and in the absence of cross language CodeDom loop break statements. (CodeDom only supports for() and no while() nor do while(), no break, no continue. How many of you hate me for this, and who agrees with me here? :cool: I'm just curious.

                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 RosselS Offline
                Sander RosselS Offline
                Sander Rossel
                wrote on last edited by
                #20

                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 codewitchH 2 Replies Last reply
                0
                • Sander RosselS 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 codewitchH Offline
                  honey the codewitchH Offline
                  honey the codewitch
                  wrote on last edited by
                  #21

                  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.

                  1 Reply Last reply
                  0
                  • Sander RosselS 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 codewitchH Offline
                    honey the codewitchH Offline
                    honey the codewitch
                    wrote on last edited by
                    #22

                    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 RosselS 1 Reply Last reply
                    0
                    • honey the codewitchH 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 RosselS Offline
                      Sander RosselS Offline
                      Sander Rossel
                      wrote on last edited by
                      #23

                      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 codewitchH 1 Reply Last reply
                      0
                      • Sander RosselS 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 codewitchH Offline
                        honey the codewitchH Offline
                        honey the codewitch
                        wrote on last edited by
                        #24

                        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.

                        1 Reply Last reply
                        0
                        • honey the codewitchH honey the codewitch

                          I almost as a matter of course involve code generation in my larger projects. So that means I'm dealing with a lot of generated code. Typically, I don't design my generated code for manual modification. I design the tool that generates it to be customizable. Ergo, the tool will make the code do what you want. Change the tool parameters to change the code but leave the code alone. The reason being is it's almost always stupid to try to support generated code that a user has modified and for extremely complicated code, like parse tables, dfa tables, or business rule tables that have a lot of conditionals and branching. So the code is a black box. And because of *that* I throw a lot of traditional design assumptions out the window, or go meta with them. Comments are an example: Commenting the generated code is pointless. Commenting the code that generates the code is project-critical Constants are another example. It doesn't matter if you use hard coded values in your generated code if the values are const in the code that generates *it*. Generating private constants just adds to code size with not much upside. The exception is long constant strings. And gotos are totally acceptable, especially in state machine code, and in the absence of cross language CodeDom loop break statements. (CodeDom only supports for() and no while() nor do while(), no break, no continue. How many of you hate me for this, and who agrees with me here? :cool: I'm just curious.

                          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.

                          M Offline
                          M Offline
                          Mycroft Holmes
                          wrote on last edited by
                          #25

                          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

                          1 Reply Last reply
                          0
                          • honey the codewitchH honey the codewitch

                            I almost as a matter of course involve code generation in my larger projects. So that means I'm dealing with a lot of generated code. Typically, I don't design my generated code for manual modification. I design the tool that generates it to be customizable. Ergo, the tool will make the code do what you want. Change the tool parameters to change the code but leave the code alone. The reason being is it's almost always stupid to try to support generated code that a user has modified and for extremely complicated code, like parse tables, dfa tables, or business rule tables that have a lot of conditionals and branching. So the code is a black box. And because of *that* I throw a lot of traditional design assumptions out the window, or go meta with them. Comments are an example: Commenting the generated code is pointless. Commenting the code that generates the code is project-critical Constants are another example. It doesn't matter if you use hard coded values in your generated code if the values are const in the code that generates *it*. Generating private constants just adds to code size with not much upside. The exception is long constant strings. And gotos are totally acceptable, especially in state machine code, and in the absence of cross language CodeDom loop break statements. (CodeDom only supports for() and no while() nor do while(), no break, no continue. How many of you hate me for this, and who agrees with me here? :cool: I'm just curious.

                            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.

                            M Offline
                            M Offline
                            Marc Clifton
                            wrote on last edited by
                            #26

                            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

                            1 Reply Last reply
                            0
                            • honey the codewitchH honey the codewitch

                              I almost as a matter of course involve code generation in my larger projects. So that means I'm dealing with a lot of generated code. Typically, I don't design my generated code for manual modification. I design the tool that generates it to be customizable. Ergo, the tool will make the code do what you want. Change the tool parameters to change the code but leave the code alone. The reason being is it's almost always stupid to try to support generated code that a user has modified and for extremely complicated code, like parse tables, dfa tables, or business rule tables that have a lot of conditionals and branching. So the code is a black box. And because of *that* I throw a lot of traditional design assumptions out the window, or go meta with them. Comments are an example: Commenting the generated code is pointless. Commenting the code that generates the code is project-critical Constants are another example. It doesn't matter if you use hard coded values in your generated code if the values are const in the code that generates *it*. Generating private constants just adds to code size with not much upside. The exception is long constant strings. And gotos are totally acceptable, especially in state machine code, and in the absence of cross language CodeDom loop break statements. (CodeDom only supports for() and no while() nor do while(), no break, no continue. How many of you hate me for this, and who agrees with me here? :cool: I'm just curious.

                              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.

                              S Offline
                              S Offline
                              Stuart Dootson
                              wrote on last edited by
                              #27

                              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 codewitchH 1 Reply Last reply
                              0
                              • S 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 codewitchH Offline
                                honey the codewitchH Offline
                                honey the codewitch
                                wrote on last edited by
                                #28

                                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.

                                S 1 Reply Last reply
                                0
                                • honey the codewitchH 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.

                                  S Offline
                                  S Offline
                                  Stuart Dootson
                                  wrote on last edited by
                                  #29

                                  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 codewitchH K 2 Replies Last reply
                                  0
                                  • S 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 codewitchH Offline
                                    honey the codewitchH Offline
                                    honey the codewitch
                                    wrote on last edited by
                                    #30

                                    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.

                                    1 Reply Last reply
                                    0
                                    • S 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

                                      K Offline
                                      K Offline
                                      kalberts
                                      wrote on last edited by
                                      #31

                                      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.

                                      honey the codewitchH 1 Reply Last reply
                                      0
                                      • honey the codewitchH honey the codewitch

                                        I almost as a matter of course involve code generation in my larger projects. So that means I'm dealing with a lot of generated code. Typically, I don't design my generated code for manual modification. I design the tool that generates it to be customizable. Ergo, the tool will make the code do what you want. Change the tool parameters to change the code but leave the code alone. The reason being is it's almost always stupid to try to support generated code that a user has modified and for extremely complicated code, like parse tables, dfa tables, or business rule tables that have a lot of conditionals and branching. So the code is a black box. And because of *that* I throw a lot of traditional design assumptions out the window, or go meta with them. Comments are an example: Commenting the generated code is pointless. Commenting the code that generates the code is project-critical Constants are another example. It doesn't matter if you use hard coded values in your generated code if the values are const in the code that generates *it*. Generating private constants just adds to code size with not much upside. The exception is long constant strings. And gotos are totally acceptable, especially in state machine code, and in the absence of cross language CodeDom loop break statements. (CodeDom only supports for() and no while() nor do while(), no break, no continue. How many of you hate me for this, and who agrees with me here? :cool: I'm just curious.

                                        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.

                                        G Offline
                                        G Offline
                                        Gary Wheeler
                                        wrote on last edited by
                                        #32

                                        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 codewitchH 1 Reply Last reply
                                        0
                                        • G 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 codewitchH Offline
                                          honey the codewitchH Offline
                                          honey the codewitch
                                          wrote on last edited by
                                          #33

                                          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.

                                          1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          • Login

                                          • Don't have an account? Register

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • World
                                          • Users
                                          • Groups