Forums
Sometimes, it really is the comment which makes the code. Sometimes, the comments make simple (but still more complex than it needs to be) code less clear.
For example, Thomas provides this code, and comment, which… I understand what is happening here, despite the comment:
/// <summary>
/// A class file for find the mid value
/// </summary>
public class a
{
string[] s2 = null;
/// <summary>
/// mid function is to cut the some values from the text which we had given
/// </summary>
/// <param name="offset">The offset number</param>
/// <param name="numcharstoread">Number of chars to read from the test</param>
/// <param name="s">The string that has to be splited</param>
/// <returns>returns a string array</returns>
public string[] mid(int offset, int numcharstoread, string s)
{
int j = 0;
for (int i = numcharstoread; i < offset; i++)
{
char ch = s[i];
this.s2[j] = Convert.ToString(ch);
j++;
}
return this.s2;
}
}
It's a substring function. I understand that just from the name: mid. But if I read the comments, I get less confident that it's a substring function. It's also a substring function which relies on class state, treats the substring as an array, and at least with this snippet, wouldn't work (because s2 is null and never gets initialized).
Other times, however, the comment is a perfectly clear summary of how we should feel about some code.
Kerin writes: "This is in the production codebase for an application that I support. Every time I look at it, I die a little more."
function local_luxSheetVoodoo(){
return true; //yes i know, don't email me
}
I need to add this to pretty much every line of code I write, I think.
[Advertisement]
ProGet’s got you covered with security and access controls on your NuGet feeds. Learn more.