Codebook - II
| Pages | ||
| from | to | time |
| 86 | 87 | 0:52 |
| Was | ||
| Wiederholung Bezeichnungskonventionen, Nachbau Programm, Variablenliste | ||
2 Kommentare - Kommentar verfassen - 0 Trackbacks
steppenhund - 31. Mai, 11:10
Also her mit dem Programm! Begutachten lassen! :)
Und welche Namenskonventionen werden beachtet?
Interessante Seite ist hier:
http://blogs.msdn.com/ericgu/archive/2004/01/19/60315.aspx
Interessant auch, dass es keine offiziellen Guidelines gibt wie etwa bei Java. (Da sind die Sun guidelines doch schlagend.)
Besonders interessant dieser Kommentar:
Tuesday, January 20, 2004 8:53 AM by Shawn
# re: C# Coding Guidelines
RE: the iDesign doc, I have a few comments and some questions.
1.4. "Prefix private member variables with m_". I dissagree. I agree with all his other naming conventions. However, in private members, I prefix with _ or they are all lower case. Again, its a standard so if everyone agrees than there is no confusion. I've never experienced or witnessed any. But m_ is ugly.
1.22. "Always place an open curly brack ({) on a new line.". Nope. I personally find code much easier to read when the brace is at the end of the first line rather than a new line. As lost as the code is neatly indented I've never experienced trouble determining where it originated nor has anyone who ever read my code. I can't stand to see too much white space and an open brace really creates white space. Of course, I can't stand to sufficate, either. I have a very strict standard I adhere to that revolves mostly around balancing the right amount of breathing room and content.
2.4. "Avoid Files with over 500 lines." While I can see some merit in that, sometimes it is just not feasible to do so. I've heard people say that it should then be refactored, but there are some occasions where a file will just get to be large. It should be avoided if possible. And while yes, by breaking everything up to different classes can greatly reduce the number of lines, there are things that can't be broken up. For example, I create custom WebControls. Some of them can't be broken up and will inevitably take more than 500 lines (in my case, even 2,000 lines.
2.5. "Avoid methods with over 25 lines." Again. a good thing to strive to achieve, but it isn't always feasible. I have a method that needs to do do some prep, make a few database calls, do some more prep and then return. While most of the method is already broken up into other methods for general re-use, this method in particular can be no more reduce and is still well over 25 lines. I always strive for the least amount of code but pleny of times I've found, it's not always possible. Back to custom WebControls. Just to render a custom Calendar, even when I severely break up the functions for internal re-use, is still over 100 lines of which are necessary to be there. Okay, "refactor" you say. Not always possible. Time, budget, etc.
2.6. "Avoid using methods with over 5 arguments. Use structures for passing multiple arguments." Okay, I see that many API's do this. Is this standard practice? I've always opted for being able to see the argument list in the function defenition so I know what to pass. Would a structure be as easy or easier? Because then I would need to add more lines of code (on top of the 25 lines requirement) just to pass into another function. What do you say about this, I have no real thoughts.
2.22... I have no thoughts, but I don't know I agree or not. Perhaps someone can elaborate why. What advantage is there, except that sometimes (but not always) you may need to use that result again somewhere in which case I understand, but is this just a matter of always preparing for that?
2.27... I learned something new with this one. Never thought of that before but it makes sense. Didn't know it can be done.
2.42. "Avoid events as interface members." I have an ADO.NET wrapper class that has the ability to load plugins for debugging purposes (has saved countless hundred of man hours to just plugin get feedback and plugout when done). In order for this to work, I need to have the interface define some events that the plugin will bind to. The DAL does not reference a plugin but the plugin only knows about the interface and not the wrapper object itself. So in this case, this rule has to be broken.
2.52... not always feasible. I used a structure for a binary datatype I created that encapsulates 8, 16, 32, or 64 bit binary operations and overloaded all the members but I couldn't find an operator for the ROR/ROL so I had to provide methods. Search planet-source-code in the .NET second for "Shawn Bullock" if you're interested in seeing it.
... no more comments in this post. Everying in sections 1 and 2 not mentioned I agree with an practice mostly.
Ich habe mir die iDesign Standards angesehen. Schauen ganz gut aus. Man muss den Link beim ersten Posting iDesign anklicken. Auf der rechten Seite befinden sich die entsprechenden Downloads.
Thanks,
Shawn
Und welche Namenskonventionen werden beachtet?
Interessante Seite ist hier:
http://blogs.msdn.com/ericgu/archive/2004/01/19/60315.aspx
Interessant auch, dass es keine offiziellen Guidelines gibt wie etwa bei Java. (Da sind die Sun guidelines doch schlagend.)
Besonders interessant dieser Kommentar:
Tuesday, January 20, 2004 8:53 AM by Shawn
# re: C# Coding Guidelines
RE: the iDesign doc, I have a few comments and some questions.
1.4. "Prefix private member variables with m_". I dissagree. I agree with all his other naming conventions. However, in private members, I prefix with _ or they are all lower case. Again, its a standard so if everyone agrees than there is no confusion. I've never experienced or witnessed any. But m_ is ugly.
1.22. "Always place an open curly brack ({) on a new line.". Nope. I personally find code much easier to read when the brace is at the end of the first line rather than a new line. As lost as the code is neatly indented I've never experienced trouble determining where it originated nor has anyone who ever read my code. I can't stand to see too much white space and an open brace really creates white space. Of course, I can't stand to sufficate, either. I have a very strict standard I adhere to that revolves mostly around balancing the right amount of breathing room and content.
2.4. "Avoid Files with over 500 lines." While I can see some merit in that, sometimes it is just not feasible to do so. I've heard people say that it should then be refactored, but there are some occasions where a file will just get to be large. It should be avoided if possible. And while yes, by breaking everything up to different classes can greatly reduce the number of lines, there are things that can't be broken up. For example, I create custom WebControls. Some of them can't be broken up and will inevitably take more than 500 lines (in my case, even 2,000 lines.
2.5. "Avoid methods with over 25 lines." Again. a good thing to strive to achieve, but it isn't always feasible. I have a method that needs to do do some prep, make a few database calls, do some more prep and then return. While most of the method is already broken up into other methods for general re-use, this method in particular can be no more reduce and is still well over 25 lines. I always strive for the least amount of code but pleny of times I've found, it's not always possible. Back to custom WebControls. Just to render a custom Calendar, even when I severely break up the functions for internal re-use, is still over 100 lines of which are necessary to be there. Okay, "refactor" you say. Not always possible. Time, budget, etc.
2.6. "Avoid using methods with over 5 arguments. Use structures for passing multiple arguments." Okay, I see that many API's do this. Is this standard practice? I've always opted for being able to see the argument list in the function defenition so I know what to pass. Would a structure be as easy or easier? Because then I would need to add more lines of code (on top of the 25 lines requirement) just to pass into another function. What do you say about this, I have no real thoughts.
2.22... I have no thoughts, but I don't know I agree or not. Perhaps someone can elaborate why. What advantage is there, except that sometimes (but not always) you may need to use that result again somewhere in which case I understand, but is this just a matter of always preparing for that?
2.27... I learned something new with this one. Never thought of that before but it makes sense. Didn't know it can be done.
2.42. "Avoid events as interface members." I have an ADO.NET wrapper class that has the ability to load plugins for debugging purposes (has saved countless hundred of man hours to just plugin get feedback and plugout when done). In order for this to work, I need to have the interface define some events that the plugin will bind to. The DAL does not reference a plugin but the plugin only knows about the interface and not the wrapper object itself. So in this case, this rule has to be broken.
2.52... not always feasible. I used a structure for a binary datatype I created that encapsulates 8, 16, 32, or 64 bit binary operations and overloaded all the members but I couldn't find an operator for the ROR/ROL so I had to provide methods. Search planet-source-code in the .NET second for "Shawn Bullock" if you're interested in seeing it.
... no more comments in this post. Everying in sections 1 and 2 not mentioned I agree with an practice mostly.
Ich habe mir die iDesign Standards angesehen. Schauen ganz gut aus. Man muss den Link beim ersten Posting iDesign anklicken. Auf der rechten Seite befinden sich die entsprechenden Downloads.
Thanks,
Shawn
books and more - 31. Mai, 21:51
Lieber Herr Steppenhund,
vielen Dank für diese höchst nützlichen Informationen! Programme & anderes gibt es allerdings noch nicht wirklich vorzuzeigen, dazu bin ich sozusagen noch zu frisch dabei! In Sachen Bezeichnungskonventionen versuche ich mir vor allem klarzumachen, wie das Buch dabei vorgeht, das ich gerade durcharbeite. Allerdings hängen die noch der 'ungarischen Notation' an, die wohl - zumindest im .NET-Umfeld - aus der Mode scheint; mit nachvollziehbaren Gründen.
So. Nach dem Sport gehört der Abend jetzt wieder der edlen Kunst des Codierens :-)
Schöne Pfingsten wünscht
B&M
vielen Dank für diese höchst nützlichen Informationen! Programme & anderes gibt es allerdings noch nicht wirklich vorzuzeigen, dazu bin ich sozusagen noch zu frisch dabei! In Sachen Bezeichnungskonventionen versuche ich mir vor allem klarzumachen, wie das Buch dabei vorgeht, das ich gerade durcharbeite. Allerdings hängen die noch der 'ungarischen Notation' an, die wohl - zumindest im .NET-Umfeld - aus der Mode scheint; mit nachvollziehbaren Gründen.
So. Nach dem Sport gehört der Abend jetzt wieder der edlen Kunst des Codierens :-)
Schöne Pfingsten wünscht
B&M
Trackback URL:
http://booksandmore.twoday.net/stories/codebook-ii/modTrackback