Commenting and Style Differences... [modified - added a final thought]
-
Gary Wheeler wrote:
My inner voice said "not f***ing likely" to that one.
gary, gary... stare at that light colored fuzzy bunny hugs artwork until your inner voice calms down... then all will be fine! all will be good!
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
I've been listening to a mix of Spanish guitar and Keiko Matsui all morning. Thus far, the mellow just ain't happenin'.
Software Zen:
delete this; -
Lack of comments is a direct side-effect of having open source developers start developing for Windows because they "gotta eat, afterall". If you look at most open-source code, you'll see a little/no comments at all because the original author abandoned the code right after he had his first clean compile. His view was "I'm not gonna maintain this code, so I don't need to put comments in it to remind me of why I did things." These same guys are now realizing that free source code doesn't put beans on the table, so they have to work in the Windows world, where they bring their half-assed coding techniques along with them.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001Preach it, brother!
Software Zen:
delete this; -
So - as I delve into more and more C# code, I am noticing something. When reading C++ code, I tended to see that the code tends to be wrapped nicely, broken up into smaller functions, and does not extend too far to the right. However, much of the C# code that I am seeing tends to runs onto the right more often than not, requiring scrolling back and forth just to grok a single line (and I run my monitors at a pretty healthy resolution). Perhaps, some of this can be partially attributed to the longer names of the classes/objects included in the framework (e.g.
AssemblyInformationalVersionAttribute,IDictionaryEnumerator,DataColumnMappingCollection), how things like enums are referenced (e.g.FileShare.ReadWrite), and how certain constructs are written (e.g.foreach( ... ),using( ... )) Even the autogenerated code is much different - when I had an IDL file generated, or generated an empty interface implementation from one, I rarely got really long lines. With C#/.NET, I have seen autogenerated code extend beyond 400(!) characters I cannot help but wonder that when a developer's tools generate code like this, do the developers take that as examples of how it should be done? Commenting is also different - I am seeing much less of it in C# code than in C/C++ code than I used to see. Am I just seeing too many poor examples in one place, or is this really a trend that other former C/C++1 developers are seeing? Or is this just a form of "developer evolution?" Anyway... Peace! 1 This in relevant - developers that only have done C# have little to compare to. Edit: Thank God for things like auto-completion, otherwise all those rapid development claims would be offset by the amount of time it took to
James R. Twine wrote:
Am I just seeing too many poor examples in one place, or is this really a trend that other former C/C++ developers are seeing?
As a former C++ developer who used C# for a couple of years and then ran back to C++, I remember I was extremely annoyed by:
using (MyBigFatClass myBigFatObject = new MyBigFatClass())
{
...
}vs.
MyBigFatClass myBigFatObject;
...Not to mention that many developers wouldn't even bother to use
usingand prefered to manually callDispose, and the most extreme ones kept claiming that even that is harmful, and the GC is smart enough to clean up all the resources. Oh, and the casting... X| And reflection X| X| -
I've been listening to a mix of Spanish guitar and Keiko Matsui all morning. Thus far, the mellow just ain't happenin'.
Software Zen:
delete this;Gary Wheeler wrote:
a mix of Spanish guitar and Keiko Matsui
mixing those will make you ill... one at a time Gary, one at a time! :-D
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
-
So - as I delve into more and more C# code, I am noticing something. When reading C++ code, I tended to see that the code tends to be wrapped nicely, broken up into smaller functions, and does not extend too far to the right. However, much of the C# code that I am seeing tends to runs onto the right more often than not, requiring scrolling back and forth just to grok a single line (and I run my monitors at a pretty healthy resolution). Perhaps, some of this can be partially attributed to the longer names of the classes/objects included in the framework (e.g.
AssemblyInformationalVersionAttribute,IDictionaryEnumerator,DataColumnMappingCollection), how things like enums are referenced (e.g.FileShare.ReadWrite), and how certain constructs are written (e.g.foreach( ... ),using( ... )) Even the autogenerated code is much different - when I had an IDL file generated, or generated an empty interface implementation from one, I rarely got really long lines. With C#/.NET, I have seen autogenerated code extend beyond 400(!) characters I cannot help but wonder that when a developer's tools generate code like this, do the developers take that as examples of how it should be done? Commenting is also different - I am seeing much less of it in C# code than in C/C++ code than I used to see. Am I just seeing too many poor examples in one place, or is this really a trend that other former C/C++1 developers are seeing? Or is this just a form of "developer evolution?" Anyway... Peace! 1 This in relevant - developers that only have done C# have little to compare to. Edit: Thank God for things like auto-completion, otherwise all those rapid development claims would be offset by the amount of time it took to
-
James R. Twine wrote:
Am I just seeing too many poor examples in one place, or is this really a trend that other former C/C++ developers are seeing?
As a former C++ developer who used C# for a couple of years and then ran back to C++, I remember I was extremely annoyed by:
using (MyBigFatClass myBigFatObject = new MyBigFatClass())
{
...
}vs.
MyBigFatClass myBigFatObject;
...Not to mention that many developers wouldn't even bother to use
usingand prefered to manually callDispose, and the most extreme ones kept claiming that even that is harmful, and the GC is smart enough to clean up all the resources. Oh, and the casting... X| And reflection X| X|Nemanja Trifunovic wrote:
Oh, and the casting...
To be fair egregious casting is hardly the preserve of C#, it's more an indication of failed design.
Nemanja Trifunovic wrote:
And reflection
Reflection is damn handy, used conservatively. The alternative is to design away the need for metadata via alternative plumbing or to add the metadata plumbing yourself. Instead you could use whats provided, provided you know the implications. Seems to me that most of the arguments leveled against C# are typically pointing to a mass of bad design and/or implementation by less experienced or less skilled developers, presumably attracted by it's apparent ease. But bad design and implementation are not the preserve of C# by a long shot. There's a reason for competitions for the most obfuscated C code, and god knows I've written some whoppers :D
I'm largely language agnostic
After a while they all bug me :doh:
-
Nemanja Trifunovic wrote:
Oh, and the casting...
To be fair egregious casting is hardly the preserve of C#, it's more an indication of failed design.
Nemanja Trifunovic wrote:
And reflection
Reflection is damn handy, used conservatively. The alternative is to design away the need for metadata via alternative plumbing or to add the metadata plumbing yourself. Instead you could use whats provided, provided you know the implications. Seems to me that most of the arguments leveled against C# are typically pointing to a mass of bad design and/or implementation by less experienced or less skilled developers, presumably attracted by it's apparent ease. But bad design and implementation are not the preserve of C# by a long shot. There's a reason for competitions for the most obfuscated C code, and god knows I've written some whoppers :D
I'm largely language agnostic
After a while they all bug me :doh:
MidwestLimey wrote:
To be fair egregious casting is hardly the preserve of C#, it's more an indication of failed design.
I beg to dissagree. At least before generics, I had to constantly cast down whenever I was using the containers. And even now, just look at all the methods that return
System.Object.MidwestLimey wrote:
Reflection is damn handy, used conservatively.
The only valid use of reflection I am aware of is in the Development tools, like IDE's, compilers, and unit-test frameworks.
-
So - as I delve into more and more C# code, I am noticing something. When reading C++ code, I tended to see that the code tends to be wrapped nicely, broken up into smaller functions, and does not extend too far to the right. However, much of the C# code that I am seeing tends to runs onto the right more often than not, requiring scrolling back and forth just to grok a single line (and I run my monitors at a pretty healthy resolution). Perhaps, some of this can be partially attributed to the longer names of the classes/objects included in the framework (e.g.
AssemblyInformationalVersionAttribute,IDictionaryEnumerator,DataColumnMappingCollection), how things like enums are referenced (e.g.FileShare.ReadWrite), and how certain constructs are written (e.g.foreach( ... ),using( ... )) Even the autogenerated code is much different - when I had an IDL file generated, or generated an empty interface implementation from one, I rarely got really long lines. With C#/.NET, I have seen autogenerated code extend beyond 400(!) characters I cannot help but wonder that when a developer's tools generate code like this, do the developers take that as examples of how it should be done? Commenting is also different - I am seeing much less of it in C# code than in C/C++ code than I used to see. Am I just seeing too many poor examples in one place, or is this really a trend that other former C/C++1 developers are seeing? Or is this just a form of "developer evolution?" Anyway... Peace! 1 This in relevant - developers that only have done C# have little to compare to. Edit: Thank God for things like auto-completion, otherwise all those rapid development claims would be offset by the amount of time it took to
I hold myself to 112 characters per line because that's how many I can fit across an 8.5" sheet of paper using 8 point Courier with half-inch margins. :-D Comments are another matter but I don't think I've improved or worsened since my just-plain-C days.
-
Ironically this is one of the most visually confusing and unreadable posts I've ever seen here. :)
"The pursuit of excellence is less profitable than the pursuit of bigness, but it can be more satisfying." - David Ogilvy
Well, luckly my code is much more readable! :) Peace!
-=- James
Please rate this message - let me know if I helped or not! * * *If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles -
MidwestLimey wrote:
To be fair egregious casting is hardly the preserve of C#, it's more an indication of failed design.
I beg to dissagree. At least before generics, I had to constantly cast down whenever I was using the containers. And even now, just look at all the methods that return
System.Object.MidwestLimey wrote:
Reflection is damn handy, used conservatively.
The only valid use of reflection I am aware of is in the Development tools, like IDE's, compilers, and unit-test frameworks.
Nemanja Trifunovic wrote:
The only valid use of reflection I am aware of is in the Development tools, like IDE's, compilers, and unit-test frameworks.
I have one program where reflection was very useful. The goal was to make a program that could be extended to allow the user to configure any of the devices we made that use a specific protocol. In an effort to keep from having to write a new data class and UI class for every device that came out, I parsed some product definition files (text files) and used reflection to create the data classes and UI (that provides basic validation capabilities and the ability to use enums in a CheckedListBox or ComboBox) at run time. Without reflection I would have had to.... ummm... I don't want to figure out how I would have done that.
