Commenting and Style Differences... [modified - added a final thought]
-
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.