Dennis responded to a rather tired discussion of whether you should comment your code or not (in fact, Frans has a nice way of saying it's a stupid discussion) by concluding that the main reason to comment code is to explain *why* an implementation is the way it is.
I fully agree that this should be the main reason for commenting. I've had to go through a lot of very large codebases over the years and what I'm looking for mostly when examining an implementation is why an approach was picked. I can't count the number of times I've tried to optimize a method only to discover there was a very good reason for not optimizing it in a certain way.
Ofcourse, practically everything else you can tell about a piece of code is usually worth writing down in comments. The whole discussion is mostly pointless now that VS.NET allows you collapse comments anyway. Think comments are dumb? Don't read them. Don't like writing comments? Fine, but I'm not touching the code.
Yesterday I was working on finishing an interface assembly in C# for one of my projects. When thinking about making the interfaces define exactly what I want them to I decided to look into the parameter types, checking to make sure I understood the semantics.
What struck me as odd, is that parameters declared with the out modifier are considered initially unassigned within a function member. This means that the following code:
void SomeMethod(out string str)
has the compiler tell you: "error CS0165: Use of unassigned local variable 'str'". The funny thing is though, that if you change the offending line to assign something to str so it compiles (out requires you to assign something to the declared parameter before returning) and put a breakpoint on it, you'll see that the compiler does assign the parameter, it just doesn't allow you to use it before assigning something to it yourself. And yes, this is fully compliant with the defined semantics.
What I wonder though, is why are
out parameters considered initially unassigned? It's not a strange scenario where you want to define a parameter that for instance returns the type of a conversion and may initially contain a requested type to convert to. If you don't pass anything you get default conversion (and a specification of what was picked in the output parameter).
If you declare such a parameter without any modifier and it's a reference type, you won't be able to assign something new to it since that won't be returned. Declaring it with the
ref modifier forces you to always supply something in advance, which means you need to define what value denotes "no value supplied". And finally, declaring it with the
out modifier means you'll be able to supply an input value but the callee will never be able to use it.
My conclusion: the language designers probably want to force me out of using parameters this way.
After not having time to do "this blogging thing" for so long, I've finally taken the plunge. This is just my opening post, not much content here I'm afraid though.
I'll be visiting the European TechEd 2004 conference from June 29th to July 2nd in Amsterdam, The Netherlands. Here's a button I made for the occassion: