Really?
-
Another fine example from our codebase:
/// <summary>
/// Loads the page
/// </summary>
/// <param name="sender"></param>
/// <param name="e"></param>
protected void Page_Load(object sender, EventArgs e)
{
...
}Good thing that comment is there, else I'd be completely lost.
-
Ironically, that method handles the actions performed in response to the page load event occurring in the ASP.NET page life-cycle. It is not actually responsible for loading the page.
-
Yeah the codebase is rife with comments like that, thanks to our 'all methods WILL have triple-slash headers' policy.
I just found another gem in that same page:
if (...)
{
if (...)
{
if (...)
{
if (...)
{
... snip ...
}
else if (...)
{
try
{
if (...)
{
if (...)
{
... snip ...
}
else
{
... snip ...
}
}
}
catch {} <-- Yes, empty catch on one line with no explanation
}
}
}
}
-
@Smitty said:
catch {} <-- Yes, empty catch on one line with no explanation
These things are nearly as informative as the title of the OP.
-
IIRC there's a VS addin that tries to infer from the method name and arguments what the documentation should read like.
-
I think there's a product called Ghostdoc which does exactly that. Sadly, we don't use it. This is plain old WTFery.
-
@Smitty said:
I think there's a product called Ghostdoc which does exactly that. Sadly, we don't use it. This is plain old WTFery.
Ghostdoc has been mentioned recently.
-
-
@boomzilla said:
@Smitty said:
New and Improved WTFeryThis is plain old WTFery.
Really, is there any other kind?
-
@El_Heffe said:
@boomzilla said:
@Smitty said:
New and Improved WTFeryThis is plain old WTFery.
Really, is there any other kind?
Meet the new WTFery. Same as the old WTFery.
-
I didn't think this example was done with GhostDoc, otherwise I think it would be "Pages the Load" instead.
Also, the parameters would have been called "the sender" and "the e".
