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 Offline
    honey the codewitchH Offline
    honey the codewitch
    wrote on last edited by
    #1

    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 P C F D 15 Replies 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
      Maximilien
      wrote on last edited by
      #2

      kinda agree.

      I'd rather be phishing!

      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.

        P Offline
        P Offline
        PIEBALDconsult
        wrote on last edited by
        #3

        I agree. I insert a comment at the top: /* This is a generated file, any modifications may be lost. */

        honey the codewitchH 1 Reply Last reply
        0
        • P PIEBALDconsult

          I agree. I insert a comment at the top: /* This is a generated file, any modifications may be lost. */

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

          absolutely. typically the CodeDomProvider framework will even generate one for you =)

          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.

            C Offline
            C Offline
            CodeWraith
            wrote on last edited by
            #5

            So it's you who torments the rest of the world with half baked, unorthodox rule engines. Has any one of these ever worked to begin with or sucessfully survived all attempts to derail it by clueless bosses with ever crazier new rules? The next step then would be a half baked rule engine with also half baked modifications to the (unorthodox and uncommented) generated code, which of course may never be generated again. Excellent. What a joy to see how the will to live is drained from those who have to maintain that thing, once Dr. Frankenfurter was done half baking his rule engine has left in search for new gullible victims. :-)

            I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.

            honey the codewitchH D 2 Replies Last reply
            0
            • C CodeWraith

              So it's you who torments the rest of the world with half baked, unorthodox rule engines. Has any one of these ever worked to begin with or sucessfully survived all attempts to derail it by clueless bosses with ever crazier new rules? The next step then would be a half baked rule engine with also half baked modifications to the (unorthodox and uncommented) generated code, which of course may never be generated again. Excellent. What a joy to see how the will to live is drained from those who have to maintain that thing, once Dr. Frankenfurter was done half baking his rule engine has left in search for new gullible victims. :-)

              I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.

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

              In my defense I've only ever made a rule engine that generated code once, and it was used for years, and it worked. You maintained the damn thing by maintaining the rule specs, not the code. The code generation could alter all three tiers (SQL schema, middleware XSD and code, and front end admin UI stuff (non admin pages were not generated because that's stupid in practice, but it *did* expose functionality to the front-end that the front end could use in the form of rule aware javascript and html widgets) I generate mostly state machine code and things like parse tables. Those will always be incomprehensible and if you try to manually modify the state machine you deserve to be chased with a ball peen hammer.

              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.

                F Offline
                F Offline
                Forogar
                wrote on last edited by
                #7

                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.

                1 Reply Last reply
                0
                • C CodeWraith

                  So it's you who torments the rest of the world with half baked, unorthodox rule engines. Has any one of these ever worked to begin with or sucessfully survived all attempts to derail it by clueless bosses with ever crazier new rules? The next step then would be a half baked rule engine with also half baked modifications to the (unorthodox and uncommented) generated code, which of course may never be generated again. Excellent. What a joy to see how the will to live is drained from those who have to maintain that thing, once Dr. Frankenfurter was done half baking his rule engine has left in search for new gullible victims. :-)

                  I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.

                  D Offline
                  D Offline
                  Daniel Pfeffer
                  wrote on last edited by
                  #8

                  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.

                  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.

                    D Offline
                    D Offline
                    Dan Neely
                    wrote on last edited by
                    #9

                    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

                    honey the codewitchH 1 Reply Last reply
                    0
                    • D Dan Neely

                      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

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

                      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.

                      1 Reply Last reply
                      0
                      • D Daniel Pfeffer

                        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.

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

                        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 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.

                          Kornfeld Eliyahu PeterK Offline
                          Kornfeld Eliyahu PeterK Offline
                          Kornfeld Eliyahu Peter
                          wrote on last edited by
                          #12

                          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

                          "It never ceases to amaze me that a spacecraft launched in 1977 can be fixed remotely from Earth." ― Brian Cox

                          honey the codewitchH 1 Reply Last reply
                          0
                          • Kornfeld Eliyahu PeterK Kornfeld Eliyahu Peter

                            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

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

                            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.

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