<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article10_01_01_226232</id>
	<title>Myths About Code Comments</title>
	<author>timothy</author>
	<datestamp>1262341740000</datestamp>
	<htmltext>theodp writes <i>"Jason Baker gives his take on <a href="http://jasonmbaker.com/myths-about-code-comments">the biggest misconceptions about code comments</a>: 1) Comments are free ('When you update the code that the comment references, you usually have to update the comment as well'). 2) Comments make code more readable ('by far the most pervasive myth that I've encountered'). 3) You should comment every function, method, class, and module ('documenting something that needs no documentation is universally a bad idea'). 4) Code must always be 'self documenting' ('would you rather use a one-liner that requires a 3-line comment, or a 10-liner that requires no comments?')."</i></htmltext>
<tokenext>theodp writes " Jason Baker gives his take on the biggest misconceptions about code comments : 1 ) Comments are free ( 'When you update the code that the comment references , you usually have to update the comment as well ' ) .
2 ) Comments make code more readable ( 'by far the most pervasive myth that I 've encountered ' ) .
3 ) You should comment every function , method , class , and module ( 'documenting something that needs no documentation is universally a bad idea ' ) .
4 ) Code must always be 'self documenting ' ( 'would you rather use a one-liner that requires a 3-line comment , or a 10-liner that requires no comments ? ' ) .
"</tokentext>
<sentencetext>theodp writes "Jason Baker gives his take on the biggest misconceptions about code comments: 1) Comments are free ('When you update the code that the comment references, you usually have to update the comment as well').
2) Comments make code more readable ('by far the most pervasive myth that I've encountered').
3) You should comment every function, method, class, and module ('documenting something that needs no documentation is universally a bad idea').
4) Code must always be 'self documenting' ('would you rather use a one-liner that requires a 3-line comment, or a 10-liner that requires no comments?').
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620018</id>
	<title>Re:Wrong on all accounts</title>
	<author>obarthelemy</author>
	<datestamp>1262373840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I think commenting is a communication, rather than technical, skill. Some programmers may not be skilled at it, others better, independently of their programming skills. It requires being able to empathize with the reader, and pedagogy.</p></htmltext>
<tokenext>I think commenting is a communication , rather than technical , skill .
Some programmers may not be skilled at it , others better , independently of their programming skills .
It requires being able to empathize with the reader , and pedagogy .</tokentext>
<sentencetext>I think commenting is a communication, rather than technical, skill.
Some programmers may not be skilled at it, others better, independently of their programming skills.
It requires being able to empathize with the reader, and pedagogy.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616880</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619838</id>
	<title>Re:Has No One Actually Studied This?</title>
	<author>Anonymous</author>
	<datestamp>1262371500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Or maybe complicated areas that have the most potential for errors also require the most comments...</p></htmltext>
<tokenext>Or maybe complicated areas that have the most potential for errors also require the most comments.. .</tokentext>
<sentencetext>Or maybe complicated areas that have the most potential for errors also require the most comments...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30690194</id>
	<title>Commenting units</title>
	<author>SplashMyBandit</author>
	<datestamp>1262877000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>One thing I notice (as a former physicist turned developer) is that computer science trained folk are very poor at documenting their *units*. For example, a time duration may be in days, years, milliseconds. Without either naming your variables with a unit name (eg. sleepDurationMillis) or putting in a comment stating the unit of measure at the point of declaration it becomes infuriating and risk-prone using other people's code. Comments are absolutely essential to document the units that variables use. It's also useful having light commentary describing the preconditions of a method and what will cause it to fail - that's one way to get more robust systems - yet few people do it. I only learnt these things after decades of maintaining and extending a lot of other people's code. Therefore I consider the "don't comment" brigade to be rather n00b in their outlook, despite thinking they're l33t.</htmltext>
<tokenext>One thing I notice ( as a former physicist turned developer ) is that computer science trained folk are very poor at documenting their * units * .
For example , a time duration may be in days , years , milliseconds .
Without either naming your variables with a unit name ( eg .
sleepDurationMillis ) or putting in a comment stating the unit of measure at the point of declaration it becomes infuriating and risk-prone using other people 's code .
Comments are absolutely essential to document the units that variables use .
It 's also useful having light commentary describing the preconditions of a method and what will cause it to fail - that 's one way to get more robust systems - yet few people do it .
I only learnt these things after decades of maintaining and extending a lot of other people 's code .
Therefore I consider the " do n't comment " brigade to be rather n00b in their outlook , despite thinking they 're l33t .</tokentext>
<sentencetext>One thing I notice (as a former physicist turned developer) is that computer science trained folk are very poor at documenting their *units*.
For example, a time duration may be in days, years, milliseconds.
Without either naming your variables with a unit name (eg.
sleepDurationMillis) or putting in a comment stating the unit of measure at the point of declaration it becomes infuriating and risk-prone using other people's code.
Comments are absolutely essential to document the units that variables use.
It's also useful having light commentary describing the preconditions of a method and what will cause it to fail - that's one way to get more robust systems - yet few people do it.
I only learnt these things after decades of maintaining and extending a lot of other people's code.
Therefore I consider the "don't comment" brigade to be rather n00b in their outlook, despite thinking they're l33t.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617362</id>
	<title>Bad programmer</title>
	<author>Anonymous</author>
	<datestamp>1262350860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Just another bad programmer desperately trying to justify the bad job he does.  I'll tell you what, you try working with a retard like this guy, and then try working with someone who "over-comments" his code, and see which is easier to work with.</p></htmltext>
<tokenext>Just another bad programmer desperately trying to justify the bad job he does .
I 'll tell you what , you try working with a retard like this guy , and then try working with someone who " over-comments " his code , and see which is easier to work with .</tokentext>
<sentencetext>Just another bad programmer desperately trying to justify the bad job he does.
I'll tell you what, you try working with a retard like this guy, and then try working with someone who "over-comments" his code, and see which is easier to work with.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30625366</id>
	<title>Re:Wrong on all accounts</title>
	<author>fishexe</author>
	<datestamp>1262465820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Having worked as a programmer for many years, all I can say is poorly commented and undocumented code is unprofessional and I would rather
rewrite it than try to decipher it. I've heard all of these excuses before and all I can say to the people that make them is: Your code is not as
good as you think it is.</p></div><p>Having read Slashdot for many years, all I can say is poorly formatted and prematurely line-fed text is unprofessional and I would rather rewrite it than try to look at it.  You haven't yet given any excuses for it, but all I'll say to you when you do is: "Your comment is not as good as you think it is."</p></div>
	</htmltext>
<tokenext>Having worked as a programmer for many years , all I can say is poorly commented and undocumented code is unprofessional and I would rather rewrite it than try to decipher it .
I 've heard all of these excuses before and all I can say to the people that make them is : Your code is not as good as you think it is.Having read Slashdot for many years , all I can say is poorly formatted and prematurely line-fed text is unprofessional and I would rather rewrite it than try to look at it .
You have n't yet given any excuses for it , but all I 'll say to you when you do is : " Your comment is not as good as you think it is .
"</tokentext>
<sentencetext>Having worked as a programmer for many years, all I can say is poorly commented and undocumented code is unprofessional and I would rather
rewrite it than try to decipher it.
I've heard all of these excuses before and all I can say to the people that make them is: Your code is not as
good as you think it is.Having read Slashdot for many years, all I can say is poorly formatted and prematurely line-fed text is unprofessional and I would rather rewrite it than try to look at it.
You haven't yet given any excuses for it, but all I'll say to you when you do is: "Your comment is not as good as you think it is.
"
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620176</id>
	<title>CommentsAreSoLastCentury.</title>
	<author>shutdown -p now</author>
	<datestamp>1262375880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>IPreferToUseDescriptiveButLongIdentifiersInstead(ForBothFunctionsAndVariables);</p><p>YesInCaseYouDidntGuessILike(Java,CSharp);</p></htmltext>
<tokenext>IPreferToUseDescriptiveButLongIdentifiersInstead ( ForBothFunctionsAndVariables ) ; YesInCaseYouDidntGuessILike ( Java,CSharp ) ;</tokentext>
<sentencetext>IPreferToUseDescriptiveButLongIdentifiersInstead(ForBothFunctionsAndVariables);YesInCaseYouDidntGuessILike(Java,CSharp);</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619244</id>
	<title>The biggest misconception he forgot to mention...</title>
	<author>Anonymous</author>
	<datestamp>1262364300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Lots of comments doesn't make bad code good.</p></htmltext>
<tokenext>Lots of comments does n't make bad code good .</tokentext>
<sentencetext>Lots of comments doesn't make bad code good.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30643030</id>
	<title>#2 is just wrong</title>
	<author>Anonymous</author>
	<datestamp>1262629680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>He misses the point. But actually states the point in his objection. Ie That he ignores the comments unless he's stumped. Duhhh... What do you think comments are for? They exist to identify the more non-obvious portions of code. Anybody can see that x = y assigns y to x. This isn't what comments are for. As stated in his #3.</p><p>Comments are useful when used correctly. The problem is they usually aren't used correctly. How many times have come back a year later, read a comment, and wondered what the hell you meant by that?</p></htmltext>
<tokenext>He misses the point .
But actually states the point in his objection .
Ie That he ignores the comments unless he 's stumped .
Duhhh... What do you think comments are for ?
They exist to identify the more non-obvious portions of code .
Anybody can see that x = y assigns y to x. This is n't what comments are for .
As stated in his # 3.Comments are useful when used correctly .
The problem is they usually are n't used correctly .
How many times have come back a year later , read a comment , and wondered what the hell you meant by that ?</tokentext>
<sentencetext>He misses the point.
But actually states the point in his objection.
Ie That he ignores the comments unless he's stumped.
Duhhh... What do you think comments are for?
They exist to identify the more non-obvious portions of code.
Anybody can see that x = y assigns y to x. This isn't what comments are for.
As stated in his #3.Comments are useful when used correctly.
The problem is they usually aren't used correctly.
How many times have come back a year later, read a comment, and wondered what the hell you meant by that?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621108</id>
	<title>Re:Wrong on all accounts</title>
	<author>Anonymous</author>
	<datestamp>1262433180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I'd like to add that comments that just reiterate what the code does can be quite helpful for debugging though, if they don't match the code that usually means that<br>a) Whoever wrote it didn't know what they are doing<br>b) The code was changed rather carelessly<br>That usually indicates a good point to start bug-fixing.<br>However that means that the code by itself must be clear enough that at least the clever programmers can understand it easily enough not to be tempted to just believe the comment.<br>No amount of comments is a substitute for good code (however some of those "every line must be commented" rules seem to assume that).</p></htmltext>
<tokenext>I 'd like to add that comments that just reiterate what the code does can be quite helpful for debugging though , if they do n't match the code that usually means thata ) Whoever wrote it did n't know what they are doingb ) The code was changed rather carelesslyThat usually indicates a good point to start bug-fixing.However that means that the code by itself must be clear enough that at least the clever programmers can understand it easily enough not to be tempted to just believe the comment.No amount of comments is a substitute for good code ( however some of those " every line must be commented " rules seem to assume that ) .</tokentext>
<sentencetext>I'd like to add that comments that just reiterate what the code does can be quite helpful for debugging though, if they don't match the code that usually means thata) Whoever wrote it didn't know what they are doingb) The code was changed rather carelesslyThat usually indicates a good point to start bug-fixing.However that means that the code by itself must be clear enough that at least the clever programmers can understand it easily enough not to be tempted to just believe the comment.No amount of comments is a substitute for good code (however some of those "every line must be commented" rules seem to assume that).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619952</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30626524</id>
	<title>Re:Verbose variables</title>
	<author>slaingod</author>
	<datestamp>1262429640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Code completion is your friend. You should only need to type two or three letters to get to most of your long named variables anyway. And using long variable names absolutely makes thing more readable, especially in a local sense.</p><p>When your debugger or log spits out:</p><p>"variable 'hn' was undefined" versus "'host\_name' was undefined", you might actually be able to fix it without opening up code, because it was just a configuration error.</p><p>But even more generally, not having to grok to the beginning of a method or fully understand a class's internals to know what 3 lines of code are doing, helps the mere mortals out there like me, especially when traverse object inheritance several layers deep.</p><p>And mathematicians do a lot of writing on paper where it actually does make more sense to use abbreviated variables, at lease more so than in modern computer engineering.</p></htmltext>
<tokenext>Code completion is your friend .
You should only need to type two or three letters to get to most of your long named variables anyway .
And using long variable names absolutely makes thing more readable , especially in a local sense.When your debugger or log spits out : " variable 'hn ' was undefined " versus " 'host \ _name ' was undefined " , you might actually be able to fix it without opening up code , because it was just a configuration error.But even more generally , not having to grok to the beginning of a method or fully understand a class 's internals to know what 3 lines of code are doing , helps the mere mortals out there like me , especially when traverse object inheritance several layers deep.And mathematicians do a lot of writing on paper where it actually does make more sense to use abbreviated variables , at lease more so than in modern computer engineering .</tokentext>
<sentencetext>Code completion is your friend.
You should only need to type two or three letters to get to most of your long named variables anyway.
And using long variable names absolutely makes thing more readable, especially in a local sense.When your debugger or log spits out:"variable 'hn' was undefined" versus "'host\_name' was undefined", you might actually be able to fix it without opening up code, because it was just a configuration error.But even more generally, not having to grok to the beginning of a method or fully understand a class's internals to know what 3 lines of code are doing, helps the mere mortals out there like me, especially when traverse object inheritance several layers deep.And mathematicians do a lot of writing on paper where it actually does make more sense to use abbreviated variables, at lease more so than in modern computer engineering.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30623824</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617030</id>
	<title>Re:Please no</title>
	<author>Anonymous</author>
	<datestamp>1262348280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Unfortunately, one of the previous pieces of software in this area followed the poster's "self documenting code" style (very nice, clean, well written code with no comments), and even I find it difficult to piece together what's going on in places --- not because all of the code is crypto-specific, but because the author has thrown so much effort into writing "clean, pretty" code that it's actually hard to know where the crucial pieces are. I can't quite explain why I find this so irritating, but perhaps some of you will know what I mean.</p></div>
</blockquote><p>

I can kind of understand this, often in the quest to make things more understandable things are refactered into methods/functions that arent modular operations in themselves which can lead to more confusion since they masquerade as pieces of modularly reusable code when they in fact rely on assumptions which happen to be satisfied by their caller.

<br> <br>

Its also worth noting that you do get a performance and memory usage penalty for pushing additional frames onto the stack. In certain cases that can be a factor. (As an aside why is it in Uni that recursive code is held in such high regard as being elegant whereas in day to day like its almost always a bad idea. I made that mistake a few times early on in my professional life).</p></div>
	</htmltext>
<tokenext>Unfortunately , one of the previous pieces of software in this area followed the poster 's " self documenting code " style ( very nice , clean , well written code with no comments ) , and even I find it difficult to piece together what 's going on in places --- not because all of the code is crypto-specific , but because the author has thrown so much effort into writing " clean , pretty " code that it 's actually hard to know where the crucial pieces are .
I ca n't quite explain why I find this so irritating , but perhaps some of you will know what I mean .
I can kind of understand this , often in the quest to make things more understandable things are refactered into methods/functions that arent modular operations in themselves which can lead to more confusion since they masquerade as pieces of modularly reusable code when they in fact rely on assumptions which happen to be satisfied by their caller .
Its also worth noting that you do get a performance and memory usage penalty for pushing additional frames onto the stack .
In certain cases that can be a factor .
( As an aside why is it in Uni that recursive code is held in such high regard as being elegant whereas in day to day like its almost always a bad idea .
I made that mistake a few times early on in my professional life ) .</tokentext>
<sentencetext>Unfortunately, one of the previous pieces of software in this area followed the poster's "self documenting code" style (very nice, clean, well written code with no comments), and even I find it difficult to piece together what's going on in places --- not because all of the code is crypto-specific, but because the author has thrown so much effort into writing "clean, pretty" code that it's actually hard to know where the crucial pieces are.
I can't quite explain why I find this so irritating, but perhaps some of you will know what I mean.
I can kind of understand this, often in the quest to make things more understandable things are refactered into methods/functions that arent modular operations in themselves which can lead to more confusion since they masquerade as pieces of modularly reusable code when they in fact rely on assumptions which happen to be satisfied by their caller.
Its also worth noting that you do get a performance and memory usage penalty for pushing additional frames onto the stack.
In certain cases that can be a factor.
(As an aside why is it in Uni that recursive code is held in such high regard as being elegant whereas in day to day like its almost always a bad idea.
I made that mistake a few times early on in my professional life).
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616836</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621654</id>
	<title>Try to write undocumented code with Perl</title>
	<author>freaker\_TuC</author>
	<datestamp>1262441760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Since I'm using remarks in my code, my coding has increased double in speed.</p><p>for loops, a missing bracket can be easy defeated by adding a code remark behind every closing bracket.<br>In big sources, this is a convenience to see where exactly a subroutine has finished to its result.</p><p>Not only for loops, but also repetitive code, regexpes (which you can write in more than one way) and parameters will give a lot more meaning when having a little bit of documentation; even, if not for the next programmer.</p><p>I could not imagine an architect or anyone who builds buildings would be not making *any* sidenotes about their project.</p></htmltext>
<tokenext>Since I 'm using remarks in my code , my coding has increased double in speed.for loops , a missing bracket can be easy defeated by adding a code remark behind every closing bracket.In big sources , this is a convenience to see where exactly a subroutine has finished to its result.Not only for loops , but also repetitive code , regexpes ( which you can write in more than one way ) and parameters will give a lot more meaning when having a little bit of documentation ; even , if not for the next programmer.I could not imagine an architect or anyone who builds buildings would be not making * any * sidenotes about their project .</tokentext>
<sentencetext>Since I'm using remarks in my code, my coding has increased double in speed.for loops, a missing bracket can be easy defeated by adding a code remark behind every closing bracket.In big sources, this is a convenience to see where exactly a subroutine has finished to its result.Not only for loops, but also repetitive code, regexpes (which you can write in more than one way) and parameters will give a lot more meaning when having a little bit of documentation; even, if not for the next programmer.I could not imagine an architect or anyone who builds buildings would be not making *any* sidenotes about their project.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621266</id>
	<title>Re:every line of code should be commented</title>
	<author>Anonymous</author>
	<datestamp>1262435460000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>That looks far too close to what I was taught at University to be a joke. We were seriously taught to end if statements and functions with "// End of blah" type comments.</p></htmltext>
<tokenext>That looks far too close to what I was taught at University to be a joke .
We were seriously taught to end if statements and functions with " // End of blah " type comments .</tokentext>
<sentencetext>That looks far too close to what I was taught at University to be a joke.
We were seriously taught to end if statements and functions with "// End of blah" type comments.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620276</id>
	<title>Re:Warning - war story ahead</title>
	<author>SecurityGuy</author>
	<datestamp>1262463720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>20,000 lines of Fortran.  Nearly all variables were i, j, k, etc, and it was rather complex modeling code.</p><p>Comments?  No, there were no comments.  There was no documentation of any kind, unless you count the journal article in which the person who wrote the code described the model.</p></htmltext>
<tokenext>20,000 lines of Fortran .
Nearly all variables were i , j , k , etc , and it was rather complex modeling code.Comments ?
No , there were no comments .
There was no documentation of any kind , unless you count the journal article in which the person who wrote the code described the model .</tokentext>
<sentencetext>20,000 lines of Fortran.
Nearly all variables were i, j, k, etc, and it was rather complex modeling code.Comments?
No, there were no comments.
There was no documentation of any kind, unless you count the journal article in which the person who wrote the code described the model.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617380</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618546</id>
	<title>Re:Please no</title>
	<author>Anonymous</author>
	<datestamp>1262358000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>when he thinks code is overcommented, he can ask Emacs to hide the comments.</p></div><p>If he ignores the comments, then his changes will lead to discrepancies between the code and the comments. If comments exist, they must be maintained. Wrong comments are worse than no comments.</p><p>Overly verbose and other types of unnecessary comments (i*=2;<nobr> <wbr></nobr>//multiply i by 2) are indeed bad and cause actual problems. Comments are their own kind of program and the more comments there are, the higher the chance that the comments "do" something different from what the code does.</p></div>
	</htmltext>
<tokenext>when he thinks code is overcommented , he can ask Emacs to hide the comments.If he ignores the comments , then his changes will lead to discrepancies between the code and the comments .
If comments exist , they must be maintained .
Wrong comments are worse than no comments.Overly verbose and other types of unnecessary comments ( i * = 2 ; //multiply i by 2 ) are indeed bad and cause actual problems .
Comments are their own kind of program and the more comments there are , the higher the chance that the comments " do " something different from what the code does .</tokentext>
<sentencetext>when he thinks code is overcommented, he can ask Emacs to hide the comments.If he ignores the comments, then his changes will lead to discrepancies between the code and the comments.
If comments exist, they must be maintained.
Wrong comments are worse than no comments.Overly verbose and other types of unnecessary comments (i*=2; //multiply i by 2) are indeed bad and cause actual problems.
Comments are their own kind of program and the more comments there are, the higher the chance that the comments "do" something different from what the code does.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616836</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622396</id>
	<title>Reviewers are to blame as well for poor comments</title>
	<author>CaptCanuk</author>
	<datestamp>1262448900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I work in an environment with 30 developers, 400K SLOC and 2 global sites specifically for one component (in a family of 12).  Our review process is pre-submit and done through e-mail.  Reviewers are as responsible as the code submitter in identifying negligent comments.  From the check-in comment, the intent of the change should be obvious; the comments need only support the intent.  Asking someone to review a change before submission has the added benefit of ensuring at least two minds understand it (even if one is only cursorily).  If you don't understand the code, you ask questions and ensure each question answered results in a architectural document change, code change, comment change, or at the very least, check-in comment change.  Sometimes, it is not apparent to the submitter that his concepts parlayed into code are consumable by others.  It's for that reason it is important to put in bad code sometimes to see if people are paying attention.</p></htmltext>
<tokenext>I work in an environment with 30 developers , 400K SLOC and 2 global sites specifically for one component ( in a family of 12 ) .
Our review process is pre-submit and done through e-mail .
Reviewers are as responsible as the code submitter in identifying negligent comments .
From the check-in comment , the intent of the change should be obvious ; the comments need only support the intent .
Asking someone to review a change before submission has the added benefit of ensuring at least two minds understand it ( even if one is only cursorily ) .
If you do n't understand the code , you ask questions and ensure each question answered results in a architectural document change , code change , comment change , or at the very least , check-in comment change .
Sometimes , it is not apparent to the submitter that his concepts parlayed into code are consumable by others .
It 's for that reason it is important to put in bad code sometimes to see if people are paying attention .</tokentext>
<sentencetext>I work in an environment with 30 developers, 400K SLOC and 2 global sites specifically for one component (in a family of 12).
Our review process is pre-submit and done through e-mail.
Reviewers are as responsible as the code submitter in identifying negligent comments.
From the check-in comment, the intent of the change should be obvious; the comments need only support the intent.
Asking someone to review a change before submission has the added benefit of ensuring at least two minds understand it (even if one is only cursorily).
If you don't understand the code, you ask questions and ensure each question answered results in a architectural document change, code change, comment change, or at the very least, check-in comment change.
Sometimes, it is not apparent to the submitter that his concepts parlayed into code are consumable by others.
It's for that reason it is important to put in bad code sometimes to see if people are paying attention.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617636</id>
	<title>Re:every line of code should be commented</title>
	<author>owlstead</author>
	<datestamp>1262352960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In Java CheckStyle I've disallowed any statements that have been placed behind the code instead of on the line right in front of it. There are a few reasons for doing so: 1) they can be easily overlooked 2) they tend to explain the how instead of the why (which is a mistake most of the time) 3) people tend to use spaces to format them and 4) they tend to go over the 120 column mark we've set during refactoring.</p><p>So none of the lines except maybe the line containing just else would have been marked with a warning<nobr> <wbr></nobr>:) (yes, I know, I am responding to a jest).</p></htmltext>
<tokenext>In Java CheckStyle I 've disallowed any statements that have been placed behind the code instead of on the line right in front of it .
There are a few reasons for doing so : 1 ) they can be easily overlooked 2 ) they tend to explain the how instead of the why ( which is a mistake most of the time ) 3 ) people tend to use spaces to format them and 4 ) they tend to go over the 120 column mark we 've set during refactoring.So none of the lines except maybe the line containing just else would have been marked with a warning : ) ( yes , I know , I am responding to a jest ) .</tokentext>
<sentencetext>In Java CheckStyle I've disallowed any statements that have been placed behind the code instead of on the line right in front of it.
There are a few reasons for doing so: 1) they can be easily overlooked 2) they tend to explain the how instead of the why (which is a mistake most of the time) 3) people tend to use spaces to format them and 4) they tend to go over the 120 column mark we've set during refactoring.So none of the lines except maybe the line containing just else would have been marked with a warning :) (yes, I know, I am responding to a jest).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618610</id>
	<title>Re:Has No One Actually Studied This?</title>
	<author>Byzantine</author>
	<datestamp>1262358720000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Sounds sorta like <a href="http://www.literateprogramming.com/" title="literateprogramming.com" rel="nofollow">literate programming</a> [literateprogramming.com].</p></htmltext>
<tokenext>Sounds sorta like literate programming [ literateprogramming.com ] .</tokentext>
<sentencetext>Sounds sorta like literate programming [literateprogramming.com].</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30630790</id>
	<title>Re:every line of code should be commented</title>
	<author>Tanuki64</author>
	<datestamp>1262519100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I do it sometimes too, when I have to understand bad code with many nested loops. However, if I am allowed to do it, and the the code and project situations allows it, I tend to refactor the code. The necessity to mark the end of a loop is definitely a code smell. Usually it is not too difficult to convert several nested loops in a group of easily readable functions. If it is, it is even a worse sign regarding code quality. Yes, exceptions exist.</htmltext>
<tokenext>I do it sometimes too , when I have to understand bad code with many nested loops .
However , if I am allowed to do it , and the the code and project situations allows it , I tend to refactor the code .
The necessity to mark the end of a loop is definitely a code smell .
Usually it is not too difficult to convert several nested loops in a group of easily readable functions .
If it is , it is even a worse sign regarding code quality .
Yes , exceptions exist .</tokentext>
<sentencetext>I do it sometimes too, when I have to understand bad code with many nested loops.
However, if I am allowed to do it, and the the code and project situations allows it, I tend to refactor the code.
The necessity to mark the end of a loop is definitely a code smell.
Usually it is not too difficult to convert several nested loops in a group of easily readable functions.
If it is, it is even a worse sign regarding code quality.
Yes, exceptions exist.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618474</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616958</id>
	<title>Should be...</title>
	<author>Restil</author>
	<datestamp>1262347680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>myths about <i>excessive</i> code comments.  Provide comments in places where the comment might be useful.  If you have some obscure function, the purpose of which might be confusing if you or someone else looks at it a year later, then you need a comment.  The more obscure or terse, the more detailed the comment should be.  On the other hand, if the function's purpose is obvious just by glancing at it, or the function name is sufficient to describe the entire purpose of the function, there's probably not a need for any comments at all.</p><p>Within a function, if you only have nested loops one deep, there's probably no need to comment each closing bracket.  But if you have some horrendous 12 dimensional loop with lots of if statements, it might save a few headaches to know exactly which bracket lines up with which routine.<br>It's just a matter of commenting what is necessary, and avoiding it when it's not.</p><p>-Restil</p></htmltext>
<tokenext>myths about excessive code comments .
Provide comments in places where the comment might be useful .
If you have some obscure function , the purpose of which might be confusing if you or someone else looks at it a year later , then you need a comment .
The more obscure or terse , the more detailed the comment should be .
On the other hand , if the function 's purpose is obvious just by glancing at it , or the function name is sufficient to describe the entire purpose of the function , there 's probably not a need for any comments at all.Within a function , if you only have nested loops one deep , there 's probably no need to comment each closing bracket .
But if you have some horrendous 12 dimensional loop with lots of if statements , it might save a few headaches to know exactly which bracket lines up with which routine.It 's just a matter of commenting what is necessary , and avoiding it when it 's not.-Restil</tokentext>
<sentencetext>myths about excessive code comments.
Provide comments in places where the comment might be useful.
If you have some obscure function, the purpose of which might be confusing if you or someone else looks at it a year later, then you need a comment.
The more obscure or terse, the more detailed the comment should be.
On the other hand, if the function's purpose is obvious just by glancing at it, or the function name is sufficient to describe the entire purpose of the function, there's probably not a need for any comments at all.Within a function, if you only have nested loops one deep, there's probably no need to comment each closing bracket.
But if you have some horrendous 12 dimensional loop with lots of if statements, it might save a few headaches to know exactly which bracket lines up with which routine.It's just a matter of commenting what is necessary, and avoiding it when it's not.-Restil</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728</id>
	<title>Wrong on all accounts</title>
	<author>Anonymous</author>
	<datestamp>1262345700000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>Having worked as a programmer for many years, all I can say is poorly commented and undocumented code is unprofessional and I would rather<br>rewrite it than try to decipher it. I've heard all of these excuses before and all I can say to the people that make them is: Your code is not as<br>good as you think it is.</p></htmltext>
<tokenext>Having worked as a programmer for many years , all I can say is poorly commented and undocumented code is unprofessional and I would ratherrewrite it than try to decipher it .
I 've heard all of these excuses before and all I can say to the people that make them is : Your code is not asgood as you think it is .</tokentext>
<sentencetext>Having worked as a programmer for many years, all I can say is poorly commented and undocumented code is unprofessional and I would ratherrewrite it than try to decipher it.
I've heard all of these excuses before and all I can say to the people that make them is: Your code is not asgood as you think it is.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617552</id>
	<title>Re:Has No One Actually Studied This?</title>
	<author>Anonymous</author>
	<datestamp>1262352300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>"they found that in general the more comments in the code, the more problems were reported against it."</p></div><p>I wonder which of these is cause, and which effect. It could just be that the difficult code has more problems, sees more revisions, and hence, accumulates more comments.</p></div>
	</htmltext>
<tokenext>" they found that in general the more comments in the code , the more problems were reported against it .
" I wonder which of these is cause , and which effect .
It could just be that the difficult code has more problems , sees more revisions , and hence , accumulates more comments .</tokentext>
<sentencetext>"they found that in general the more comments in the code, the more problems were reported against it.
"I wonder which of these is cause, and which effect.
It could just be that the difficult code has more problems, sees more revisions, and hence, accumulates more comments.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619582</id>
	<title>Examples would help both sides of the argument</title>
	<author>Anonymous</author>
	<datestamp>1262368680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Software development is a broad enough topic to make this discussion difficult without examples.</p><p>http://code.google.com/p/virtualagc/source/browse/trunk/Comanche055/CM\_BODY\_ATTITUDE.s?r=258</p><p>http://c2.com/cgi/wiki?CommentExample</p></htmltext>
<tokenext>Software development is a broad enough topic to make this discussion difficult without examples.http : //code.google.com/p/virtualagc/source/browse/trunk/Comanche055/CM \ _BODY \ _ATTITUDE.s ? r = 258http : //c2.com/cgi/wiki ? CommentExample</tokentext>
<sentencetext>Software development is a broad enough topic to make this discussion difficult without examples.http://code.google.com/p/virtualagc/source/browse/trunk/Comanche055/CM\_BODY\_ATTITUDE.s?r=258http://c2.com/cgi/wiki?CommentExample</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618630</id>
	<title>Re:Wrong on all accounts</title>
	<author>Gothmolly</author>
	<datestamp>1262358900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>And you're not as perfect as you think you are.</p><p>Welcome to reality.</p></htmltext>
<tokenext>And you 're not as perfect as you think you are.Welcome to reality .</tokentext>
<sentencetext>And you're not as perfect as you think you are.Welcome to reality.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617140</id>
	<title>Re:More verbose == less readable?</title>
	<author>pjt33</author>
	<datestamp>1262349120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Unless you're doing it for absolutely required performance reasons</p></div><p>Or numerical reasons. Sometimes it happens that the 3-line version is algebraically equivalent to the 10-line version, but more stable numerically. In this case you may need to replace 3 lines of comments with 20 lines sketching the outline of the 10-line version and giving a proof of correctness of the 3-line version.</p></div>
	</htmltext>
<tokenext>Unless you 're doing it for absolutely required performance reasonsOr numerical reasons .
Sometimes it happens that the 3-line version is algebraically equivalent to the 10-line version , but more stable numerically .
In this case you may need to replace 3 lines of comments with 20 lines sketching the outline of the 10-line version and giving a proof of correctness of the 3-line version .</tokentext>
<sentencetext>Unless you're doing it for absolutely required performance reasonsOr numerical reasons.
Sometimes it happens that the 3-line version is algebraically equivalent to the 10-line version, but more stable numerically.
In this case you may need to replace 3 lines of comments with 20 lines sketching the outline of the 10-line version and giving a proof of correctness of the 3-line version.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616770</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621112</id>
	<title>Re:One person's myth is another person's fact.</title>
	<author>awol</author>
	<datestamp>1262433300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I find the most important comments are those that tell you WHY something was done the way it was.</p>  </div><p>More than most important it is the only reason to comment. HOW comments can only ever be wrong. The code is right (well at least it is what it is) telling how the code does what it does can only be informative by being wrong since even if it is right it is only right insofar as it reflects what the actual code does.</p><p>For this reason, I am not a big fan of comments other than self documenting API regimes since they can be used to adress precisely this point.</p><p>On the other hand I am a fan of literate programming but then that's a whole different story.</p></div>
	</htmltext>
<tokenext>I find the most important comments are those that tell you WHY something was done the way it was .
More than most important it is the only reason to comment .
HOW comments can only ever be wrong .
The code is right ( well at least it is what it is ) telling how the code does what it does can only be informative by being wrong since even if it is right it is only right insofar as it reflects what the actual code does.For this reason , I am not a big fan of comments other than self documenting API regimes since they can be used to adress precisely this point.On the other hand I am a fan of literate programming but then that 's a whole different story .</tokentext>
<sentencetext>I find the most important comments are those that tell you WHY something was done the way it was.
More than most important it is the only reason to comment.
HOW comments can only ever be wrong.
The code is right (well at least it is what it is) telling how the code does what it does can only be informative by being wrong since even if it is right it is only right insofar as it reflects what the actual code does.For this reason, I am not a big fan of comments other than self documenting API regimes since they can be used to adress precisely this point.On the other hand I am a fan of literate programming but then that's a whole different story.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616748</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617344</id>
	<title>Self Documenting</title>
	<author>jamesh</author>
	<datestamp>1262350740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>4) Code must always be 'self documenting' ('would you rather use a one-liner that requires a 3-line comment, or a 10-liner that requires no comments?').</p></div><p>Or to put some more straw in it "would you rather use a one-liner that requires 1 character of comments, or a 1 billion-liner that requires no comments".</p><p>If your 1 line of code is so complicated that it takes 10 lines to write it out in a way that is easily understood, then 3 lines of comments is probably not going to do it justice.</p></div>
	</htmltext>
<tokenext>4 ) Code must always be 'self documenting ' ( 'would you rather use a one-liner that requires a 3-line comment , or a 10-liner that requires no comments ?
' ) .Or to put some more straw in it " would you rather use a one-liner that requires 1 character of comments , or a 1 billion-liner that requires no comments " .If your 1 line of code is so complicated that it takes 10 lines to write it out in a way that is easily understood , then 3 lines of comments is probably not going to do it justice .</tokentext>
<sentencetext>4) Code must always be 'self documenting' ('would you rather use a one-liner that requires a 3-line comment, or a 10-liner that requires no comments?
').Or to put some more straw in it "would you rather use a one-liner that requires 1 character of comments, or a 1 billion-liner that requires no comments".If your 1 line of code is so complicated that it takes 10 lines to write it out in a way that is easily understood, then 3 lines of comments is probably not going to do it justice.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619628</id>
	<title>Re:Warning - war story ahead</title>
	<author>Speare</author>
	<datestamp>1262369280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>
<p>My favorite was a suite of FORTRAN programs written by X-Ray Crystallography lab chemists, sometime in the 70s I imagine, which were given descriptive names like CASTLE, FRODO and DRAGON.  The code was laid in columns 1-71, and the FORTRAN compiler ignored anything after column 72 as a comment (a holdover from narrow punchcards).  Thus, the authors wrote an epic fantasy story into the rightmost columns of 132-character lines.  Every line of code had a bit of dialogue, action or other Tolkien-esque prose married to it.  Folks in the lab in the late 80s hated changing anything in the code, bugs or no, because it would require fixing, reflowing, or stripping out the story column.</p></htmltext>
<tokenext>My favorite was a suite of FORTRAN programs written by X-Ray Crystallography lab chemists , sometime in the 70s I imagine , which were given descriptive names like CASTLE , FRODO and DRAGON .
The code was laid in columns 1-71 , and the FORTRAN compiler ignored anything after column 72 as a comment ( a holdover from narrow punchcards ) .
Thus , the authors wrote an epic fantasy story into the rightmost columns of 132-character lines .
Every line of code had a bit of dialogue , action or other Tolkien-esque prose married to it .
Folks in the lab in the late 80s hated changing anything in the code , bugs or no , because it would require fixing , reflowing , or stripping out the story column .</tokentext>
<sentencetext>
My favorite was a suite of FORTRAN programs written by X-Ray Crystallography lab chemists, sometime in the 70s I imagine, which were given descriptive names like CASTLE, FRODO and DRAGON.
The code was laid in columns 1-71, and the FORTRAN compiler ignored anything after column 72 as a comment (a holdover from narrow punchcards).
Thus, the authors wrote an epic fantasy story into the rightmost columns of 132-character lines.
Every line of code had a bit of dialogue, action or other Tolkien-esque prose married to it.
Folks in the lab in the late 80s hated changing anything in the code, bugs or no, because it would require fixing, reflowing, or stripping out the story column.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617380</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619202</id>
	<title>I have to disagree.</title>
	<author>hallux.sinister</author>
	<datestamp>1262364000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I would rather use code with 1 line of high-level language, requiring three lines of comments, than 10 lines of high-level language code, with no comments, because 99\% of the time, the MACHINE is what's going to be reading the code, in compiled binary form.  At compilation time, as I think everyone on<nobr> <wbr></nobr>/. knows, (or should) all those comments get sent Express Mail to<nobr> <wbr></nobr>/dev/null, and the result is usually more compact final-product machine code, which executes faster, using less time and processor power.  The other 1\% of the time, when it is <b>I</b> who am actually looking at it, I don't mind reading a few sentences from the previous coder telling me what he was TRYING to accomplish with that function.</htmltext>
<tokenext>I would rather use code with 1 line of high-level language , requiring three lines of comments , than 10 lines of high-level language code , with no comments , because 99 \ % of the time , the MACHINE is what 's going to be reading the code , in compiled binary form .
At compilation time , as I think everyone on / .
knows , ( or should ) all those comments get sent Express Mail to /dev/null , and the result is usually more compact final-product machine code , which executes faster , using less time and processor power .
The other 1 \ % of the time , when it is I who am actually looking at it , I do n't mind reading a few sentences from the previous coder telling me what he was TRYING to accomplish with that function .</tokentext>
<sentencetext>I would rather use code with 1 line of high-level language, requiring three lines of comments, than 10 lines of high-level language code, with no comments, because 99\% of the time, the MACHINE is what's going to be reading the code, in compiled binary form.
At compilation time, as I think everyone on /.
knows, (or should) all those comments get sent Express Mail to /dev/null, and the result is usually more compact final-product machine code, which executes faster, using less time and processor power.
The other 1\% of the time, when it is I who am actually looking at it, I don't mind reading a few sentences from the previous coder telling me what he was TRYING to accomplish with that function.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618484</id>
	<title>Re:Not commenting is a sign of not thinking or car</title>
	<author>Anonymous</author>
	<datestamp>1262357640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>When your public method is named something like initCamera( int camID ), or grabFrame(), I'm not altogether certain what's gained by spelling that out in a comment... maybe if there's something deeper going on, but if it is as simple as it looks, why pollute it with additional words to read that convey the exact same meaning?</htmltext>
<tokenext>When your public method is named something like initCamera ( int camID ) , or grabFrame ( ) , I 'm not altogether certain what 's gained by spelling that out in a comment... maybe if there 's something deeper going on , but if it is as simple as it looks , why pollute it with additional words to read that convey the exact same meaning ?</tokentext>
<sentencetext>When your public method is named something like initCamera( int camID ), or grabFrame(), I'm not altogether certain what's gained by spelling that out in a comment... maybe if there's something deeper going on, but if it is as simple as it looks, why pollute it with additional words to read that convey the exact same meaning?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616936</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616884</id>
	<title>Compare / contrast.</title>
	<author>fahrbot-bot</author>
	<datestamp>1262347080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>...would you rather use a one-liner that requires a 3-line comment, or a 10-liner that requires no comments...</p></div>
</blockquote><p>
Depends on the efficiency and maintainability.  A one-liner that's "perfect" is probably worth the extra comments.  Ten lines of self-evident code may not be better.  Personally, I can't stand code that starts "boolean done = false; while (!done) {...}" when the condition can be determined inline using an operational variable.</p></div>
	</htmltext>
<tokenext>...would you rather use a one-liner that requires a 3-line comment , or a 10-liner that requires no comments.. . Depends on the efficiency and maintainability .
A one-liner that 's " perfect " is probably worth the extra comments .
Ten lines of self-evident code may not be better .
Personally , I ca n't stand code that starts " boolean done = false ; while ( ! done ) { ... } " when the condition can be determined inline using an operational variable .</tokentext>
<sentencetext>...would you rather use a one-liner that requires a 3-line comment, or a 10-liner that requires no comments...

Depends on the efficiency and maintainability.
A one-liner that's "perfect" is probably worth the extra comments.
Ten lines of self-evident code may not be better.
Personally, I can't stand code that starts "boolean done = false; while (!done) {...}" when the condition can be determined inline using an operational variable.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617014</id>
	<title>Re:More verbose == less readable?</title>
	<author>buddyglass</author>
	<datestamp>1262348100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>And if you're that worried about a verbose section of code, extract a method, give it a good name, and be done.</p></div></blockquote><p>In total agreement here.  Usually just look at a short-ish method's name, its parameters, and its return value, makes it clear what it does.  This is different than if that same code were included in-place, since in that situation its not clear what the "inputs" and "outputs".  Plus extracting it usually makes the section from which it was extracted easier to read.</p></div>
	</htmltext>
<tokenext>And if you 're that worried about a verbose section of code , extract a method , give it a good name , and be done.In total agreement here .
Usually just look at a short-ish method 's name , its parameters , and its return value , makes it clear what it does .
This is different than if that same code were included in-place , since in that situation its not clear what the " inputs " and " outputs " .
Plus extracting it usually makes the section from which it was extracted easier to read .</tokentext>
<sentencetext>And if you're that worried about a verbose section of code, extract a method, give it a good name, and be done.In total agreement here.
Usually just look at a short-ish method's name, its parameters, and its return value, makes it clear what it does.
This is different than if that same code were included in-place, since in that situation its not clear what the "inputs" and "outputs".
Plus extracting it usually makes the section from which it was extracted easier to read.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616770</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621636</id>
	<title>Re:Wrong on all accounts</title>
	<author>Anonymous</author>
	<datestamp>1262441520000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Sometimes code is not poorly written, just because it needs deciphering.</p><p>I've seen cases where the understandable code is so slow, that the users waste a lot of time, while the code that is not understandable, takes less than a second to execute. In this case, comments are really useful.</p><p>I have also seen situations where the unreadable code is marginally faster, but that little difference, is the make it or break it.</p></htmltext>
<tokenext>Sometimes code is not poorly written , just because it needs deciphering.I 've seen cases where the understandable code is so slow , that the users waste a lot of time , while the code that is not understandable , takes less than a second to execute .
In this case , comments are really useful.I have also seen situations where the unreadable code is marginally faster , but that little difference , is the make it or break it .</tokentext>
<sentencetext>Sometimes code is not poorly written, just because it needs deciphering.I've seen cases where the understandable code is so slow, that the users waste a lot of time, while the code that is not understandable, takes less than a second to execute.
In this case, comments are really useful.I have also seen situations where the unreadable code is marginally faster, but that little difference, is the make it or break it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616976</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622176</id>
	<title>code completion</title>
	<author>Anonymous</author>
	<datestamp>1262447100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Two words:  "Code Completion".  Many IDE's (like Netbeans) use PHPDoc comments to make educated guesses about code completion.  A one-liner function with 5 lines of comments is worth it.</p></htmltext>
<tokenext>Two words : " Code Completion " .
Many IDE 's ( like Netbeans ) use PHPDoc comments to make educated guesses about code completion .
A one-liner function with 5 lines of comments is worth it .</tokentext>
<sentencetext>Two words:  "Code Completion".
Many IDE's (like Netbeans) use PHPDoc comments to make educated guesses about code completion.
A one-liner function with 5 lines of comments is worth it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619326</id>
	<title>Re:Has No One Actually Studied This?</title>
	<author>oliverthered</author>
	<datestamp>1262365440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>" noticed was their tendency to keep copying data from one data structure to another instead of using it in place"</p><p>hmm.... maybe they just read the python tutorial on the python website.</p><p>It is not safe to modify the sequence being iterated over in the loop (this can only happen for mutable sequence types, such as lists). If you need to modify the list you are iterating over (for example, to duplicate selected items) you must iterate over a copy. The slice notation makes this particularly convenient:<br>&gt;&gt;&gt; for x in a[:]: # make a slice copy of the entire list<nobr> <wbr></nobr>...    if len(x) &gt; 6: a.insert(0, x)<nobr> <wbr></nobr>...<br>&gt;&gt;&gt; a</p><p>far better solution would be to loop over a and build a list of thins you wanted to insert then loop over the things you wanted to insert list and modify a.</p><p>immutable types are really for beginners and only case problems for people who actually can write code.</p></htmltext>
<tokenext>" noticed was their tendency to keep copying data from one data structure to another instead of using it in place " hmm.... maybe they just read the python tutorial on the python website.It is not safe to modify the sequence being iterated over in the loop ( this can only happen for mutable sequence types , such as lists ) .
If you need to modify the list you are iterating over ( for example , to duplicate selected items ) you must iterate over a copy .
The slice notation makes this particularly convenient : &gt; &gt; &gt; for x in a [ : ] : # make a slice copy of the entire list ... if len ( x ) &gt; 6 : a.insert ( 0 , x ) ... &gt; &gt; &gt; afar better solution would be to loop over a and build a list of thins you wanted to insert then loop over the things you wanted to insert list and modify a.immutable types are really for beginners and only case problems for people who actually can write code .</tokentext>
<sentencetext>" noticed was their tendency to keep copying data from one data structure to another instead of using it in place"hmm.... maybe they just read the python tutorial on the python website.It is not safe to modify the sequence being iterated over in the loop (this can only happen for mutable sequence types, such as lists).
If you need to modify the list you are iterating over (for example, to duplicate selected items) you must iterate over a copy.
The slice notation makes this particularly convenient:&gt;&gt;&gt; for x in a[:]: # make a slice copy of the entire list ...    if len(x) &gt; 6: a.insert(0, x) ...&gt;&gt;&gt; afar better solution would be to loop over a and build a list of thins you wanted to insert then loop over the things you wanted to insert list and modify a.immutable types are really for beginners and only case problems for people who actually can write code.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619292</id>
	<title>Re:Code format</title>
	<author>daVinci1980</author>
	<datestamp>1262364900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Citation needed.</p><p>The reason it's the number 80 was rather arbitrary, but a throwback to <a href="http://as400blog.blogspot.com/2009/05/80-column-punched-cards-and-history-of.html" title="blogspot.com">old punch-card systems.</a> [blogspot.com]</p></htmltext>
<tokenext>Citation needed.The reason it 's the number 80 was rather arbitrary , but a throwback to old punch-card systems .
[ blogspot.com ]</tokentext>
<sentencetext>Citation needed.The reason it's the number 80 was rather arbitrary, but a throwback to old punch-card systems.
[blogspot.com]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617800</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616810</id>
	<title>Re:Wrong on all accounts</title>
	<author>CAIMLAS</author>
	<datestamp>1262346540000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>What bothers me is not so much undocumented code, but undocumented functions and/or blocks of code. Main should be well documented, and a function should have a line or two explaining its function, but unless its particularly obtuse code, I don't want/need documentation.</p></htmltext>
<tokenext>What bothers me is not so much undocumented code , but undocumented functions and/or blocks of code .
Main should be well documented , and a function should have a line or two explaining its function , but unless its particularly obtuse code , I do n't want/need documentation .</tokentext>
<sentencetext>What bothers me is not so much undocumented code, but undocumented functions and/or blocks of code.
Main should be well documented, and a function should have a line or two explaining its function, but unless its particularly obtuse code, I don't want/need documentation.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30628362</id>
	<title>Raw nerve</title>
	<author>Anonymous</author>
	<datestamp>1262443500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>In a southern software company, the original developer (oh yes he was original) decided that it would be a good idea to delete all the comments from the code because he thought you should get inside his code and really understand it and not rely on unhelpful and potentially misleading hints such as comments.  I rather suspect that he did it because he was threatened by the chimps they hired as the monstrosity he had spawned began to require more and bodies to maintain -  a half a day for the most basic label change which usually went totally wrong.  The code was mostly crap with occasional really shitty bits.  Certain routines meant to run overnight took several hours.  I glimpsed inside this man's head from time to time and was afraid.  I'm still baffled how such garbage could have come so far (the company is let's just say not unsuccessful).</p><p>All I have to say unless you are absolutely positively sure that you are god's gift to programming and what you consider wonderfully elegant code is universally intelligible - DON'T BE A FUCKING DICK AND COMMENT YOUR WORK.</p><p>
&nbsp;</p></htmltext>
<tokenext>In a southern software company , the original developer ( oh yes he was original ) decided that it would be a good idea to delete all the comments from the code because he thought you should get inside his code and really understand it and not rely on unhelpful and potentially misleading hints such as comments .
I rather suspect that he did it because he was threatened by the chimps they hired as the monstrosity he had spawned began to require more and bodies to maintain - a half a day for the most basic label change which usually went totally wrong .
The code was mostly crap with occasional really shitty bits .
Certain routines meant to run overnight took several hours .
I glimpsed inside this man 's head from time to time and was afraid .
I 'm still baffled how such garbage could have come so far ( the company is let 's just say not unsuccessful ) .All I have to say unless you are absolutely positively sure that you are god 's gift to programming and what you consider wonderfully elegant code is universally intelligible - DO N'T BE A FUCKING DICK AND COMMENT YOUR WORK .
 </tokentext>
<sentencetext>In a southern software company, the original developer (oh yes he was original) decided that it would be a good idea to delete all the comments from the code because he thought you should get inside his code and really understand it and not rely on unhelpful and potentially misleading hints such as comments.
I rather suspect that he did it because he was threatened by the chimps they hired as the monstrosity he had spawned began to require more and bodies to maintain -  a half a day for the most basic label change which usually went totally wrong.
The code was mostly crap with occasional really shitty bits.
Certain routines meant to run overnight took several hours.
I glimpsed inside this man's head from time to time and was afraid.
I'm still baffled how such garbage could have come so far (the company is let's just say not unsuccessful).All I have to say unless you are absolutely positively sure that you are god's gift to programming and what you consider wonderfully elegant code is universally intelligible - DON'T BE A FUCKING DICK AND COMMENT YOUR WORK.
 </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617196</id>
	<title>Re:So who is this guy?</title>
	<author>oogoliegoogolie</author>
	<datestamp>1262349540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I have no idea who this guy is either.  Can someone fill us in?</p></htmltext>
<tokenext>I have no idea who this guy is either .
Can someone fill us in ?</tokentext>
<sentencetext>I have no idea who this guy is either.
Can someone fill us in?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616872</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617260</id>
	<title>Did anyone read the article?</title>
	<author>garg0yle</author>
	<datestamp>1262350020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The author's point (near as I can tell) isn't so much "comments are bad" as "most people comment incorrectly", which I would not argue with.</p><p>Nobody who's actually worked on other people's code in the wild will argue that comments are bad (at least, nobody sane), but there IS a right and wrong way to comment.  Unfortunately, while you can explain to newbies about commenting until you're blue in the face, they really won't "get it" until they've been there themselves.</p></htmltext>
<tokenext>The author 's point ( near as I can tell ) is n't so much " comments are bad " as " most people comment incorrectly " , which I would not argue with.Nobody who 's actually worked on other people 's code in the wild will argue that comments are bad ( at least , nobody sane ) , but there IS a right and wrong way to comment .
Unfortunately , while you can explain to newbies about commenting until you 're blue in the face , they really wo n't " get it " until they 've been there themselves .</tokentext>
<sentencetext>The author's point (near as I can tell) isn't so much "comments are bad" as "most people comment incorrectly", which I would not argue with.Nobody who's actually worked on other people's code in the wild will argue that comments are bad (at least, nobody sane), but there IS a right and wrong way to comment.
Unfortunately, while you can explain to newbies about commenting until you're blue in the face, they really won't "get it" until they've been there themselves.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617618</id>
	<title>Asshole CS Professor</title>
	<author>EmagGeek</author>
	<datestamp>1262352900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I had a real asshole of a CS professor in college (who will remain nameless) who insisted that every single line of code be commented. He took 10 points off an assignment once because I didn't comment a line that only had a closed brace on it.</p></htmltext>
<tokenext>I had a real asshole of a CS professor in college ( who will remain nameless ) who insisted that every single line of code be commented .
He took 10 points off an assignment once because I did n't comment a line that only had a closed brace on it .</tokentext>
<sentencetext>I had a real asshole of a CS professor in college (who will remain nameless) who insisted that every single line of code be commented.
He took 10 points off an assignment once because I didn't comment a line that only had a closed brace on it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30654974</id>
	<title>Re:In other news...</title>
	<author>Anonymous</author>
	<datestamp>1262707740000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>I think that if more people wrote code (or, for that matter, books) like George Orwell wrote his books, code (and books) would be generally more readable: shorter sentences (lines of code) which convey a single meaning (function), strung together into short paragraphs (code blocks), chained together into a larger cohesive whole.</p></div><p>Was this meant ironically?</p></div>
	</htmltext>
<tokenext>I think that if more people wrote code ( or , for that matter , books ) like George Orwell wrote his books , code ( and books ) would be generally more readable : shorter sentences ( lines of code ) which convey a single meaning ( function ) , strung together into short paragraphs ( code blocks ) , chained together into a larger cohesive whole.Was this meant ironically ?</tokentext>
<sentencetext>I think that if more people wrote code (or, for that matter, books) like George Orwell wrote his books, code (and books) would be generally more readable: shorter sentences (lines of code) which convey a single meaning (function), strung together into short paragraphs (code blocks), chained together into a larger cohesive whole.Was this meant ironically?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616776</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30625112</id>
	<title>Re:Not commenting is a sign of not thinking or car</title>
	<author>Anonymous</author>
	<datestamp>1262464380000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Bravo!  Surprising that you have achieved so much insight in your short career of two or three high school projects, congratulations!</p></htmltext>
<tokenext>Bravo !
Surprising that you have achieved so much insight in your short career of two or three high school projects , congratulations !</tokentext>
<sentencetext>Bravo!
Surprising that you have achieved so much insight in your short career of two or three high school projects, congratulations!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616936</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30623854</id>
	<title>Second Class Citizens: Code Comments</title>
	<author>Anonymous</author>
	<datestamp>1262457180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I think that code should contain no comments at all.</p><p>Notice that I did not say that code should not be commented.</p><p>The problem here is that we are trying to do two things together, where we should be doing them separately. I'm envisioning a development environment that gives you control over your comments - you don't put them in the code - they live separately and are anchored to the code. They could be viewed separately (or together with the code), expanded and collapsed, and nested for varying levels of explanation.</p><p>Comments today are second class citizens, but we should be thinking about providing a full set of features around the commenting of our code,</p></htmltext>
<tokenext>I think that code should contain no comments at all.Notice that I did not say that code should not be commented.The problem here is that we are trying to do two things together , where we should be doing them separately .
I 'm envisioning a development environment that gives you control over your comments - you do n't put them in the code - they live separately and are anchored to the code .
They could be viewed separately ( or together with the code ) , expanded and collapsed , and nested for varying levels of explanation.Comments today are second class citizens , but we should be thinking about providing a full set of features around the commenting of our code,</tokentext>
<sentencetext>I think that code should contain no comments at all.Notice that I did not say that code should not be commented.The problem here is that we are trying to do two things together, where we should be doing them separately.
I'm envisioning a development environment that gives you control over your comments - you don't put them in the code - they live separately and are anchored to the code.
They could be viewed separately (or together with the code), expanded and collapsed, and nested for varying levels of explanation.Comments today are second class citizens, but we should be thinking about providing a full set of features around the commenting of our code,</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617110</id>
	<title>This guy is WRONG.</title>
	<author>sootman</author>
	<datestamp>1262349060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"documenting something that needs no documentation is universally a bad idea"</p><p>-- yeah, because everyone in the world has the exact same experience and knowledge, so something that's obvious to one person is obvious to the rest of the world and vice-versa. And nobody ever changes, learns new things, or uses things that are obvious now but will be completely forgotten after five years of not using that particular construct.</p><p>This guy's opinions are worth less than the comments he eschews.</p></htmltext>
<tokenext>" documenting something that needs no documentation is universally a bad idea " -- yeah , because everyone in the world has the exact same experience and knowledge , so something that 's obvious to one person is obvious to the rest of the world and vice-versa .
And nobody ever changes , learns new things , or uses things that are obvious now but will be completely forgotten after five years of not using that particular construct.This guy 's opinions are worth less than the comments he eschews .</tokentext>
<sentencetext>"documenting something that needs no documentation is universally a bad idea"-- yeah, because everyone in the world has the exact same experience and knowledge, so something that's obvious to one person is obvious to the rest of the world and vice-versa.
And nobody ever changes, learns new things, or uses things that are obvious now but will be completely forgotten after five years of not using that particular construct.This guy's opinions are worth less than the comments he eschews.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617682</id>
	<title>Decommented</title>
	<author>Anonymous</author>
	<datestamp>1262353260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Here's some of <a href="http://www-personal.umich.edu/~wagnerr/MersenneTwister.html" title="umich.edu">my own code</a> [umich.edu] with the comments removed:<blockquote><div><p> <tt>uint32 randInt();<br>uint32 randInt( const uint32 n );<br>double rand();<br>double rand( const double n );<br>double randExc();<br>double randExc( const double n );<br>double randDblExc();<br>double randDblExc( const double n );<br>double operator()();<br> <br>inline MTRand::uint32 MTRand::randInt( const uint32 n )<br>{<br>  uint32 used = n;<br>  used |= used &gt;&gt; 1;<br>  used |= used &gt;&gt; 2;<br>  used |= used &gt;&gt; 4;<br>  used |= used &gt;&gt; 8;<br>  used |= used &gt;&gt; 16;<br> <br>  uint32 i;<br>  do<br>    i = randInt() &amp; used;<br>  while( i &gt; n );<br>  return i;<br>}</tt></p></div> </blockquote><p>And here are the missing comments:</p><blockquote><div><p> <tt>Access to 32-bit random numbers<br>integer in [0,2^32-1]<br>integer in [0,n] for n &lt; 2^32<br>real number in [0,1]<br>real number in [0,n]<br>real number in [0,1)<br>real number in [0,n)<br>real number in (0,1)<br>real number in (0,n)<br>same as rand()<br> <br>Find which bits are used in n<br>Optimized by Magnus Jonsson (magnus@smartelectronix.com)<br>Draw numbers until one is found in [0,n]<br> toss unused bits to shorten search<br> <br>v1.0 Revised seeding to match 26 Jan 2002 update of Nishimura and Matsumoto<br>Allowed for seeding with arrays of any length<br>Added access for real numbers in [0,1) with 53-bit resolution<br>Added access for real numbers from normal (Gaussian) distributions<br>Increased overall speed by optimizing twist()<br>Doubled speed of integer [0,n] generation<br>Fixed out-of-range number generation on 64-bit machines<br>Improved portability by substituting literal constants for long enum's<br>Changed license from GNU LGPL to BSD</tt></p></div> </blockquote><p>Did you fully understand the code by itself? Are any of these comments harmful? Would anyone seriously rather have the code without the comments?</p></div>
	</htmltext>
<tokenext>Here 's some of my own code [ umich.edu ] with the comments removed : uint32 randInt ( ) ; uint32 randInt ( const uint32 n ) ; double rand ( ) ; double rand ( const double n ) ; double randExc ( ) ; double randExc ( const double n ) ; double randDblExc ( ) ; double randDblExc ( const double n ) ; double operator ( ) ( ) ; inline MTRand : : uint32 MTRand : : randInt ( const uint32 n ) { uint32 used = n ; used | = used &gt; &gt; 1 ; used | = used &gt; &gt; 2 ; used | = used &gt; &gt; 4 ; used | = used &gt; &gt; 8 ; used | = used &gt; &gt; 16 ; uint32 i ; do i = randInt ( ) &amp; used ; while ( i &gt; n ) ; return i ; } And here are the missing comments : Access to 32-bit random numbersinteger in [ 0,2 ^ 32-1 ] integer in [ 0,n ] for n real number in [ 0,1 ] real number in [ 0,n ] real number in [ 0,1 ) real number in [ 0,n ) real number in ( 0,1 ) real number in ( 0,n ) same as rand ( ) Find which bits are used in nOptimized by Magnus Jonsson ( magnus @ smartelectronix.com ) Draw numbers until one is found in [ 0,n ] toss unused bits to shorten search v1.0 Revised seeding to match 26 Jan 2002 update of Nishimura and MatsumotoAllowed for seeding with arrays of any lengthAdded access for real numbers in [ 0,1 ) with 53-bit resolutionAdded access for real numbers from normal ( Gaussian ) distributionsIncreased overall speed by optimizing twist ( ) Doubled speed of integer [ 0,n ] generationFixed out-of-range number generation on 64-bit machinesImproved portability by substituting literal constants for long enum'sChanged license from GNU LGPL to BSD Did you fully understand the code by itself ?
Are any of these comments harmful ?
Would anyone seriously rather have the code without the comments ?</tokentext>
<sentencetext>Here's some of my own code [umich.edu] with the comments removed: uint32 randInt();uint32 randInt( const uint32 n );double rand();double rand( const double n );double randExc();double randExc( const double n );double randDblExc();double randDblExc( const double n );double operator()(); inline MTRand::uint32 MTRand::randInt( const uint32 n ){  uint32 used = n;  used |= used &gt;&gt; 1;  used |= used &gt;&gt; 2;  used |= used &gt;&gt; 4;  used |= used &gt;&gt; 8;  used |= used &gt;&gt; 16;   uint32 i;  do    i = randInt() &amp; used;  while( i &gt; n );  return i;} And here are the missing comments: Access to 32-bit random numbersinteger in [0,2^32-1]integer in [0,n] for n real number in [0,1]real number in [0,n]real number in [0,1)real number in [0,n)real number in (0,1)real number in (0,n)same as rand() Find which bits are used in nOptimized by Magnus Jonsson (magnus@smartelectronix.com)Draw numbers until one is found in [0,n] toss unused bits to shorten search v1.0 Revised seeding to match 26 Jan 2002 update of Nishimura and MatsumotoAllowed for seeding with arrays of any lengthAdded access for real numbers in [0,1) with 53-bit resolutionAdded access for real numbers from normal (Gaussian) distributionsIncreased overall speed by optimizing twist()Doubled speed of integer [0,n] generationFixed out-of-range number generation on 64-bit machinesImproved portability by substituting literal constants for long enum'sChanged license from GNU LGPL to BSD Did you fully understand the code by itself?
Are any of these comments harmful?
Would anyone seriously rather have the code without the comments?
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30623250</id>
	<title>Re:The flipside</title>
	<author>merreborn</author>
	<datestamp>1262454060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>For what it's worth, your diatribe comes off as fairly melodramatic.  You'd do well with a rewrite that puts more emphasis on the largest issues (management having no idea how long projects should take, lack of air conditioning, coworkers incapable of basic communication), de-emphasizing the most trivial complaints (manager that checks in "up to 3 times a day"?  A company focused on profit? These seem par for the course), and omitting the dramatic hyperbole entirely -- especially the repeated mentions of being "almost in tears", and the paragraph of suicidal ideations.</p><p>It was clearly a lousy job, and you were right to leave, but the way you've written your account doesn't put you in a terribly positive light either.</p></htmltext>
<tokenext>For what it 's worth , your diatribe comes off as fairly melodramatic .
You 'd do well with a rewrite that puts more emphasis on the largest issues ( management having no idea how long projects should take , lack of air conditioning , coworkers incapable of basic communication ) , de-emphasizing the most trivial complaints ( manager that checks in " up to 3 times a day " ?
A company focused on profit ?
These seem par for the course ) , and omitting the dramatic hyperbole entirely -- especially the repeated mentions of being " almost in tears " , and the paragraph of suicidal ideations.It was clearly a lousy job , and you were right to leave , but the way you 've written your account does n't put you in a terribly positive light either .</tokentext>
<sentencetext>For what it's worth, your diatribe comes off as fairly melodramatic.
You'd do well with a rewrite that puts more emphasis on the largest issues (management having no idea how long projects should take, lack of air conditioning, coworkers incapable of basic communication), de-emphasizing the most trivial complaints (manager that checks in "up to 3 times a day"?
A company focused on profit?
These seem par for the course), and omitting the dramatic hyperbole entirely -- especially the repeated mentions of being "almost in tears", and the paragraph of suicidal ideations.It was clearly a lousy job, and you were right to leave, but the way you've written your account doesn't put you in a terribly positive light either.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617190</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618118</id>
	<title>The Commentator</title>
	<author>EatAtJoes</author>
	<datestamp>1262355600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>So far as I know there's no automatic system that will generate the comments that the author failed to put in</p></div></blockquote><p>you've obviously not heard of <a href="http://www.cenqua.com/commentator/" title="cenqua.com" rel="nofollow">The Commentator</a> [cenqua.com]<nobr> <wbr></nobr>...</p></div>
	</htmltext>
<tokenext>So far as I know there 's no automatic system that will generate the comments that the author failed to put inyou 've obviously not heard of The Commentator [ cenqua.com ] .. .</tokentext>
<sentencetext>So far as I know there's no automatic system that will generate the comments that the author failed to put inyou've obviously not heard of The Commentator [cenqua.com] ...
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616836</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618520</id>
	<title>Re:Strongly RESTRICT Code Commenting</title>
	<author>JoeMerchant</author>
	<datestamp>1262357940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>
One routine I have written a couple of times that NEEDS comments is a cubic spline interpolation, the algebra is thick, and if you do it well, your code skips about 80\% of the steps due to zero values in the variables.  Even with the zeroing, there are about a half dozen intermediate variables computed and it is all too easy to make a mistake along the way.</htmltext>
<tokenext>One routine I have written a couple of times that NEEDS comments is a cubic spline interpolation , the algebra is thick , and if you do it well , your code skips about 80 \ % of the steps due to zero values in the variables .
Even with the zeroing , there are about a half dozen intermediate variables computed and it is all too easy to make a mistake along the way .</tokentext>
<sentencetext>
One routine I have written a couple of times that NEEDS comments is a cubic spline interpolation, the algebra is thick, and if you do it well, your code skips about 80\% of the steps due to zero values in the variables.
Even with the zeroing, there are about a half dozen intermediate variables computed and it is all too easy to make a mistake along the way.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617052</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622488</id>
	<title>Code Complete</title>
	<author>minstrelmike</author>
	<datestamp>1262449740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Best book on coding is Code Complete. Also has the best advice on comments.
<br>
If the variables and functions are named AND USED correctly and <br>
you don't comment on standard procedures open(fname)<nobr> <wbr></nobr>// open filename
<br>
then there is very little that needs commenting.</htmltext>
<tokenext>Best book on coding is Code Complete .
Also has the best advice on comments .
If the variables and functions are named AND USED correctly and you do n't comment on standard procedures open ( fname ) // open filename then there is very little that needs commenting .</tokentext>
<sentencetext>Best book on coding is Code Complete.
Also has the best advice on comments.
If the variables and functions are named AND USED correctly and 
you don't comment on standard procedures open(fname) // open filename

then there is very little that needs commenting.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619428</id>
	<title>"Midlertidig" means temporary</title>
	<author>jonaskoelker</author>
	<datestamp>1262366520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>- 1 comment - the single word "midlertidig"</p></div><p>FWIW, "midlertidig" means temporary.  My guess is that it wasn't used for a local variable in a `<tt>swap</tt>' method<nobr> <wbr></nobr>;)</p></div>
	</htmltext>
<tokenext>- 1 comment - the single word " midlertidig " FWIW , " midlertidig " means temporary .
My guess is that it was n't used for a local variable in a ` swap ' method ; )</tokentext>
<sentencetext>- 1 comment - the single word "midlertidig"FWIW, "midlertidig" means temporary.
My guess is that it wasn't used for a local variable in a `swap' method ;)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617380</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617760</id>
	<title>Re:Warning - war story ahead</title>
	<author>Anonymous</author>
	<datestamp>1262353560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Yeah, but you could actually do something useful with 6000 lines of code in those days...</p></htmltext>
<tokenext>Yeah , but you could actually do something useful with 6000 lines of code in those days.. .</tokentext>
<sentencetext>Yeah, but you could actually do something useful with 6000 lines of code in those days...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617380</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617782</id>
	<title>Re:Has No One Actually Studied This?</title>
	<author>jim\_v2000</author>
	<datestamp>1262353740000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext>&gt; they found that in general the more comments in the code, the more problems were reported against i
<br> <br>
The obvious solution then is to simply ban employees from using comments in code.</htmltext>
<tokenext>&gt; they found that in general the more comments in the code , the more problems were reported against i The obvious solution then is to simply ban employees from using comments in code .</tokentext>
<sentencetext>&gt; they found that in general the more comments in the code, the more problems were reported against i
 
The obvious solution then is to simply ban employees from using comments in code.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616750</id>
	<title>Re:One person's myth is another person's fact.</title>
	<author>Anonymous</author>
	<datestamp>1262345940000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>I work on a really big hunk of C code and one place I would like to see more comments is in the start and end of blocks. This is because during the life of the code people come in and paste maybe 1000 lines of code from elsewhere into the block and totally stuff up the indenting so its hard to see what is supposed to match to what. This is particularly a problem with importing between branches (my job at the moment) because it can be hard to work out the original intent of the various nested blocks you wind up with.</p><p>Commented out code is a particular problem because my editor can count { and } but it doesn't know if some of those have been commented out, possibly asymmetrically.</p><p>Where I work comments get used to abuse people. You commit a message:<br>
&nbsp; <br><nobr> <wbr></nobr><tt>/*Hey $YOU dont do this again */</tt> </p><p>But a lot of the comments we have I can't even read because they have been collected by the code in one of the countries it has been to over the last 30 years or so. Many of them seem to be in French and Arabic.</p></htmltext>
<tokenext>I work on a really big hunk of C code and one place I would like to see more comments is in the start and end of blocks .
This is because during the life of the code people come in and paste maybe 1000 lines of code from elsewhere into the block and totally stuff up the indenting so its hard to see what is supposed to match to what .
This is particularly a problem with importing between branches ( my job at the moment ) because it can be hard to work out the original intent of the various nested blocks you wind up with.Commented out code is a particular problem because my editor can count { and } but it does n't know if some of those have been commented out , possibly asymmetrically.Where I work comments get used to abuse people .
You commit a message :   / * Hey $ YOU dont do this again * / But a lot of the comments we have I ca n't even read because they have been collected by the code in one of the countries it has been to over the last 30 years or so .
Many of them seem to be in French and Arabic .</tokentext>
<sentencetext>I work on a really big hunk of C code and one place I would like to see more comments is in the start and end of blocks.
This is because during the life of the code people come in and paste maybe 1000 lines of code from elsewhere into the block and totally stuff up the indenting so its hard to see what is supposed to match to what.
This is particularly a problem with importing between branches (my job at the moment) because it can be hard to work out the original intent of the various nested blocks you wind up with.Commented out code is a particular problem because my editor can count { and } but it doesn't know if some of those have been commented out, possibly asymmetrically.Where I work comments get used to abuse people.
You commit a message:
   /*Hey $YOU dont do this again */ But a lot of the comments we have I can't even read because they have been collected by the code in one of the countries it has been to over the last 30 years or so.
Many of them seem to be in French and Arabic.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616696</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617158</id>
	<title>compares to all professions</title>
	<author>DaveGod</author>
	<datestamp>1262349240000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>Working in accountancy (and doubly-so for audit) a well-commented file is absolutely necessary. Like (I suspect) computer code, the file should stand on it's own - a competent fellow professional should be able to fully understand it and be comfortable reaching the same conclusions. This is not only good practice for the benefit of your firm but a professional requirement: my institute comes along every few years, selects a few files and basically if they have difficulty understanding the file (or worse, reached different conclusions) then you're in a lot of trouble.</p><p>Many of the points in TFA hold up well however - explaining things unnecessarily merely adds bloat, irritates and wastes the time of the reader by telling them obvious, patronising or pointless things. And yes, a perfect accounts job doesn't require any explanation because the schedules will be self-explanatory. </p><p>The thing is though, if you're doing anything complex (earning your salary), have to make corrections (hackjobs) or judgements then you need explanations. Manager's will be reviewing your work and you or a colleague will be referring to it next year. If explanations go out of date, update them - if they had value before then value is there in updating them. Yes there is a cost, so there is a tradeoff vs their value to the file. The key is <i>competent fellow professional</i>. Assume your colleague will be reviewing your work and be satisfied that they will be able to understand and appreciate it.</p><p>If you're just churning out "stuff that works" then you're at best a technician. </p></htmltext>
<tokenext>Working in accountancy ( and doubly-so for audit ) a well-commented file is absolutely necessary .
Like ( I suspect ) computer code , the file should stand on it 's own - a competent fellow professional should be able to fully understand it and be comfortable reaching the same conclusions .
This is not only good practice for the benefit of your firm but a professional requirement : my institute comes along every few years , selects a few files and basically if they have difficulty understanding the file ( or worse , reached different conclusions ) then you 're in a lot of trouble.Many of the points in TFA hold up well however - explaining things unnecessarily merely adds bloat , irritates and wastes the time of the reader by telling them obvious , patronising or pointless things .
And yes , a perfect accounts job does n't require any explanation because the schedules will be self-explanatory .
The thing is though , if you 're doing anything complex ( earning your salary ) , have to make corrections ( hackjobs ) or judgements then you need explanations .
Manager 's will be reviewing your work and you or a colleague will be referring to it next year .
If explanations go out of date , update them - if they had value before then value is there in updating them .
Yes there is a cost , so there is a tradeoff vs their value to the file .
The key is competent fellow professional .
Assume your colleague will be reviewing your work and be satisfied that they will be able to understand and appreciate it.If you 're just churning out " stuff that works " then you 're at best a technician .</tokentext>
<sentencetext>Working in accountancy (and doubly-so for audit) a well-commented file is absolutely necessary.
Like (I suspect) computer code, the file should stand on it's own - a competent fellow professional should be able to fully understand it and be comfortable reaching the same conclusions.
This is not only good practice for the benefit of your firm but a professional requirement: my institute comes along every few years, selects a few files and basically if they have difficulty understanding the file (or worse, reached different conclusions) then you're in a lot of trouble.Many of the points in TFA hold up well however - explaining things unnecessarily merely adds bloat, irritates and wastes the time of the reader by telling them obvious, patronising or pointless things.
And yes, a perfect accounts job doesn't require any explanation because the schedules will be self-explanatory.
The thing is though, if you're doing anything complex (earning your salary), have to make corrections (hackjobs) or judgements then you need explanations.
Manager's will be reviewing your work and you or a colleague will be referring to it next year.
If explanations go out of date, update them - if they had value before then value is there in updating them.
Yes there is a cost, so there is a tradeoff vs their value to the file.
The key is competent fellow professional.
Assume your colleague will be reviewing your work and be satisfied that they will be able to understand and appreciate it.If you're just churning out "stuff that works" then you're at best a technician. </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620898</id>
	<title>Re:every line of code should be commented</title>
	<author>Anonymous</author>
	<datestamp>1262429760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>FAIL</p><p>You forgot to comment "else"</p></htmltext>
<tokenext>FAILYou forgot to comment " else "</tokentext>
<sentencetext>FAILYou forgot to comment "else"</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616920</id>
	<title>"would you rather use a one-liner"</title>
	<author>lax-goalie</author>
	<datestamp>1262347380000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><blockquote><div><p>would you rather use a one-liner that requires a 3-line comment, or a 10-liner that requires no comments?</p></div></blockquote><p>Easy. 10 lines, no comments. After writing a couple of million lines of code, the more code I write, the more I unwind it. Somewhere along the line, adolescent programmers got the idea that jamming all your logic into as few unreadable lines as possible is the fastest way to manliness. Way, way wrong.</p><p>Modern compilers and interpreters do a pretty good job nowadays. Source code bytes are near free. If you have to skull out dense code 6 months after you've written it, you're doing something wrong.</p><p>(OK, Lisp and APL are special cases, but really, when's the last time you wrote Lisp or APL, other than for fun?)</p></div>
	</htmltext>
<tokenext>would you rather use a one-liner that requires a 3-line comment , or a 10-liner that requires no comments ? Easy .
10 lines , no comments .
After writing a couple of million lines of code , the more code I write , the more I unwind it .
Somewhere along the line , adolescent programmers got the idea that jamming all your logic into as few unreadable lines as possible is the fastest way to manliness .
Way , way wrong.Modern compilers and interpreters do a pretty good job nowadays .
Source code bytes are near free .
If you have to skull out dense code 6 months after you 've written it , you 're doing something wrong .
( OK , Lisp and APL are special cases , but really , when 's the last time you wrote Lisp or APL , other than for fun ?
)</tokentext>
<sentencetext>would you rather use a one-liner that requires a 3-line comment, or a 10-liner that requires no comments?Easy.
10 lines, no comments.
After writing a couple of million lines of code, the more code I write, the more I unwind it.
Somewhere along the line, adolescent programmers got the idea that jamming all your logic into as few unreadable lines as possible is the fastest way to manliness.
Way, way wrong.Modern compilers and interpreters do a pretty good job nowadays.
Source code bytes are near free.
If you have to skull out dense code 6 months after you've written it, you're doing something wrong.
(OK, Lisp and APL are special cases, but really, when's the last time you wrote Lisp or APL, other than for fun?
)
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618208</id>
	<title>Good Comments Are Good</title>
	<author>Greyfox</author>
	<datestamp>1262355960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I've seen some well commented projects where the code comments were really the only thing you could read to get a handle on the business logic behind the application. Occasionally you'll read a comment and realize that the original programmer had a misconception about how the next bit was actually supposed to work. Maintenance programming is as much about understanding the state of mind of the guy who wrote it originally as it is about writing code.</htmltext>
<tokenext>I 've seen some well commented projects where the code comments were really the only thing you could read to get a handle on the business logic behind the application .
Occasionally you 'll read a comment and realize that the original programmer had a misconception about how the next bit was actually supposed to work .
Maintenance programming is as much about understanding the state of mind of the guy who wrote it originally as it is about writing code .</tokentext>
<sentencetext>I've seen some well commented projects where the code comments were really the only thing you could read to get a handle on the business logic behind the application.
Occasionally you'll read a comment and realize that the original programmer had a misconception about how the next bit was actually supposed to work.
Maintenance programming is as much about understanding the state of mind of the guy who wrote it originally as it is about writing code.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621864</id>
	<title>Re:More verbose == less readable?</title>
	<author>tanderson92</author>
	<datestamp>1262443920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>First, I think any time you consider writing some clever one-liner in real production code you should rethink long and hard.  Is the hypothetical 6 fewer lines of code really worth it?  Unless you're doing it for absolutely required performance reasons, the 6 lines of code you save won't buy you anything but the wrath of whoever has to come along in 3 years and refactor your code.</p></div><p>Given your inability to properly subtract I think you've had performance problems not just in your code, but in school as well.</p></div>
	</htmltext>
<tokenext>First , I think any time you consider writing some clever one-liner in real production code you should rethink long and hard .
Is the hypothetical 6 fewer lines of code really worth it ?
Unless you 're doing it for absolutely required performance reasons , the 6 lines of code you save wo n't buy you anything but the wrath of whoever has to come along in 3 years and refactor your code.Given your inability to properly subtract I think you 've had performance problems not just in your code , but in school as well .</tokentext>
<sentencetext>First, I think any time you consider writing some clever one-liner in real production code you should rethink long and hard.
Is the hypothetical 6 fewer lines of code really worth it?
Unless you're doing it for absolutely required performance reasons, the 6 lines of code you save won't buy you anything but the wrath of whoever has to come along in 3 years and refactor your code.Given your inability to properly subtract I think you've had performance problems not just in your code, but in school as well.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616770</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621850</id>
	<title>Re:Has No One Actually Studied This?</title>
	<author>Anonymous</author>
	<datestamp>1262443800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Yeah, sure. Messy code get fixes. Developper fixing a messy code add comments. Hence messy code have comments.</p><p>Correlation != causality.</p><p>And probably, half of the comments were:<nobr> <wbr></nobr>// Fix for #34212<nobr> <wbr></nobr>// Fix for #41223</p><p>etc, etc</p></htmltext>
<tokenext>Yeah , sure .
Messy code get fixes .
Developper fixing a messy code add comments .
Hence messy code have comments.Correlation ! = causality.And probably , half of the comments were : // Fix for # 34212 // Fix for # 41223etc , etc</tokentext>
<sentencetext>Yeah, sure.
Messy code get fixes.
Developper fixing a messy code add comments.
Hence messy code have comments.Correlation != causality.And probably, half of the comments were: // Fix for #34212 // Fix for #41223etc, etc</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622316</id>
	<title>what about bugfixes?</title>
	<author>Anonymous</author>
	<datestamp>1262448180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>A project is not just about the codebase anymore: now we've got issue tracking<br>systems and (D)VCSes ruling the day.</p><p>Seeing your code as something independent is foolish for anything but the<br>smallest toy-ish project.</p><p>I like something like:</p><p>bugfix for issue ${your-favorite-bug-tracking-system-bug-number here}</p><p>or even:</p><p>bugfix for issue ${your-favorite-bug-tracking-system-bug-number here} introduced in changeset 5b8362e108fc</p><p>Should you ever change from (D)VCS (Mercurial here), you can write a script to automatically update<br>all the changesets reference.</p><p>That's how they do it in "Real-World[TM]" millions-and-millions line of code projects<br>where you need both the code and references to discussions / bugs description<br>concerning said code.</p><p>The OpenJDK comes to mind.</p><p>Millions and millions of lines, I tell ya, you should listen kids<nobr> <wbr></nobr>;)</p></htmltext>
<tokenext>A project is not just about the codebase anymore : now we 've got issue trackingsystems and ( D ) VCSes ruling the day.Seeing your code as something independent is foolish for anything but thesmallest toy-ish project.I like something like : bugfix for issue $ { your-favorite-bug-tracking-system-bug-number here } or even : bugfix for issue $ { your-favorite-bug-tracking-system-bug-number here } introduced in changeset 5b8362e108fcShould you ever change from ( D ) VCS ( Mercurial here ) , you can write a script to automatically updateall the changesets reference.That 's how they do it in " Real-World [ TM ] " millions-and-millions line of code projectswhere you need both the code and references to discussions / bugs descriptionconcerning said code.The OpenJDK comes to mind.Millions and millions of lines , I tell ya , you should listen kids ; )</tokentext>
<sentencetext>A project is not just about the codebase anymore: now we've got issue trackingsystems and (D)VCSes ruling the day.Seeing your code as something independent is foolish for anything but thesmallest toy-ish project.I like something like:bugfix for issue ${your-favorite-bug-tracking-system-bug-number here}or even:bugfix for issue ${your-favorite-bug-tracking-system-bug-number here} introduced in changeset 5b8362e108fcShould you ever change from (D)VCS (Mercurial here), you can write a script to automatically updateall the changesets reference.That's how they do it in "Real-World[TM]" millions-and-millions line of code projectswhere you need both the code and references to discussions / bugs descriptionconcerning said code.The OpenJDK comes to mind.Millions and millions of lines, I tell ya, you should listen kids ;)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620578</id>
	<title>Re:Warning - war story ahead</title>
	<author>Anonymous</author>
	<datestamp>1262424660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>A couple of dozen globals can make code hell. I really hope you don't ever need to fix (or change) software like that. It bloody \_better\_ work OOTB.</p></htmltext>
<tokenext>A couple of dozen globals can make code hell .
I really hope you do n't ever need to fix ( or change ) software like that .
It bloody \ _better \ _ work OOTB .</tokentext>
<sentencetext>A couple of dozen globals can make code hell.
I really hope you don't ever need to fix (or change) software like that.
It bloody \_better\_ work OOTB.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617380</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620962</id>
	<title>Comments dont help with other peoples code</title>
	<author>keean</author>
	<datestamp>1262430900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>As someone who frequently gets asked to work with code written elsewhere, adding features, fixing bugs etc, I find comments in code mostly useless. Reading and understanding the code is the only way to really understand what is going on. I find the comments don't really save time, as if there is a bug in the code, the original programmer did not understand the code anyway.</htmltext>
<tokenext>As someone who frequently gets asked to work with code written elsewhere , adding features , fixing bugs etc , I find comments in code mostly useless .
Reading and understanding the code is the only way to really understand what is going on .
I find the comments do n't really save time , as if there is a bug in the code , the original programmer did not understand the code anyway .</tokentext>
<sentencetext>As someone who frequently gets asked to work with code written elsewhere, adding features, fixing bugs etc, I find comments in code mostly useless.
Reading and understanding the code is the only way to really understand what is going on.
I find the comments don't really save time, as if there is a bug in the code, the original programmer did not understand the code anyway.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30626218</id>
	<title>Re:Wrong on all accounts</title>
	<author>johanatan</author>
	<datestamp>1262427840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I agree.  I read a lot of code and if the quality is such that you'd want to keep it, comments are only needed when something is non-obvious (e.g., when equations or data from an external source are encoded).</htmltext>
<tokenext>I agree .
I read a lot of code and if the quality is such that you 'd want to keep it , comments are only needed when something is non-obvious ( e.g. , when equations or data from an external source are encoded ) .</tokentext>
<sentencetext>I agree.
I read a lot of code and if the quality is such that you'd want to keep it, comments are only needed when something is non-obvious (e.g., when equations or data from an external source are encoded).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616810</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617322</id>
	<title>self-documenting</title>
	<author>onefriedrice</author>
	<datestamp>1262350560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>4) Code must always be 'self documenting' ('would you rather use a one-liner that requires a 3-line comment, or a 10-liner that requires no comments?')</p></div><p>Not sure if that example supports his claim very well...  After all, four lines is less than ten, and if you can adequately describe what the function <i>should</i> do in three lines, somebody should easily be able to flesh it out themselves if ever a need arises.  I'm all for self-documenting code, but for functions that are simple enough to be implemented in one line, I say go for it.  We've got deadlines, people.</p></div>
	</htmltext>
<tokenext>4 ) Code must always be 'self documenting ' ( 'would you rather use a one-liner that requires a 3-line comment , or a 10-liner that requires no comments ?
' ) Not sure if that example supports his claim very well... After all , four lines is less than ten , and if you can adequately describe what the function should do in three lines , somebody should easily be able to flesh it out themselves if ever a need arises .
I 'm all for self-documenting code , but for functions that are simple enough to be implemented in one line , I say go for it .
We 've got deadlines , people .</tokentext>
<sentencetext>4) Code must always be 'self documenting' ('would you rather use a one-liner that requires a 3-line comment, or a 10-liner that requires no comments?
')Not sure if that example supports his claim very well...  After all, four lines is less than ten, and if you can adequately describe what the function should do in three lines, somebody should easily be able to flesh it out themselves if ever a need arises.
I'm all for self-documenting code, but for functions that are simple enough to be implemented in one line, I say go for it.
We've got deadlines, people.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617380</id>
	<title>Warning - war story ahead</title>
	<author>tengwar</author>
	<datestamp>1262350980000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext>My favourite bit of code was about 22 years ago. It was supposed to control some scientific equipment that we had bought from Denmark, and I had insisted on getting the source because of previous problems with the supplier. In summary:<p>

- 6000 lines of Pascal<br>
- 200 global variables<br>
- 3 local variables<br>
- 1 comment - the single word "midlertidig"</p><p>

Oh, and one bug. Code really was less buggy back then.</p><p>
Now get off my lawn, you kids.</p></htmltext>
<tokenext>My favourite bit of code was about 22 years ago .
It was supposed to control some scientific equipment that we had bought from Denmark , and I had insisted on getting the source because of previous problems with the supplier .
In summary : - 6000 lines of Pascal - 200 global variables - 3 local variables - 1 comment - the single word " midlertidig " Oh , and one bug .
Code really was less buggy back then .
Now get off my lawn , you kids .</tokentext>
<sentencetext>My favourite bit of code was about 22 years ago.
It was supposed to control some scientific equipment that we had bought from Denmark, and I had insisted on getting the source because of previous problems with the supplier.
In summary:

- 6000 lines of Pascal
- 200 global variables
- 3 local variables
- 1 comment - the single word "midlertidig"

Oh, and one bug.
Code really was less buggy back then.
Now get off my lawn, you kids.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618620</id>
	<title>Lengthy legalese...</title>
	<author>FriendlyPrimate</author>
	<datestamp>1262358780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><nobr> <wbr></nobr></p><div class="quote"><p>...
The other thing to be avoided is lengthy legalese or copyright information spread all over code. If this is necessary, at all, it should fit on one line and if necessary reference a COPYRIGHT or LEGAL file<nobr> <wbr></nobr>...</p></div><p>You know....for many of us developers, this legalese is dictated by company lawyers.  We can't simply "avoid" putting this legalese in our code.</p></div>
	</htmltext>
<tokenext>.. . The other thing to be avoided is lengthy legalese or copyright information spread all over code .
If this is necessary , at all , it should fit on one line and if necessary reference a COPYRIGHT or LEGAL file ...You know....for many of us developers , this legalese is dictated by company lawyers .
We ca n't simply " avoid " putting this legalese in our code .</tokentext>
<sentencetext> ...
The other thing to be avoided is lengthy legalese or copyright information spread all over code.
If this is necessary, at all, it should fit on one line and if necessary reference a COPYRIGHT or LEGAL file ...You know....for many of us developers, this legalese is dictated by company lawyers.
We can't simply "avoid" putting this legalese in our code.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617052</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618032</id>
	<title>Re:Wrong on all accounts</title>
	<author>0xdeadbeef</author>
	<datestamp>1262355120000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>If you have to "decipher" code, it is wasn't good to begin with. I used to believe the comment religion, it was beat into us in school, but once I started working with people with similar or greater skill than mine, I noticed that comments became few and far between. Usually they are only necessary to explain the intersection with something external or poorly designed, such as an API call or hackish work-around. Comments are no substitute for not knowing the problem domain. If you need to educate a new hire, you should already have documentation that explains the architecture.</p><p>If you want to talk unprofessional, the absolute worst are comments that state the obvious. It's like watching a movie with an imbecile talking to the screen, telling himself everything that is happening. It goes without saying that those comments are usually uncapitalized, lacking punctuation, and full of misspellings.</p></htmltext>
<tokenext>If you have to " decipher " code , it is was n't good to begin with .
I used to believe the comment religion , it was beat into us in school , but once I started working with people with similar or greater skill than mine , I noticed that comments became few and far between .
Usually they are only necessary to explain the intersection with something external or poorly designed , such as an API call or hackish work-around .
Comments are no substitute for not knowing the problem domain .
If you need to educate a new hire , you should already have documentation that explains the architecture.If you want to talk unprofessional , the absolute worst are comments that state the obvious .
It 's like watching a movie with an imbecile talking to the screen , telling himself everything that is happening .
It goes without saying that those comments are usually uncapitalized , lacking punctuation , and full of misspellings .</tokentext>
<sentencetext>If you have to "decipher" code, it is wasn't good to begin with.
I used to believe the comment religion, it was beat into us in school, but once I started working with people with similar or greater skill than mine, I noticed that comments became few and far between.
Usually they are only necessary to explain the intersection with something external or poorly designed, such as an API call or hackish work-around.
Comments are no substitute for not knowing the problem domain.
If you need to educate a new hire, you should already have documentation that explains the architecture.If you want to talk unprofessional, the absolute worst are comments that state the obvious.
It's like watching a movie with an imbecile talking to the screen, telling himself everything that is happening.
It goes without saying that those comments are usually uncapitalized, lacking punctuation, and full of misspellings.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618576</id>
	<title>"Thus, I would choose to write the comment..."</title>
	<author>Frankenshteen</author>
	<datestamp>1262358540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>"In most cases"

That's the bottom line - just apply the same rule to comments you do to code; overly verbose is usually more confusing.</htmltext>
<tokenext>" In most cases " That 's the bottom line - just apply the same rule to comments you do to code ; overly verbose is usually more confusing .</tokentext>
<sentencetext>"In most cases"

That's the bottom line - just apply the same rule to comments you do to code; overly verbose is usually more confusing.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617060</id>
	<title>Commenting "why"</title>
	<author>Chris Newton</author>
	<datestamp>1262348580000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>I've heard one person after another argue about how to comment and how much to comment, but what I've never seen is any kind of serious study attempting to measure what actually works best.</p></div><p>FWIW, in studies of the problems developers encounter in practice, one recurring difficulty is working out the motivation behind a given piece of code. This supports advice to comment why the code is written the way it is. See, for example:</p><ul>
<li>LaToza, Thomas D., et al, <i>Maintaining Mental Models: A Study of Developer Work Habits</i>, in ICSE '06: Proceedings of the 28th international conference on Software Engineering</li><li>Ko, Andrew J., et al, <i>Information Needs in Collocated Software Development Teams</i>, in ICSE '07: Proceedings of the 29th international conference on Software Engineering</li></ul><p>Both papers were coauthored by Robert DeLine and Gina Venolia of Microsoft Research.</p><p>In LaToza, 66\% agreed that "understanding the rationale behind a piece of code" was a serious problem for them.</p><p>In Ko, "Why was the code implemented this way?" was the second most frequently unsatisfied information need among the developers observed.</p></div>
	</htmltext>
<tokenext>I 've heard one person after another argue about how to comment and how much to comment , but what I 've never seen is any kind of serious study attempting to measure what actually works best.FWIW , in studies of the problems developers encounter in practice , one recurring difficulty is working out the motivation behind a given piece of code .
This supports advice to comment why the code is written the way it is .
See , for example : LaToza , Thomas D. , et al , Maintaining Mental Models : A Study of Developer Work Habits , in ICSE '06 : Proceedings of the 28th international conference on Software EngineeringKo , Andrew J. , et al , Information Needs in Collocated Software Development Teams , in ICSE '07 : Proceedings of the 29th international conference on Software EngineeringBoth papers were coauthored by Robert DeLine and Gina Venolia of Microsoft Research.In LaToza , 66 \ % agreed that " understanding the rationale behind a piece of code " was a serious problem for them.In Ko , " Why was the code implemented this way ?
" was the second most frequently unsatisfied information need among the developers observed .</tokentext>
<sentencetext>I've heard one person after another argue about how to comment and how much to comment, but what I've never seen is any kind of serious study attempting to measure what actually works best.FWIW, in studies of the problems developers encounter in practice, one recurring difficulty is working out the motivation behind a given piece of code.
This supports advice to comment why the code is written the way it is.
See, for example:
LaToza, Thomas D., et al, Maintaining Mental Models: A Study of Developer Work Habits, in ICSE '06: Proceedings of the 28th international conference on Software EngineeringKo, Andrew J., et al, Information Needs in Collocated Software Development Teams, in ICSE '07: Proceedings of the 29th international conference on Software EngineeringBoth papers were coauthored by Robert DeLine and Gina Venolia of Microsoft Research.In LaToza, 66\% agreed that "understanding the rationale behind a piece of code" was a serious problem for them.In Ko, "Why was the code implemented this way?
" was the second most frequently unsatisfied information need among the developers observed.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616872</id>
	<title>So who is this guy?</title>
	<author>Anonymous</author>
	<datestamp>1262347020000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>No offence intended to him, but he's just re-interating the sort of commentary on commenting that's in Code Complete, The Practice of Programming, Linux kernel CodingStyle etc. He's not offering any original insights, or telling war stories that people can learn from. Any decent programmer would already know these myths, and if they didn't, they really should be reading books such as the ones I've listed, not a blog entry with very little original content.</p><p>IOW, what makes special enough to be Slashdot front page news?</p></htmltext>
<tokenext>No offence intended to him , but he 's just re-interating the sort of commentary on commenting that 's in Code Complete , The Practice of Programming , Linux kernel CodingStyle etc .
He 's not offering any original insights , or telling war stories that people can learn from .
Any decent programmer would already know these myths , and if they did n't , they really should be reading books such as the ones I 've listed , not a blog entry with very little original content.IOW , what makes special enough to be Slashdot front page news ?</tokentext>
<sentencetext>No offence intended to him, but he's just re-interating the sort of commentary on commenting that's in Code Complete, The Practice of Programming, Linux kernel CodingStyle etc.
He's not offering any original insights, or telling war stories that people can learn from.
Any decent programmer would already know these myths, and if they didn't, they really should be reading books such as the ones I've listed, not a blog entry with very little original content.IOW, what makes special enough to be Slashdot front page news?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618300</id>
	<title>Seperate code and comments in one file.</title>
	<author>Anonymous</author>
	<datestamp>1262356500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I have a unique system for code comments that serves my own projects incredibly well.</p><p>I find that comments break the flow and readability of the code, especially when there are huge blocks of comment for a small section of code.</p><p>What I've done is set the tab size to 85 characters in my editors. I do not use tabs (one because I prefer 2-space indenting, two because most editors have Smart Tab features), so to comment a line, I tab at the end of the line and add as long as a comment as I want about the line there.</p><p>On a widescreen monitor, this makes both code and comments visible (up to 90 characters of comment on my 1440-wide screen), without one breaking the readability of the other.</p><p>Some other developers I've worked with have liked the system so much they started using it as well.</p></htmltext>
<tokenext>I have a unique system for code comments that serves my own projects incredibly well.I find that comments break the flow and readability of the code , especially when there are huge blocks of comment for a small section of code.What I 've done is set the tab size to 85 characters in my editors .
I do not use tabs ( one because I prefer 2-space indenting , two because most editors have Smart Tab features ) , so to comment a line , I tab at the end of the line and add as long as a comment as I want about the line there.On a widescreen monitor , this makes both code and comments visible ( up to 90 characters of comment on my 1440-wide screen ) , without one breaking the readability of the other.Some other developers I 've worked with have liked the system so much they started using it as well .</tokentext>
<sentencetext>I have a unique system for code comments that serves my own projects incredibly well.I find that comments break the flow and readability of the code, especially when there are huge blocks of comment for a small section of code.What I've done is set the tab size to 85 characters in my editors.
I do not use tabs (one because I prefer 2-space indenting, two because most editors have Smart Tab features), so to comment a line, I tab at the end of the line and add as long as a comment as I want about the line there.On a widescreen monitor, this makes both code and comments visible (up to 90 characters of comment on my 1440-wide screen), without one breaking the readability of the other.Some other developers I've worked with have liked the system so much they started using it as well.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30623726</id>
	<title>You want comments? Docs? Allow time for it.</title>
	<author>bXTr</author>
	<datestamp>1262456460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It always amazes me that management requires fully commented code and complete documentation, but they don't allow the time necessary to create it. You have to allow at least double the amount of time that you would give for coding because you are effectively writing the program twice. When time gets short, the first thing to go is the documentation. Your users don't give an unwashed rats ass about how well the code is commented. They care about whether or not it does what they want. Therefore, it's entirely up to management to allow for time in the project for documentation and commenting code.</htmltext>
<tokenext>It always amazes me that management requires fully commented code and complete documentation , but they do n't allow the time necessary to create it .
You have to allow at least double the amount of time that you would give for coding because you are effectively writing the program twice .
When time gets short , the first thing to go is the documentation .
Your users do n't give an unwashed rats ass about how well the code is commented .
They care about whether or not it does what they want .
Therefore , it 's entirely up to management to allow for time in the project for documentation and commenting code .</tokentext>
<sentencetext>It always amazes me that management requires fully commented code and complete documentation, but they don't allow the time necessary to create it.
You have to allow at least double the amount of time that you would give for coding because you are effectively writing the program twice.
When time gets short, the first thing to go is the documentation.
Your users don't give an unwashed rats ass about how well the code is commented.
They care about whether or not it does what they want.
Therefore, it's entirely up to management to allow for time in the project for documentation and commenting code.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616748</id>
	<title>Re:One person's myth is another person's fact.</title>
	<author>v1</author>
	<datestamp>1262345940000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>I find the most important comments are those that tell you WHY something was done the way it was.  I do this with my own code when I track down and fix a bug that turns out to be caused by some very subtle effect or easily made mistake.  I put the comment there to stop myself (or someone else) from "fixing" / "cleaning it up" later because they don't realize <i>why</i> it's done the way it is.  Comments like:</p><p># yes, 1, not 0.  If all four of the lists are allowed to go to 0, we will blow up later with DBZ.</p><p>And having a sometimes very poor memory of code written long ago, this saves me from <i>myself</i> more than others.</p></htmltext>
<tokenext>I find the most important comments are those that tell you WHY something was done the way it was .
I do this with my own code when I track down and fix a bug that turns out to be caused by some very subtle effect or easily made mistake .
I put the comment there to stop myself ( or someone else ) from " fixing " / " cleaning it up " later because they do n't realize why it 's done the way it is .
Comments like : # yes , 1 , not 0 .
If all four of the lists are allowed to go to 0 , we will blow up later with DBZ.And having a sometimes very poor memory of code written long ago , this saves me from myself more than others .</tokentext>
<sentencetext>I find the most important comments are those that tell you WHY something was done the way it was.
I do this with my own code when I track down and fix a bug that turns out to be caused by some very subtle effect or easily made mistake.
I put the comment there to stop myself (or someone else) from "fixing" / "cleaning it up" later because they don't realize why it's done the way it is.
Comments like:# yes, 1, not 0.
If all four of the lists are allowed to go to 0, we will blow up later with DBZ.And having a sometimes very poor memory of code written long ago, this saves me from myself more than others.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616696</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618506</id>
	<title>How does this even deserve a /.  ?</title>
	<author>upuv</author>
	<datestamp>1262357880000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Because his opinion is against a fairly standard convention he declares himself right and the opposite opinion to be myth.</p><p>How arrogant can you get. Really.</p><p>"I think MS Windows sucks Donkey Nuggets.  Therefore everyone should switch to Android. The power I wield is frightening."</p><p>I've been writing code for over 20 years.  One thing you learn is that you don't want those "Hey how do you do xyz with method ABC in the code you wrote 10 years ago." calls.  How do you avoid this your code follows you like a bad poo cling on. YOU COMMENT YOUR CODE.  With descriptions, examples, purpose and anything else that is relevant.  You probably should spend as much if not more time on the comments than the code.  Cause it will save you heaps of time in the future.</p><p>As for documentation that is external to the code?  Well it's useless.  Because repositories change move and mutate.  Over the years the design/requirements/arch docs all seem to vanish.  The only thing that seems to live on is the actual code.  Why.  The code is the business not the power point slide show.  The code therefore should also be the documentation.</p><p>So Mr.  I'm 20something and know everything about writing code.  Time to join the real world.  I for one never want to have to fix your code.</p></htmltext>
<tokenext>Because his opinion is against a fairly standard convention he declares himself right and the opposite opinion to be myth.How arrogant can you get .
Really. " I think MS Windows sucks Donkey Nuggets .
Therefore everyone should switch to Android .
The power I wield is frightening .
" I 've been writing code for over 20 years .
One thing you learn is that you do n't want those " Hey how do you do xyz with method ABC in the code you wrote 10 years ago .
" calls .
How do you avoid this your code follows you like a bad poo cling on .
YOU COMMENT YOUR CODE .
With descriptions , examples , purpose and anything else that is relevant .
You probably should spend as much if not more time on the comments than the code .
Cause it will save you heaps of time in the future.As for documentation that is external to the code ?
Well it 's useless .
Because repositories change move and mutate .
Over the years the design/requirements/arch docs all seem to vanish .
The only thing that seems to live on is the actual code .
Why. The code is the business not the power point slide show .
The code therefore should also be the documentation.So Mr. I 'm 20something and know everything about writing code .
Time to join the real world .
I for one never want to have to fix your code .</tokentext>
<sentencetext>Because his opinion is against a fairly standard convention he declares himself right and the opposite opinion to be myth.How arrogant can you get.
Really."I think MS Windows sucks Donkey Nuggets.
Therefore everyone should switch to Android.
The power I wield is frightening.
"I've been writing code for over 20 years.
One thing you learn is that you don't want those "Hey how do you do xyz with method ABC in the code you wrote 10 years ago.
" calls.
How do you avoid this your code follows you like a bad poo cling on.
YOU COMMENT YOUR CODE.
With descriptions, examples, purpose and anything else that is relevant.
You probably should spend as much if not more time on the comments than the code.
Cause it will save you heaps of time in the future.As for documentation that is external to the code?
Well it's useless.
Because repositories change move and mutate.
Over the years the design/requirements/arch docs all seem to vanish.
The only thing that seems to live on is the actual code.
Why.  The code is the business not the power point slide show.
The code therefore should also be the documentation.So Mr.  I'm 20something and know everything about writing code.
Time to join the real world.
I for one never want to have to fix your code.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619872</id>
	<title>Re: OP</title>
	<author>Anonymous</author>
	<datestamp>1262371860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>'would you rather use a one-liner that requires a 3-line comment, or a 10-liner that requires no comments?'</p><p>What defines 'requires no comments'?  To me a comment is useful if it saves someone (me or anyone else) time later.  Even if you have a brilliant and fairly self-documenting 10-liner, what is quicker for a programmer: reading a one line comment or reading 10 lines of code?  What about a poor scripter that is using a c/c++ function from a simpler language that may not be able to decipher the original code at all, no matter how 'self-documenting'.</p></htmltext>
<tokenext>'would you rather use a one-liner that requires a 3-line comment , or a 10-liner that requires no comments ?
'What defines 'requires no comments ' ?
To me a comment is useful if it saves someone ( me or anyone else ) time later .
Even if you have a brilliant and fairly self-documenting 10-liner , what is quicker for a programmer : reading a one line comment or reading 10 lines of code ?
What about a poor scripter that is using a c/c + + function from a simpler language that may not be able to decipher the original code at all , no matter how 'self-documenting' .</tokentext>
<sentencetext>'would you rather use a one-liner that requires a 3-line comment, or a 10-liner that requires no comments?
'What defines 'requires no comments'?
To me a comment is useful if it saves someone (me or anyone else) time later.
Even if you have a brilliant and fairly self-documenting 10-liner, what is quicker for a programmer: reading a one line comment or reading 10 lines of code?
What about a poor scripter that is using a c/c++ function from a simpler language that may not be able to decipher the original code at all, no matter how 'self-documenting'.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617240</id>
	<title>Re:More verbose == less readable?</title>
	<author>Kjella</author>
	<datestamp>1262349840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>And if you're that worried about a verbose section of code, extract a method, give it a good name, and be done. Now you have both a one-liner method call that is easy to read in context and a more verbose implementation that is easier to understand and maintain in the future.</p></div><p>And for the love of $deity, don't create side effects which aren't apparent from the function name. Like doing data hacks in the loadFromDisk() method. What is unfortunately also annoying with "functionifying" a method is that it clogs up the class methods, I wish there was a keyword like "foohelper() helps foo();" which would mean foohelper() is only in scope inside foo(). If something is complex and consists of several long operations, it's usually cleaner to have a supermethod which only calls helpers.</p></div>
	</htmltext>
<tokenext>And if you 're that worried about a verbose section of code , extract a method , give it a good name , and be done .
Now you have both a one-liner method call that is easy to read in context and a more verbose implementation that is easier to understand and maintain in the future.And for the love of $ deity , do n't create side effects which are n't apparent from the function name .
Like doing data hacks in the loadFromDisk ( ) method .
What is unfortunately also annoying with " functionifying " a method is that it clogs up the class methods , I wish there was a keyword like " foohelper ( ) helps foo ( ) ; " which would mean foohelper ( ) is only in scope inside foo ( ) .
If something is complex and consists of several long operations , it 's usually cleaner to have a supermethod which only calls helpers .</tokentext>
<sentencetext>And if you're that worried about a verbose section of code, extract a method, give it a good name, and be done.
Now you have both a one-liner method call that is easy to read in context and a more verbose implementation that is easier to understand and maintain in the future.And for the love of $deity, don't create side effects which aren't apparent from the function name.
Like doing data hacks in the loadFromDisk() method.
What is unfortunately also annoying with "functionifying" a method is that it clogs up the class methods, I wish there was a keyword like "foohelper() helps foo();" which would mean foohelper() is only in scope inside foo().
If something is complex and consists of several long operations, it's usually cleaner to have a supermethod which only calls helpers.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616770</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619610</id>
	<title>Re:every line of code should be commented</title>
	<author>Anonymous</author>
	<datestamp>1262368980000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Every line should be commented, like:<nobr> <wbr></nobr>// Declare function called doit with one int param that returns an int<br>int doit(int i)<nobr> <wbr></nobr>// See above comment<br>{<nobr> <wbr></nobr>// The function's open brace. I like to put braces on their own line. You should too!! BTW, this is C code, so braces are totally the way to go.</p><p>
&nbsp; &nbsp; &nbsp; if(i == 0)<nobr> <wbr></nobr>// Check if i is 0. You know, in C, "==" is the way to compare values, unlike in VB where you use a single "=". Just thought u should know.</p><p>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return 0;<nobr> <wbr></nobr>// Return 0. That is, all the bits of the return value are 0. We could also return i, because i is 0, too. That is, all the bits of i are 0. On a 32 bit system, there would be, like, 32 0's.</p><p>
&nbsp; &nbsp; &nbsp; else</p><p>
&nbsp; &nbsp; &nbsp; {<nobr> <wbr></nobr>// Begin an if block using a brace (this is C syntax!!!)</p><p>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; int j = i - 1;<nobr> <wbr></nobr>// Declare an int variable named j that is one less than i</p><p>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return i + doit(j);<nobr> <wbr></nobr>// Return the sum of i and the value of calling doit with j</p><p>
&nbsp; &nbsp; &nbsp; }<nobr> <wbr></nobr>// Finish the if block with a C close brace. By the way, we could have written the above code as return i + doit(i - 1) without using the braces.<br>}<nobr> <wbr></nobr>// The function's close brace.</p><p>There! Now that is both way readable and informative. Anything less would just not pass my code review.</p></div><p>I would give you a b- for this, comments should be on their own line as it makes it easier to read</p></div>
	</htmltext>
<tokenext>Every line should be commented , like : // Declare function called doit with one int param that returns an intint doit ( int i ) // See above comment { // The function 's open brace .
I like to put braces on their own line .
You should too ! !
BTW , this is C code , so braces are totally the way to go .
      if ( i = = 0 ) // Check if i is 0 .
You know , in C , " = = " is the way to compare values , unlike in VB where you use a single " = " .
Just thought u should know .
            return 0 ; // Return 0 .
That is , all the bits of the return value are 0 .
We could also return i , because i is 0 , too .
That is , all the bits of i are 0 .
On a 32 bit system , there would be , like , 32 0 's .
      else       { // Begin an if block using a brace ( this is C syntax ! ! !
)             int j = i - 1 ; // Declare an int variable named j that is one less than i             return i + doit ( j ) ; // Return the sum of i and the value of calling doit with j       } // Finish the if block with a C close brace .
By the way , we could have written the above code as return i + doit ( i - 1 ) without using the braces .
} // The function 's close brace.There !
Now that is both way readable and informative .
Anything less would just not pass my code review.I would give you a b- for this , comments should be on their own line as it makes it easier to read</tokentext>
<sentencetext>Every line should be commented, like: // Declare function called doit with one int param that returns an intint doit(int i) // See above comment{ // The function's open brace.
I like to put braces on their own line.
You should too!!
BTW, this is C code, so braces are totally the way to go.
      if(i == 0) // Check if i is 0.
You know, in C, "==" is the way to compare values, unlike in VB where you use a single "=".
Just thought u should know.
            return 0; // Return 0.
That is, all the bits of the return value are 0.
We could also return i, because i is 0, too.
That is, all the bits of i are 0.
On a 32 bit system, there would be, like, 32 0's.
      else
      { // Begin an if block using a brace (this is C syntax!!!
)
            int j = i - 1; // Declare an int variable named j that is one less than i
            return i + doit(j); // Return the sum of i and the value of calling doit with j
      } // Finish the if block with a C close brace.
By the way, we could have written the above code as return i + doit(i - 1) without using the braces.
} // The function's close brace.There!
Now that is both way readable and informative.
Anything less would just not pass my code review.I would give you a b- for this, comments should be on their own line as it makes it easier to read
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620052</id>
	<title>Re:More verbose == less readable?</title>
	<author>dcollins</author>
	<datestamp>1262374140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"First, I think any time you consider writing some clever one-liner in real production code you should rethink long and hard. Is the hypothetical 6 fewer lines of code really worth it? Unless you're doing it for absolutely required performance reasons, the 6 lines of code you save won't buy you anything but the wrath of whoever has to come along in 3 years and refactor your code."</p><p>This sounds like ideology taken too far. Why would one well-commented line inspire wrath? That doesn't make any sense.</p></htmltext>
<tokenext>" First , I think any time you consider writing some clever one-liner in real production code you should rethink long and hard .
Is the hypothetical 6 fewer lines of code really worth it ?
Unless you 're doing it for absolutely required performance reasons , the 6 lines of code you save wo n't buy you anything but the wrath of whoever has to come along in 3 years and refactor your code .
" This sounds like ideology taken too far .
Why would one well-commented line inspire wrath ?
That does n't make any sense .</tokentext>
<sentencetext>"First, I think any time you consider writing some clever one-liner in real production code you should rethink long and hard.
Is the hypothetical 6 fewer lines of code really worth it?
Unless you're doing it for absolutely required performance reasons, the 6 lines of code you save won't buy you anything but the wrath of whoever has to come along in 3 years and refactor your code.
"This sounds like ideology taken too far.
Why would one well-commented line inspire wrath?
That doesn't make any sense.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616770</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618664</id>
	<title>Re:So who is this guy?</title>
	<author>Anonymous</author>
	<datestamp>1262359140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>But the Y2K+10 bug <b>is</b> here. If your mail is sorted by SpamAssassin, there's a good chance you have some false positives in the spam folder: SpamAssassin assigns spam points to mails where the year matches<nobr> <wbr></nobr>/20[1-9][0-9]/ because the year is "too far in the future". <a href="https://issues.apache.org/SpamAssassin/show\_bug.cgi?id=6269" title="apache.org" rel="nofollow">Oops.</a> [apache.org]</p></htmltext>
<tokenext>But the Y2K + 10 bug is here .
If your mail is sorted by SpamAssassin , there 's a good chance you have some false positives in the spam folder : SpamAssassin assigns spam points to mails where the year matches /20 [ 1-9 ] [ 0-9 ] / because the year is " too far in the future " .
Oops. [ apache.org ]</tokentext>
<sentencetext>But the Y2K+10 bug is here.
If your mail is sorted by SpamAssassin, there's a good chance you have some false positives in the spam folder: SpamAssassin assigns spam points to mails where the year matches /20[1-9][0-9]/ because the year is "too far in the future".
Oops. [apache.org]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617264</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618414</id>
	<title>Re:Strongly RESTRICT Code Commenting</title>
	<author>Anonymous</author>
	<datestamp>1262357100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Reminds me of a chunk of PHP code that I was asked to "refactor"<nobr> <wbr></nobr>... Every single file (about 70 of them) came with a 30-line copyright notice, followed by intermixed fragments of PHP and HTML. There were no comments in any of the files and each usually came with braces on either side of HTML blocks. Needless to say it ended up rm -rf 'ed<nobr> <wbr></nobr>... Sometimes it is just faster to start over.</p></htmltext>
<tokenext>Reminds me of a chunk of PHP code that I was asked to " refactor " ... Every single file ( about 70 of them ) came with a 30-line copyright notice , followed by intermixed fragments of PHP and HTML .
There were no comments in any of the files and each usually came with braces on either side of HTML blocks .
Needless to say it ended up rm -rf 'ed ... Sometimes it is just faster to start over .</tokentext>
<sentencetext>Reminds me of a chunk of PHP code that I was asked to "refactor" ... Every single file (about 70 of them) came with a 30-line copyright notice, followed by intermixed fragments of PHP and HTML.
There were no comments in any of the files and each usually came with braces on either side of HTML blocks.
Needless to say it ended up rm -rf 'ed ... Sometimes it is just faster to start over.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617052</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617264</id>
	<title>Re:So who is this guy?</title>
	<author>Sapphon</author>
	<datestamp>1262350020000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext>It's New Year's Day. What did you want &ndash; "Y2K bug still not here"?</htmltext>
<tokenext>It 's New Year 's Day .
What did you want    " Y2K bug still not here " ?</tokentext>
<sentencetext>It's New Year's Day.
What did you want – "Y2K bug still not here"?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616872</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616880</id>
	<title>Re:Wrong on all accounts</title>
	<author>SerpentMage</author>
	<datestamp>1262347080000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>And therein lies the problem.</p><p>There are two major problems:</p><p>1) As much as I would like to say that documentation helps, I actually don't think it helps unless you writing an API.  But even then I wonder. The real problem with documentation is that as much as we would like to keep it up to date, it does not happen. I personally would prefer modular code that works without tricks than code with comments and tricks.</p><p>2) The problem with comments is that it fails the psychological test. When I write something down it does not necessarily mean that another programmer is going to understand what I mean. The reason has to do with the words I choose and how I phrase things. Even with good wording I can't explain a complex system. For example, let's say that I had to explain some complex multi-threading code. Unless the third party had a level of knowledge as good as mine it will not matter what I write as a comment since they lack the basic threading knowledge. And this lack knowledge is a key problem in any complex system.</p><p>Thus if I had to choose between comments and simplicity I choose simplicity since one can understand simplicity.</p></htmltext>
<tokenext>And therein lies the problem.There are two major problems : 1 ) As much as I would like to say that documentation helps , I actually do n't think it helps unless you writing an API .
But even then I wonder .
The real problem with documentation is that as much as we would like to keep it up to date , it does not happen .
I personally would prefer modular code that works without tricks than code with comments and tricks.2 ) The problem with comments is that it fails the psychological test .
When I write something down it does not necessarily mean that another programmer is going to understand what I mean .
The reason has to do with the words I choose and how I phrase things .
Even with good wording I ca n't explain a complex system .
For example , let 's say that I had to explain some complex multi-threading code .
Unless the third party had a level of knowledge as good as mine it will not matter what I write as a comment since they lack the basic threading knowledge .
And this lack knowledge is a key problem in any complex system.Thus if I had to choose between comments and simplicity I choose simplicity since one can understand simplicity .</tokentext>
<sentencetext>And therein lies the problem.There are two major problems:1) As much as I would like to say that documentation helps, I actually don't think it helps unless you writing an API.
But even then I wonder.
The real problem with documentation is that as much as we would like to keep it up to date, it does not happen.
I personally would prefer modular code that works without tricks than code with comments and tricks.2) The problem with comments is that it fails the psychological test.
When I write something down it does not necessarily mean that another programmer is going to understand what I mean.
The reason has to do with the words I choose and how I phrase things.
Even with good wording I can't explain a complex system.
For example, let's say that I had to explain some complex multi-threading code.
Unless the third party had a level of knowledge as good as mine it will not matter what I write as a comment since they lack the basic threading knowledge.
And this lack knowledge is a key problem in any complex system.Thus if I had to choose between comments and simplicity I choose simplicity since one can understand simplicity.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30652114</id>
	<title>Good commenting... another art form</title>
	<author>hazydave</author>
	<datestamp>1262722620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Just like programming, the proper use of comments is an art form. Yes, there are plenty of really stupid comments in code... you don't need line-by-line comments describing the obvious behavior of the code. Well, unless you're writing in APL or some other "write-only" language.. no no-trivial line of APL code is obvious. But proper comments should describe functions, large blocks, and classes... not just what they do or how they work, but what you're thinking and why you did things that might be non-obvious, even when the code looks clear and well written.</p><p>There can also be commenting formalisms. I have worked at several companies that used some form of "auto-docs"... basically, when you commented a function, you wrote the documentation for folks calling that function from other modules. I put this feature into the interface description language I wrote as part of an object model for an object-based OS. There were both "formal" and "informal" comments. Informal would be used for very specific little details, formal became part of the hypertext (OS/2 or HTML) generated during every build.</p><p>And yeah, in any autodoc-type situation, comment maintenance is part of the job, no less important in the long run than the code itself. In fact, potentially much more important... a bug in your code breaks the system at one point. A bug in your autodoc comments can break the code at any number of points.</p><p>This same project also had a mess of pretty cool things. Some weren't useful outside of our object model... the compiler generated a database of pre-compiled object tokens. The release system formally enforced the use of the official release version of the compiler from the server, for a formal release (you could use any compiler you wanted to for testing). This release system also sent release packages out to various other sites in our company, automatically installed, compiled, and merged databases during the "catch" process, etc. You could always build identical code on any PC (OS/2 or Windows NT), with no worries about missing libraries, etc. Not much of it was applicable to code development outside of our specific custom OS, but in the end, it was a very cool system.</p></htmltext>
<tokenext>Just like programming , the proper use of comments is an art form .
Yes , there are plenty of really stupid comments in code... you do n't need line-by-line comments describing the obvious behavior of the code .
Well , unless you 're writing in APL or some other " write-only " language.. no no-trivial line of APL code is obvious .
But proper comments should describe functions , large blocks , and classes... not just what they do or how they work , but what you 're thinking and why you did things that might be non-obvious , even when the code looks clear and well written.There can also be commenting formalisms .
I have worked at several companies that used some form of " auto-docs " ... basically , when you commented a function , you wrote the documentation for folks calling that function from other modules .
I put this feature into the interface description language I wrote as part of an object model for an object-based OS .
There were both " formal " and " informal " comments .
Informal would be used for very specific little details , formal became part of the hypertext ( OS/2 or HTML ) generated during every build.And yeah , in any autodoc-type situation , comment maintenance is part of the job , no less important in the long run than the code itself .
In fact , potentially much more important... a bug in your code breaks the system at one point .
A bug in your autodoc comments can break the code at any number of points.This same project also had a mess of pretty cool things .
Some were n't useful outside of our object model... the compiler generated a database of pre-compiled object tokens .
The release system formally enforced the use of the official release version of the compiler from the server , for a formal release ( you could use any compiler you wanted to for testing ) .
This release system also sent release packages out to various other sites in our company , automatically installed , compiled , and merged databases during the " catch " process , etc .
You could always build identical code on any PC ( OS/2 or Windows NT ) , with no worries about missing libraries , etc .
Not much of it was applicable to code development outside of our specific custom OS , but in the end , it was a very cool system .</tokentext>
<sentencetext>Just like programming, the proper use of comments is an art form.
Yes, there are plenty of really stupid comments in code... you don't need line-by-line comments describing the obvious behavior of the code.
Well, unless you're writing in APL or some other "write-only" language.. no no-trivial line of APL code is obvious.
But proper comments should describe functions, large blocks, and classes... not just what they do or how they work, but what you're thinking and why you did things that might be non-obvious, even when the code looks clear and well written.There can also be commenting formalisms.
I have worked at several companies that used some form of "auto-docs"... basically, when you commented a function, you wrote the documentation for folks calling that function from other modules.
I put this feature into the interface description language I wrote as part of an object model for an object-based OS.
There were both "formal" and "informal" comments.
Informal would be used for very specific little details, formal became part of the hypertext (OS/2 or HTML) generated during every build.And yeah, in any autodoc-type situation, comment maintenance is part of the job, no less important in the long run than the code itself.
In fact, potentially much more important... a bug in your code breaks the system at one point.
A bug in your autodoc comments can break the code at any number of points.This same project also had a mess of pretty cool things.
Some weren't useful outside of our object model... the compiler generated a database of pre-compiled object tokens.
The release system formally enforced the use of the official release version of the compiler from the server, for a formal release (you could use any compiler you wanted to for testing).
This release system also sent release packages out to various other sites in our company, automatically installed, compiled, and merged databases during the "catch" process, etc.
You could always build identical code on any PC (OS/2 or Windows NT), with no worries about missing libraries, etc.
Not much of it was applicable to code development outside of our specific custom OS, but in the end, it was a very cool system.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618778</id>
	<title>Re:Has No One Actually Studied This?</title>
	<author>Anonymous</author>
	<datestamp>1262359800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I know better than most of the complaints I read on here, and yet, I can't get a programming job. Eh, go figure.</p></htmltext>
<tokenext>I know better than most of the complaints I read on here , and yet , I ca n't get a programming job .
Eh , go figure .</tokentext>
<sentencetext>I know better than most of the complaints I read on here, and yet, I can't get a programming job.
Eh, go figure.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622364</id>
	<title>Re:Warning - war story ahead</title>
	<author>StormReaver</author>
	<datestamp>1262448660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>- 6000 lines of Pascal</p><p>Oh, and one bug.</p></div><p>[Adam Sandler drawl]Well, there's your problem.[/Adam Sandler drawl]</p></div>
	</htmltext>
<tokenext>- 6000 lines of PascalOh , and one bug .
[ Adam Sandler drawl ] Well , there 's your problem .
[ /Adam Sandler drawl ]</tokentext>
<sentencetext>- 6000 lines of PascalOh, and one bug.
[Adam Sandler drawl]Well, there's your problem.
[/Adam Sandler drawl]
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617380</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617308</id>
	<title>Re:More verbose == less readable?</title>
	<author>Anonymous</author>
	<datestamp>1262350440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>efficient code should be to goal.</p><p>I see a lot of sh script written with people using 'for' + 'ls' + 'grep' to find files, filter the output, and perform some action in a loop.  This creates extra lines of code when some 'clever' one liner could do this better.</p><p>in bash for example , declare everything you can so that your program doesnt have to wait on a $PATH return and search for your program.  Learn each functions options so you dont stack things together for no good reason.</p><p>this:<br>FINDPATH=/here;<br>PROGRAM=/usr/bin/touch;<br>FINDFLAGS="-this -than -theother";<br>find $FINDPATH $FINDFLAGS -name regex -exec $PROGRAM {} \;</p><p>is about 1000 times faster than this:<br>for x in `find / | grep -e regex`ldo program $x;done</p></htmltext>
<tokenext>efficient code should be to goal.I see a lot of sh script written with people using 'for ' + 'ls ' + 'grep ' to find files , filter the output , and perform some action in a loop .
This creates extra lines of code when some 'clever ' one liner could do this better.in bash for example , declare everything you can so that your program doesnt have to wait on a $ PATH return and search for your program .
Learn each functions options so you dont stack things together for no good reason.this : FINDPATH = /here ; PROGRAM = /usr/bin/touch ; FINDFLAGS = " -this -than -theother " ; find $ FINDPATH $ FINDFLAGS -name regex -exec $ PROGRAM { } \ ; is about 1000 times faster than this : for x in ` find / | grep -e regex ` ldo program $ x ; done</tokentext>
<sentencetext>efficient code should be to goal.I see a lot of sh script written with people using 'for' + 'ls' + 'grep' to find files, filter the output, and perform some action in a loop.
This creates extra lines of code when some 'clever' one liner could do this better.in bash for example , declare everything you can so that your program doesnt have to wait on a $PATH return and search for your program.
Learn each functions options so you dont stack things together for no good reason.this:FINDPATH=/here;PROGRAM=/usr/bin/touch;FINDFLAGS="-this -than -theother";find $FINDPATH $FINDFLAGS -name regex -exec $PROGRAM {} \;is about 1000 times faster than this:for x in `find / | grep -e regex`ldo program $x;done</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616770</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616820</id>
	<title>Comments are not design</title>
	<author>Anonymous</author>
	<datestamp>1262346660000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>Code that has concise, sensible comments is indicative of a good design.  However, I don't care how 1337 you are, no professional developer worth a damn programs anything bigger than a 3-line batch without at least some sort of design document.  Comments that relate back to the design document are one thing, but it is really hard to use comments to point out the design of a program which had no design other than "I am ok to just wing this because i am 1337."</p></htmltext>
<tokenext>Code that has concise , sensible comments is indicative of a good design .
However , I do n't care how 1337 you are , no professional developer worth a damn programs anything bigger than a 3-line batch without at least some sort of design document .
Comments that relate back to the design document are one thing , but it is really hard to use comments to point out the design of a program which had no design other than " I am ok to just wing this because i am 1337 .
"</tokentext>
<sentencetext>Code that has concise, sensible comments is indicative of a good design.
However, I don't care how 1337 you are, no professional developer worth a damn programs anything bigger than a 3-line batch without at least some sort of design document.
Comments that relate back to the design document are one thing, but it is really hard to use comments to point out the design of a program which had no design other than "I am ok to just wing this because i am 1337.
"</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620278</id>
	<title>Re:Has No One Actually Studied This?</title>
	<author>Anonymous</author>
	<datestamp>1262463720000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>I think you may have the cart before the horse.<br>Code which is doing a hard job, often needs more comments because there are more things to keep in mind when working on it. it is also more likely to have problems.</p><p>I have been programming for more years than the age of a large portion of the readership of slashdot (34 years), and I can tell you that when you come across your own code twenty years later, you have NO IDEA about what you were thinking when you wrote it.  After years of experience I have decided that code should be rejected if you can not tell what it should be doing AND WHY without actually looking at the code itself. The comments should form an independent summary of what the program should be doing, a bit like the "director's commentary" track on some DVDs.<br>Think of them as an error recovery track.</p><p>I recently started work at a new company and to my dismay found that much of the code was uncommented.  I estimate it slowed down my understanding of how the  product worked by several hundred percent. And yes, somewhere, you have used my code, whether you knew it or not.</p></htmltext>
<tokenext>I think you may have the cart before the horse.Code which is doing a hard job , often needs more comments because there are more things to keep in mind when working on it .
it is also more likely to have problems.I have been programming for more years than the age of a large portion of the readership of slashdot ( 34 years ) , and I can tell you that when you come across your own code twenty years later , you have NO IDEA about what you were thinking when you wrote it .
After years of experience I have decided that code should be rejected if you can not tell what it should be doing AND WHY without actually looking at the code itself .
The comments should form an independent summary of what the program should be doing , a bit like the " director 's commentary " track on some DVDs.Think of them as an error recovery track.I recently started work at a new company and to my dismay found that much of the code was uncommented .
I estimate it slowed down my understanding of how the product worked by several hundred percent .
And yes , somewhere , you have used my code , whether you knew it or not .</tokentext>
<sentencetext>I think you may have the cart before the horse.Code which is doing a hard job, often needs more comments because there are more things to keep in mind when working on it.
it is also more likely to have problems.I have been programming for more years than the age of a large portion of the readership of slashdot (34 years), and I can tell you that when you come across your own code twenty years later, you have NO IDEA about what you were thinking when you wrote it.
After years of experience I have decided that code should be rejected if you can not tell what it should be doing AND WHY without actually looking at the code itself.
The comments should form an independent summary of what the program should be doing, a bit like the "director's commentary" track on some DVDs.Think of them as an error recovery track.I recently started work at a new company and to my dismay found that much of the code was uncommented.
I estimate it slowed down my understanding of how the  product worked by several hundred percent.
And yes, somewhere, you have used my code, whether you knew it or not.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619562</id>
	<title>Re:Has No One Actually Studied This?</title>
	<author>Anonymous</author>
	<datestamp>1262368320000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>This is amusing: "when it finally becomes a real engineering discipline". Certainly there are plenty of people who think software engineering is a real engineering discipline, after all you can get a degree in software engineering. But then, there are just as many people (most of whom are in those other real engineering disciplines) who believe that SE is not real engineering.</p><p>My point is: In those other real engineering disciplines engineers are expected to keep notebooks, write white papers, journal articles, or whatever is most convenient to document their work so other people can understand their design decisions. The luxury of having your notes stay with your design does exist as it does with a code file. You cannot write your design decisions in the silkscreen on a PCB, or the top metal layer of a chip, etc...</p><p>In my undergrad engineering days keeping a lab notebook was a significant portion of the grade for that lab. And I know that in CompSci, SE, other programming classes, comments and good coding style are preached. Unfortunately those lessons are lost on most people in the classroom. It seems that keeping a lab notebook/commenting code are lessons that are best learned by the experience of not having done it and then realizing you should have.</p><p>So comment your code, document your designs, and stop having asinine arguments like this, and then maybe the other real engineers will stop laughing at you.</p></htmltext>
<tokenext>This is amusing : " when it finally becomes a real engineering discipline " .
Certainly there are plenty of people who think software engineering is a real engineering discipline , after all you can get a degree in software engineering .
But then , there are just as many people ( most of whom are in those other real engineering disciplines ) who believe that SE is not real engineering.My point is : In those other real engineering disciplines engineers are expected to keep notebooks , write white papers , journal articles , or whatever is most convenient to document their work so other people can understand their design decisions .
The luxury of having your notes stay with your design does exist as it does with a code file .
You can not write your design decisions in the silkscreen on a PCB , or the top metal layer of a chip , etc...In my undergrad engineering days keeping a lab notebook was a significant portion of the grade for that lab .
And I know that in CompSci , SE , other programming classes , comments and good coding style are preached .
Unfortunately those lessons are lost on most people in the classroom .
It seems that keeping a lab notebook/commenting code are lessons that are best learned by the experience of not having done it and then realizing you should have.So comment your code , document your designs , and stop having asinine arguments like this , and then maybe the other real engineers will stop laughing at you .</tokentext>
<sentencetext>This is amusing: "when it finally becomes a real engineering discipline".
Certainly there are plenty of people who think software engineering is a real engineering discipline, after all you can get a degree in software engineering.
But then, there are just as many people (most of whom are in those other real engineering disciplines) who believe that SE is not real engineering.My point is: In those other real engineering disciplines engineers are expected to keep notebooks, write white papers, journal articles, or whatever is most convenient to document their work so other people can understand their design decisions.
The luxury of having your notes stay with your design does exist as it does with a code file.
You cannot write your design decisions in the silkscreen on a PCB, or the top metal layer of a chip, etc...In my undergrad engineering days keeping a lab notebook was a significant portion of the grade for that lab.
And I know that in CompSci, SE, other programming classes, comments and good coding style are preached.
Unfortunately those lessons are lost on most people in the classroom.
It seems that keeping a lab notebook/commenting code are lessons that are best learned by the experience of not having done it and then realizing you should have.So comment your code, document your designs, and stop having asinine arguments like this, and then maybe the other real engineers will stop laughing at you.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30665132</id>
	<title>Re:every line of code should be commented</title>
	<author>Anonymous</author>
	<datestamp>1262709180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You forgot to document the 'else'.</p></htmltext>
<tokenext>You forgot to document the 'else' .</tokentext>
<sentencetext>You forgot to document the 'else'.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616936</id>
	<title>Not commenting is a sign of not thinking or caring</title>
	<author>presidenteloco</author>
	<datestamp>1262347500000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>If you don't header-comment your class or public method,<br>I have to conclude that you cannot articulate what it is or what it<br>means or is for. So probably the code is incoherent/inconsistent too.</p><p>So that's going to make me write my own instead of using your code.</p><p>Or maybe you can articulate what it is about but are borderline<br>autistic and don't see the need to communicate meaning to others.<br>To me this just means you are so inexperienced in programming that<br>you a) don't understand the costs of maintenance, and<br>b) don't even realize that you yourself aren't going to be able to figure<br>out your code in six months.<br>Either way, I'm not using that code if I can help it.</p></htmltext>
<tokenext>If you do n't header-comment your class or public method,I have to conclude that you can not articulate what it is or what itmeans or is for .
So probably the code is incoherent/inconsistent too.So that 's going to make me write my own instead of using your code.Or maybe you can articulate what it is about but are borderlineautistic and do n't see the need to communicate meaning to others.To me this just means you are so inexperienced in programming thatyou a ) do n't understand the costs of maintenance , andb ) do n't even realize that you yourself are n't going to be able to figureout your code in six months.Either way , I 'm not using that code if I can help it .</tokentext>
<sentencetext>If you don't header-comment your class or public method,I have to conclude that you cannot articulate what it is or what itmeans or is for.
So probably the code is incoherent/inconsistent too.So that's going to make me write my own instead of using your code.Or maybe you can articulate what it is about but are borderlineautistic and don't see the need to communicate meaning to others.To me this just means you are so inexperienced in programming thatyou a) don't understand the costs of maintenance, andb) don't even realize that you yourself aren't going to be able to figureout your code in six months.Either way, I'm not using that code if I can help it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617120</id>
	<title>Re:So who is this guy?</title>
	<author>Anonymous</author>
	<datestamp>1262349060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>IOW, what makes special enough to be Slashdot front page news?</p></div><p>IT'S BOOKS 2.0</p></div>
	</htmltext>
<tokenext>IOW , what makes special enough to be Slashdot front page news ? IT 'S BOOKS 2.0</tokentext>
<sentencetext>IOW, what makes special enough to be Slashdot front page news?IT'S BOOKS 2.0
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616872</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622474</id>
	<title>Obligatory...</title>
	<author>SharpFang</author>
	<datestamp>1262449680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>code:</p><p>for(unsigned char x=limit; x&gt;=limit; x--)<br>{<br>do\_something\_with(x);<nobr> <wbr></nobr>// no comments whatsoever<br>}</p><p>Direct result: my fingers tightly locked around throat of programmer who wrote that.<br>Indirect result:from then on, whenever he purposely uses variable overflow/underflow, he always comments that he does.</p></htmltext>
<tokenext>code : for ( unsigned char x = limit ; x &gt; = limit ; x-- ) { do \ _something \ _with ( x ) ; // no comments whatsoever } Direct result : my fingers tightly locked around throat of programmer who wrote that.Indirect result : from then on , whenever he purposely uses variable overflow/underflow , he always comments that he does .</tokentext>
<sentencetext>code:for(unsigned char x=limit; x&gt;=limit; x--){do\_something\_with(x); // no comments whatsoever}Direct result: my fingers tightly locked around throat of programmer who wrote that.Indirect result:from then on, whenever he purposely uses variable overflow/underflow, he always comments that he does.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616868</id>
	<title>Does he think comments are pseudocode?</title>
	<author>EsJay</author>
	<datestamp>1262346960000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><blockquote><div><p>When you update the code that the comment references, you usually have to update the comment as well.</p></div></blockquote><p>If your comments are that detailed, you're doing it wrong.</p></div>
	</htmltext>
<tokenext>When you update the code that the comment references , you usually have to update the comment as well.If your comments are that detailed , you 're doing it wrong .</tokentext>
<sentencetext>When you update the code that the comment references, you usually have to update the comment as well.If your comments are that detailed, you're doing it wrong.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616854</id>
	<title>Re:Has No One Actually Studied This?</title>
	<author>Anonymous</author>
	<datestamp>1262346840000</datestamp>
	<modclass>Funny</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>In thirty years of programming, I've heard one person after another argue about how to comment and how much to comment, but what I've never seen is any kind of serious study attempting to measure what actually works best.</p></div><p>// TODO: Implement mathematically optimal commenting</p></div>
	</htmltext>
<tokenext>In thirty years of programming , I 've heard one person after another argue about how to comment and how much to comment , but what I 've never seen is any kind of serious study attempting to measure what actually works best.// TODO : Implement mathematically optimal commenting</tokentext>
<sentencetext>In thirty years of programming, I've heard one person after another argue about how to comment and how much to comment, but what I've never seen is any kind of serious study attempting to measure what actually works best.// TODO: Implement mathematically optimal commenting
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617190</id>
	<title>The flipside</title>
	<author>Anonymous</author>
	<datestamp>1262349480000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>I used to work for a <a href="http://www.paullee.com/computers/autonomy.php" title="paullee.com">company</a> [paullee.com] that didn't believe in commenting code...took ages to reverse engineer the code...</htmltext>
<tokenext>I used to work for a company [ paullee.com ] that did n't believe in commenting code...took ages to reverse engineer the code.. .</tokentext>
<sentencetext>I used to work for a company [paullee.com] that didn't believe in commenting code...took ages to reverse engineer the code...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618080</id>
	<title>Re:Has No One Actually Studied This?</title>
	<author>gadzook33</author>
	<datestamp>1262355360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It's funny, a lot of the examples you see on MSDN and similar are often not very commented.  I'm not saying this always produces readable code, but as the examples are "at the correct level", it tends to be quite readable.  If you abstract things well, it does seem to make for very readable code.  Maybe I'm guilty of too much hubris regarding my own programming, but when I go back years later and read old code I usually find one of two things to be true: either I have trouble reading it and almost immediately see a better way of organizing it that would help.  Or, I can read it just fine.  But rarely do I find that comments make the difference.  In my mind the argument is analogous to procedural documentation.  In one system where I work there are hundreds of pages on deployment procedures.  In ours we managed to automate 99\% of the process.  Which would you rather have?  Don't explain what can simply be encoded and factored away.  People who argue against tools like intellisense might as well be arguing against higher-level languages.  Of course there has to be a balance, but these tools exist for a reason.  We can't write in machine code from now until the end of time - we have to be more efficient and more productive than we were before.</htmltext>
<tokenext>It 's funny , a lot of the examples you see on MSDN and similar are often not very commented .
I 'm not saying this always produces readable code , but as the examples are " at the correct level " , it tends to be quite readable .
If you abstract things well , it does seem to make for very readable code .
Maybe I 'm guilty of too much hubris regarding my own programming , but when I go back years later and read old code I usually find one of two things to be true : either I have trouble reading it and almost immediately see a better way of organizing it that would help .
Or , I can read it just fine .
But rarely do I find that comments make the difference .
In my mind the argument is analogous to procedural documentation .
In one system where I work there are hundreds of pages on deployment procedures .
In ours we managed to automate 99 \ % of the process .
Which would you rather have ?
Do n't explain what can simply be encoded and factored away .
People who argue against tools like intellisense might as well be arguing against higher-level languages .
Of course there has to be a balance , but these tools exist for a reason .
We ca n't write in machine code from now until the end of time - we have to be more efficient and more productive than we were before .</tokentext>
<sentencetext>It's funny, a lot of the examples you see on MSDN and similar are often not very commented.
I'm not saying this always produces readable code, but as the examples are "at the correct level", it tends to be quite readable.
If you abstract things well, it does seem to make for very readable code.
Maybe I'm guilty of too much hubris regarding my own programming, but when I go back years later and read old code I usually find one of two things to be true: either I have trouble reading it and almost immediately see a better way of organizing it that would help.
Or, I can read it just fine.
But rarely do I find that comments make the difference.
In my mind the argument is analogous to procedural documentation.
In one system where I work there are hundreds of pages on deployment procedures.
In ours we managed to automate 99\% of the process.
Which would you rather have?
Don't explain what can simply be encoded and factored away.
People who argue against tools like intellisense might as well be arguing against higher-level languages.
Of course there has to be a balance, but these tools exist for a reason.
We can't write in machine code from now until the end of time - we have to be more efficient and more productive than we were before.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620020</id>
	<title>Re:every line of code should be commented</title>
	<author>Anonymous</author>
	<datestamp>1262373840000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>What does "else" do? It's not commented...</p></htmltext>
<tokenext>What does " else " do ?
It 's not commented.. .</tokentext>
<sentencetext>What does "else" do?
It's not commented...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619090</id>
	<title>Comment on no comments...</title>
	<author>CFBMoo1</author>
	<datestamp>1262362860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I hate uncommented code, I hate it with a passion. I hate having to track down how this or that works with no comments or documentation to figure something out. I hate hearing people say, "The code is the documentation!" because I just want to slap them silly.<br><br>I comment my code, whenever I make changes I damn well do my best to document those in the code and developer guides I usually write for projects. I figure if nobody is going to be kind enough to me and leave good documentation and code comments then I should set an example. Thankfully at my current job, the last developer to retire left such good documentation I'm in heaven and even tried to clean up my documenting methods more based on his work.</htmltext>
<tokenext>I hate uncommented code , I hate it with a passion .
I hate having to track down how this or that works with no comments or documentation to figure something out .
I hate hearing people say , " The code is the documentation !
" because I just want to slap them silly.I comment my code , whenever I make changes I damn well do my best to document those in the code and developer guides I usually write for projects .
I figure if nobody is going to be kind enough to me and leave good documentation and code comments then I should set an example .
Thankfully at my current job , the last developer to retire left such good documentation I 'm in heaven and even tried to clean up my documenting methods more based on his work .</tokentext>
<sentencetext>I hate uncommented code, I hate it with a passion.
I hate having to track down how this or that works with no comments or documentation to figure something out.
I hate hearing people say, "The code is the documentation!
" because I just want to slap them silly.I comment my code, whenever I make changes I damn well do my best to document those in the code and developer guides I usually write for projects.
I figure if nobody is going to be kind enough to me and leave good documentation and code comments then I should set an example.
Thankfully at my current job, the last developer to retire left such good documentation I'm in heaven and even tried to clean up my documenting methods more based on his work.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618350</id>
	<title>StyleCop</title>
	<author>Saint Stephen</author>
	<datestamp>1262356740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I do mostly C# + SQL, and have gotten into using StyleCop since it came out.  It forces you to use xml comments on every method, field, property, public or private.  For properties you have to use "Gets or sets the value of Foo" or "Gets or sets a value indicating Foo" (for bool).  Since the only duplicate comment allowed is "The parameter is not allowed," what I do is fill in by default ALL the comment parts (summary, param, returns) with "The parameter is not used."</p><p>Then I get my code to be StyleCop clean, and go back and search for "The parameter is not used."  I update the comments appropriately.</p><p>For comments in the body I use "// TODO refactor" or something terse.  I find putting SOME comment block on everything makes it nice and readable, and if I see a huge block of stuff with "The parameter is not used." I know it's something that's not important to comment (like a million TextBox field declarations), or else it's somethign important I haven't gotten around to commenting yet.</p><p>So this is working all well for me<nobr> <wbr></nobr>:-)  The gist is I use the StyleCop guidelines, a boilerplate for "no comment comments", and terse inline things usually indicating work items in the body.</p><p>Works for me and I explain it to the next guy and he can figure out my intentions.  Right balance of anal retentiveness and terseness for me.</p></htmltext>
<tokenext>I do mostly C # + SQL , and have gotten into using StyleCop since it came out .
It forces you to use xml comments on every method , field , property , public or private .
For properties you have to use " Gets or sets the value of Foo " or " Gets or sets a value indicating Foo " ( for bool ) .
Since the only duplicate comment allowed is " The parameter is not allowed , " what I do is fill in by default ALL the comment parts ( summary , param , returns ) with " The parameter is not used .
" Then I get my code to be StyleCop clean , and go back and search for " The parameter is not used .
" I update the comments appropriately.For comments in the body I use " // TODO refactor " or something terse .
I find putting SOME comment block on everything makes it nice and readable , and if I see a huge block of stuff with " The parameter is not used .
" I know it 's something that 's not important to comment ( like a million TextBox field declarations ) , or else it 's somethign important I have n't gotten around to commenting yet.So this is working all well for me : - ) The gist is I use the StyleCop guidelines , a boilerplate for " no comment comments " , and terse inline things usually indicating work items in the body.Works for me and I explain it to the next guy and he can figure out my intentions .
Right balance of anal retentiveness and terseness for me .</tokentext>
<sentencetext>I do mostly C# + SQL, and have gotten into using StyleCop since it came out.
It forces you to use xml comments on every method, field, property, public or private.
For properties you have to use "Gets or sets the value of Foo" or "Gets or sets a value indicating Foo" (for bool).
Since the only duplicate comment allowed is "The parameter is not allowed," what I do is fill in by default ALL the comment parts (summary, param, returns) with "The parameter is not used.
"Then I get my code to be StyleCop clean, and go back and search for "The parameter is not used.
"  I update the comments appropriately.For comments in the body I use "// TODO refactor" or something terse.
I find putting SOME comment block on everything makes it nice and readable, and if I see a huge block of stuff with "The parameter is not used.
" I know it's something that's not important to comment (like a million TextBox field declarations), or else it's somethign important I haven't gotten around to commenting yet.So this is working all well for me :-)  The gist is I use the StyleCop guidelines, a boilerplate for "no comment comments", and terse inline things usually indicating work items in the body.Works for me and I explain it to the next guy and he can figure out my intentions.
Right balance of anal retentiveness and terseness for me.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617336</id>
	<title>Re:So who is this guy?</title>
	<author>dkleinsc</author>
	<datestamp>1262350620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I think we can answer the question pretty easily: Some guy who wanted to increase the Google rank of his blog and somehow made it through the firehose.</p></htmltext>
<tokenext>I think we can answer the question pretty easily : Some guy who wanted to increase the Google rank of his blog and somehow made it through the firehose .</tokentext>
<sentencetext>I think we can answer the question pretty easily: Some guy who wanted to increase the Google rank of his blog and somehow made it through the firehose.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616872</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619218</id>
	<title>Re:Less verbose is more writeable</title>
	<author>zippthorne</author>
	<datestamp>1262364120000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Either way you need commments.  Your example code only finds one root, and doesn't handle the case of positive b and abs(ac/b^2)  1 very well.  Your comments could explain why you don't expect that case to arise, and why you only need one root.</p></htmltext>
<tokenext>Either way you need commments .
Your example code only finds one root , and does n't handle the case of positive b and abs ( ac/b ^ 2 ) 1 very well .
Your comments could explain why you do n't expect that case to arise , and why you only need one root .</tokentext>
<sentencetext>Either way you need commments.
Your example code only finds one root, and doesn't handle the case of positive b and abs(ac/b^2)  1 very well.
Your comments could explain why you don't expect that case to arise, and why you only need one root.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617056</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616770</id>
	<title>More verbose == less readable?</title>
	<author>Anonymous</author>
	<datestamp>1262346120000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>I disagree with this general statement:</p><blockquote><div><p>For instance, would you rather use a one-liner that requires a 3-line comment, or a 10-liner that requires no comments? In most cases, code's readability suffers more when it's overly verbose than when it has a high comment to code ratio. Thus, I would choose to write the comment in most cases.</p></div></blockquote><p>First, I think any time you consider writing some clever one-liner in real production code you should rethink long and hard.  Is the hypothetical 6 fewer lines of code really worth it?  Unless you're doing it for absolutely required performance reasons, the 6 lines of code you save won't buy you anything but the wrath of whoever has to come along in 3 years and refactor your code.</p><p>Of course you can be too verbose, but it's a much rarer problem than the alternative.  Even overly verbose code is usually easier to understand, easier to maintain, and easier to refactor than that clever little one-liner.  And if you're that worried about a verbose section of code, extract a method, give it a good name, and be done. Now you have both a one-liner method call that is easy to read in context and a more verbose implementation that is easier to understand and maintain in the future.</p></div>
	</htmltext>
<tokenext>I disagree with this general statement : For instance , would you rather use a one-liner that requires a 3-line comment , or a 10-liner that requires no comments ?
In most cases , code 's readability suffers more when it 's overly verbose than when it has a high comment to code ratio .
Thus , I would choose to write the comment in most cases.First , I think any time you consider writing some clever one-liner in real production code you should rethink long and hard .
Is the hypothetical 6 fewer lines of code really worth it ?
Unless you 're doing it for absolutely required performance reasons , the 6 lines of code you save wo n't buy you anything but the wrath of whoever has to come along in 3 years and refactor your code.Of course you can be too verbose , but it 's a much rarer problem than the alternative .
Even overly verbose code is usually easier to understand , easier to maintain , and easier to refactor than that clever little one-liner .
And if you 're that worried about a verbose section of code , extract a method , give it a good name , and be done .
Now you have both a one-liner method call that is easy to read in context and a more verbose implementation that is easier to understand and maintain in the future .</tokentext>
<sentencetext>I disagree with this general statement:For instance, would you rather use a one-liner that requires a 3-line comment, or a 10-liner that requires no comments?
In most cases, code's readability suffers more when it's overly verbose than when it has a high comment to code ratio.
Thus, I would choose to write the comment in most cases.First, I think any time you consider writing some clever one-liner in real production code you should rethink long and hard.
Is the hypothetical 6 fewer lines of code really worth it?
Unless you're doing it for absolutely required performance reasons, the 6 lines of code you save won't buy you anything but the wrath of whoever has to come along in 3 years and refactor your code.Of course you can be too verbose, but it's a much rarer problem than the alternative.
Even overly verbose code is usually easier to understand, easier to maintain, and easier to refactor than that clever little one-liner.
And if you're that worried about a verbose section of code, extract a method, give it a good name, and be done.
Now you have both a one-liner method call that is easy to read in context and a more verbose implementation that is easier to understand and maintain in the future.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618486</id>
	<title>Re:Has No One Actually Studied This?</title>
	<author>digitig</author>
	<datestamp>1262357700000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>A former employer (a very big multinational corporation) did a study that tried to correlate the number of comments in code to the number of problem reports against it.</p></div><p>Which seems to me to be representative of the sort of blunder very big multinational corporations seem particularly prone to. Just count the comments, never mind what the comment says.<nobr> <wbr></nobr>/* Stable sort in place, efficiency O(n log n) */
counts for the same as<nobr> <wbr></nobr>/* Oblig comment coz a dude in QA sez I has to */</p></div>
	</htmltext>
<tokenext>A former employer ( a very big multinational corporation ) did a study that tried to correlate the number of comments in code to the number of problem reports against it.Which seems to me to be representative of the sort of blunder very big multinational corporations seem particularly prone to .
Just count the comments , never mind what the comment says .
/ * Stable sort in place , efficiency O ( n log n ) * / counts for the same as / * Oblig comment coz a dude in QA sez I has to * /</tokentext>
<sentencetext>A former employer (a very big multinational corporation) did a study that tried to correlate the number of comments in code to the number of problem reports against it.Which seems to me to be representative of the sort of blunder very big multinational corporations seem particularly prone to.
Just count the comments, never mind what the comment says.
/* Stable sort in place, efficiency O(n log n) */
counts for the same as /* Oblig comment coz a dude in QA sez I has to */
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30625574</id>
	<title>Under and Over commenting</title>
	<author>CrazyFool</author>
	<datestamp>1262423700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Uncommented code is very often shitty code - and so is over-commented code.</p><p>Uncommented code is good if you 1) will be the only person to ever, ever, ever touch the code, 2) you have perfect memory, and 3) you don't expect anyone else on the planet to ever use it.</p><p><strong>General rule - assume the person following you is *not* a uber-coding-adept but just some average-joe/jane code-mechanic who has far, far more work on their plate then they can handle already.  And this isn't a freaking competition - you **are** allowed to give them a hand in understanding your latest convoluted masterpiece.  You usually are on the same team.</strong></p><p>At my workplace they have a library of perl code.  Most of it is pretty good \_code\_ and do usefull function.  But there is very, very, little comments and the writers simply LOVED to use the latest arcane features of Perl.   No subs are documented - "Hey - read the code!".</p><p>Sorry but why should I have to read and try to comprehend your convoluted code just to use it?  Its *your* responsibility as the author to make sure it does its job and its also *your* responsibility to document (and maintain that documentation) the interface to your code if you expect anyone else to use it. Its *my* responsiblity to follow your documentation and use your code properly.</p><p>Also subroutine/module/method comments are often picked up by IDEs to provide on-the-fly documentation (or 'hover-help') for anyone using your code - I'll admit that I find this very useful.</p><p>On the Other Hand - there are those who grossly over-comment their code.  We have a bunch of these types of people as well.</p><p>They Comment every single change and bracket their changes with comments showing the Change Request number as in :</p><p><nobr> <wbr></nobr>// FR: 1203938+</p><p><nobr> <wbr></nobr>... Block of new code...</p><p>// FR: 1203938-</p><p>The results, over time, a patch work of these comments - overlapping each other....  The code ends up virtually unreadable. There are far more lines of these types of comments than lines of code.</p></htmltext>
<tokenext>Uncommented code is very often shitty code - and so is over-commented code.Uncommented code is good if you 1 ) will be the only person to ever , ever , ever touch the code , 2 ) you have perfect memory , and 3 ) you do n't expect anyone else on the planet to ever use it.General rule - assume the person following you is * not * a uber-coding-adept but just some average-joe/jane code-mechanic who has far , far more work on their plate then they can handle already .
And this is n't a freaking competition - you * * are * * allowed to give them a hand in understanding your latest convoluted masterpiece .
You usually are on the same team.At my workplace they have a library of perl code .
Most of it is pretty good \ _code \ _ and do usefull function .
But there is very , very , little comments and the writers simply LOVED to use the latest arcane features of Perl .
No subs are documented - " Hey - read the code !
" .Sorry but why should I have to read and try to comprehend your convoluted code just to use it ?
Its * your * responsibility as the author to make sure it does its job and its also * your * responsibility to document ( and maintain that documentation ) the interface to your code if you expect anyone else to use it .
Its * my * responsiblity to follow your documentation and use your code properly.Also subroutine/module/method comments are often picked up by IDEs to provide on-the-fly documentation ( or 'hover-help ' ) for anyone using your code - I 'll admit that I find this very useful.On the Other Hand - there are those who grossly over-comment their code .
We have a bunch of these types of people as well.They Comment every single change and bracket their changes with comments showing the Change Request number as in : // FR : 1203938 + ... Block of new code...// FR : 1203938-The results , over time , a patch work of these comments - overlapping each other.... The code ends up virtually unreadable .
There are far more lines of these types of comments than lines of code .</tokentext>
<sentencetext>Uncommented code is very often shitty code - and so is over-commented code.Uncommented code is good if you 1) will be the only person to ever, ever, ever touch the code, 2) you have perfect memory, and 3) you don't expect anyone else on the planet to ever use it.General rule - assume the person following you is *not* a uber-coding-adept but just some average-joe/jane code-mechanic who has far, far more work on their plate then they can handle already.
And this isn't a freaking competition - you **are** allowed to give them a hand in understanding your latest convoluted masterpiece.
You usually are on the same team.At my workplace they have a library of perl code.
Most of it is pretty good \_code\_ and do usefull function.
But there is very, very, little comments and the writers simply LOVED to use the latest arcane features of Perl.
No subs are documented - "Hey - read the code!
".Sorry but why should I have to read and try to comprehend your convoluted code just to use it?
Its *your* responsibility as the author to make sure it does its job and its also *your* responsibility to document (and maintain that documentation) the interface to your code if you expect anyone else to use it.
Its *my* responsiblity to follow your documentation and use your code properly.Also subroutine/module/method comments are often picked up by IDEs to provide on-the-fly documentation (or 'hover-help') for anyone using your code - I'll admit that I find this very useful.On the Other Hand - there are those who grossly over-comment their code.
We have a bunch of these types of people as well.They Comment every single change and bracket their changes with comments showing the Change Request number as in : // FR: 1203938+ ... Block of new code...// FR: 1203938-The results, over time, a patch work of these comments - overlapping each other....  The code ends up virtually unreadable.
There are far more lines of these types of comments than lines of code.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617188</id>
	<title>Re:Does he think comments are pseudocode?</title>
	<author>noidentity</author>
	<datestamp>1262349480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>If your comments are that detailed, you're doing it wrong.</p></div>
</blockquote><p>No problem, just add some comments to explain the details.</p></div>
	</htmltext>
<tokenext>If your comments are that detailed , you 're doing it wrong .
No problem , just add some comments to explain the details .</tokentext>
<sentencetext>If your comments are that detailed, you're doing it wrong.
No problem, just add some comments to explain the details.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616868</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619398</id>
	<title>Re:One person's myth is another person's fact.</title>
	<author>Anonymous</author>
	<datestamp>1262366160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If you started coding and management hasn't provided a spec, then <i>management</i> are the ones who should be fired.</p><p>If you have a functional spec, it should already tell you everything you need to know about <i>what</i> the code is (supposed to be) doing.</p><p>I'm not saying there is never a need for comments; but documentation belongs in the documentation.</p></htmltext>
<tokenext>If you started coding and management has n't provided a spec , then management are the ones who should be fired.If you have a functional spec , it should already tell you everything you need to know about what the code is ( supposed to be ) doing.I 'm not saying there is never a need for comments ; but documentation belongs in the documentation .</tokentext>
<sentencetext>If you started coding and management hasn't provided a spec, then management are the ones who should be fired.If you have a functional spec, it should already tell you everything you need to know about what the code is (supposed to be) doing.I'm not saying there is never a need for comments; but documentation belongs in the documentation.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619960</id>
	<title>Re:every line of code should be commented</title>
	<author>Anonymous</author>
	<datestamp>1262373180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>/* You don't use<nobr> <wbr></nobr>// in C. */</p></htmltext>
<tokenext>/ * You do n't use // in C. * /</tokentext>
<sentencetext>/* You don't use // in C. */</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616836</id>
	<title>Please no</title>
	<author>dachshund</author>
	<datestamp>1262346720000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>Christ, I know everyone has their own personal style and everything, but this is just pernicious.  In any case, the author gives the game away: when he thinks code is overcommented, he can ask Emacs to hide the comments.  So far as I know there's no automatic system that will <i>generate</i> the comments that the author failed to put in because the code was "self-documenting".  This is particularly important when you're working with anything other than standard libraries --- you might know what "libfzp\_inc\_param\_count\_fast", but your reader probably won't.</p><p>Right now I'm working on a crypto library that incorporates a lot of very specific elliptic curve operations.  My technique is to comment the hell out of every damned interesting piece of code <i>on the assumption</i> that a picky reader can turn off the damned comments if they get in his way.  In fact, there are various places where I've actually scaffolded all of the comments before writing a line of code.  Doing otherwise would have been an enormous headache and made bugs a whole lot more likely.  And this way even a non-expert should be able to understand the entire program flow.</p><p>Unfortunately, one of the previous pieces of software in this area followed the poster's "self documenting code" style (very nice, clean, well written code with no comments), and even I find it difficult to piece together what's going on in places --- not because all of the code is crypto-specific, but because the author has thrown so much effort into writing "clean, pretty" code that it's actually hard to know where the crucial pieces are.  I can't quite explain why I find this so irritating, but perhaps some of you will know what I mean.</p></htmltext>
<tokenext>Christ , I know everyone has their own personal style and everything , but this is just pernicious .
In any case , the author gives the game away : when he thinks code is overcommented , he can ask Emacs to hide the comments .
So far as I know there 's no automatic system that will generate the comments that the author failed to put in because the code was " self-documenting " .
This is particularly important when you 're working with anything other than standard libraries --- you might know what " libfzp \ _inc \ _param \ _count \ _fast " , but your reader probably wo n't.Right now I 'm working on a crypto library that incorporates a lot of very specific elliptic curve operations .
My technique is to comment the hell out of every damned interesting piece of code on the assumption that a picky reader can turn off the damned comments if they get in his way .
In fact , there are various places where I 've actually scaffolded all of the comments before writing a line of code .
Doing otherwise would have been an enormous headache and made bugs a whole lot more likely .
And this way even a non-expert should be able to understand the entire program flow.Unfortunately , one of the previous pieces of software in this area followed the poster 's " self documenting code " style ( very nice , clean , well written code with no comments ) , and even I find it difficult to piece together what 's going on in places --- not because all of the code is crypto-specific , but because the author has thrown so much effort into writing " clean , pretty " code that it 's actually hard to know where the crucial pieces are .
I ca n't quite explain why I find this so irritating , but perhaps some of you will know what I mean .</tokentext>
<sentencetext>Christ, I know everyone has their own personal style and everything, but this is just pernicious.
In any case, the author gives the game away: when he thinks code is overcommented, he can ask Emacs to hide the comments.
So far as I know there's no automatic system that will generate the comments that the author failed to put in because the code was "self-documenting".
This is particularly important when you're working with anything other than standard libraries --- you might know what "libfzp\_inc\_param\_count\_fast", but your reader probably won't.Right now I'm working on a crypto library that incorporates a lot of very specific elliptic curve operations.
My technique is to comment the hell out of every damned interesting piece of code on the assumption that a picky reader can turn off the damned comments if they get in his way.
In fact, there are various places where I've actually scaffolded all of the comments before writing a line of code.
Doing otherwise would have been an enormous headache and made bugs a whole lot more likely.
And this way even a non-expert should be able to understand the entire program flow.Unfortunately, one of the previous pieces of software in this area followed the poster's "self documenting code" style (very nice, clean, well written code with no comments), and even I find it difficult to piece together what's going on in places --- not because all of the code is crypto-specific, but because the author has thrown so much effort into writing "clean, pretty" code that it's actually hard to know where the crucial pieces are.
I can't quite explain why I find this so irritating, but perhaps some of you will know what I mean.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617126</id>
	<title>Re:Shorter sentences</title>
	<author>paylett</author>
	<datestamp>1262349060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I think that if more people wrote code (or, for that matter, books) like George Orwell wrote his books, code (and books) would be generally more readable: shorter sentences (lines of code) which convey a single meaning (function), strung together into short paragraphs (code blocks), chained together into a larger cohesive whole.</p></div><p>
Complexity of that last sentence:<br>
* 52 words,<br>
* 17 punctuation characters,<br>
* 5 parentheses blocks,<br>
* at least half a dozen ideas.
</p><p>
But I'm just having fun. I agree with you 100\%.
</p></div>
	</htmltext>
<tokenext>I think that if more people wrote code ( or , for that matter , books ) like George Orwell wrote his books , code ( and books ) would be generally more readable : shorter sentences ( lines of code ) which convey a single meaning ( function ) , strung together into short paragraphs ( code blocks ) , chained together into a larger cohesive whole .
Complexity of that last sentence : * 52 words , * 17 punctuation characters , * 5 parentheses blocks , * at least half a dozen ideas .
But I 'm just having fun .
I agree with you 100 \ % .</tokentext>
<sentencetext>I think that if more people wrote code (or, for that matter, books) like George Orwell wrote his books, code (and books) would be generally more readable: shorter sentences (lines of code) which convey a single meaning (function), strung together into short paragraphs (code blocks), chained together into a larger cohesive whole.
Complexity of that last sentence:
* 52 words,
* 17 punctuation characters,
* 5 parentheses blocks,
* at least half a dozen ideas.
But I'm just having fun.
I agree with you 100\%.

	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616776</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30623060</id>
	<title>Re:Wrong on all accounts</title>
	<author>paenguin</author>
	<datestamp>1262452980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>My code <i>is</i> as good as I think it is.

Your comprehension skills are not as good as you think they are.</htmltext>
<tokenext>My code is as good as I think it is .
Your comprehension skills are not as good as you think they are .</tokentext>
<sentencetext>My code is as good as I think it is.
Your comprehension skills are not as good as you think they are.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30623756</id>
	<title>Re:every line of code should be commented</title>
	<author>Anonymous</author>
	<datestamp>1262456580000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><nobr> <wbr></nobr>//previous version did not work for negative i</p><p>unsigned int doit(unsigned int i) {<br>
&nbsp; if(i!=0) i+=doit(i-1);<br>
&nbsp; return i;<br>}</p></htmltext>
<tokenext>//previous version did not work for negative iunsigned int doit ( unsigned int i ) {   if ( i ! = 0 ) i + = doit ( i-1 ) ;   return i ; }</tokentext>
<sentencetext> //previous version did not work for negative iunsigned int doit(unsigned int i) {
  if(i!=0) i+=doit(i-1);
  return i;}</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617274</id>
	<title>its the What was i drinking problem</title>
	<author>RobertLTux</author>
	<datestamp>1262350140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>put comments in places where you may later need to remind yourself what you were thinking/drinking later (or if you get run over by a bus the next guy). Also in any places where you have to code around a bug in hardware or some other chunk of software make detailed comments.</p><p>a request to programmers please have a function to dump a settings file with all the settings set to defaults<br>(even those that would normally not be in the settings file)</p></htmltext>
<tokenext>put comments in places where you may later need to remind yourself what you were thinking/drinking later ( or if you get run over by a bus the next guy ) .
Also in any places where you have to code around a bug in hardware or some other chunk of software make detailed comments.a request to programmers please have a function to dump a settings file with all the settings set to defaults ( even those that would normally not be in the settings file )</tokentext>
<sentencetext>put comments in places where you may later need to remind yourself what you were thinking/drinking later (or if you get run over by a bus the next guy).
Also in any places where you have to code around a bug in hardware or some other chunk of software make detailed comments.a request to programmers please have a function to dump a settings file with all the settings set to defaults(even those that would normally not be in the settings file)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618320</id>
	<title>Re:Wrong on all accounts</title>
	<author>rainmaestro</author>
	<datestamp>1262356560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Undocumented code is only a problem if the code does something that isn't obvious to any second-year CS student. Some code simply doesn't require comments because the code is obvious to anyone reading it.</p><p>Get/Set methods: do they *really* need comments?<br>Basic assignment loops?<br>List traversal loops?<br>Swap function?<br>etc, etc</p><p>That being said, poorly or incorrectly documented code is truly evil, I'd rather see no comments than incorrect comments.</p></htmltext>
<tokenext>Undocumented code is only a problem if the code does something that is n't obvious to any second-year CS student .
Some code simply does n't require comments because the code is obvious to anyone reading it.Get/Set methods : do they * really * need comments ? Basic assignment loops ? List traversal loops ? Swap function ? etc , etcThat being said , poorly or incorrectly documented code is truly evil , I 'd rather see no comments than incorrect comments .</tokentext>
<sentencetext>Undocumented code is only a problem if the code does something that isn't obvious to any second-year CS student.
Some code simply doesn't require comments because the code is obvious to anyone reading it.Get/Set methods: do they *really* need comments?Basic assignment loops?List traversal loops?Swap function?etc, etcThat being said, poorly or incorrectly documented code is truly evil, I'd rather see no comments than incorrect comments.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622546</id>
	<title>pretty large pile of misconceptions</title>
	<author>Uzik2</author>
	<datestamp>1262450160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>In my long career I've never heard anyone advance the first two arguments, and only one manager ever required we comment every function. This guy must have just had a difficult time finding something to blog about if this is all he can post. Can you guys posting this do some vetting? Please?</htmltext>
<tokenext>In my long career I 've never heard anyone advance the first two arguments , and only one manager ever required we comment every function .
This guy must have just had a difficult time finding something to blog about if this is all he can post .
Can you guys posting this do some vetting ?
Please ?</tokentext>
<sentencetext>In my long career I've never heard anyone advance the first two arguments, and only one manager ever required we comment every function.
This guy must have just had a difficult time finding something to blog about if this is all he can post.
Can you guys posting this do some vetting?
Please?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617592</id>
	<title>Re:every line of code should be commented</title>
	<author>Anonymous</author>
	<datestamp>1262352540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Sadly, this is actually how some places teach commenting, apparently.  On a C forum I contribute to, posters will occasionally post code that is wildly overcommented.  There are literally comments along the lines of "these are the declarations".</p></htmltext>
<tokenext>Sadly , this is actually how some places teach commenting , apparently .
On a C forum I contribute to , posters will occasionally post code that is wildly overcommented .
There are literally comments along the lines of " these are the declarations " .</tokentext>
<sentencetext>Sadly, this is actually how some places teach commenting, apparently.
On a C forum I contribute to, posters will occasionally post code that is wildly overcommented.
There are literally comments along the lines of "these are the declarations".</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616984</id>
	<title>Re:One person's myth is another person's fact.</title>
	<author>Tanuki64</author>
	<datestamp>1262347860000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>I work on a really big hunk of C code and one place I would like to see more comments is in the start and end of blocks. This is because during the life of the code people come in and paste maybe 1000 lines of code from elsewhere into the block and totally stuff up the indenting so its hard to see what is supposed to match to what.</p></div><p>If the only tool you have is a hammer, every problem looks like a nail. You comments are in this case the nail you desperately want to hammer in, when in reality you need a refactoring. And you need to give the idiot, who pastes the additional 1000 lines, a hearty kick in the ass.</p></div>
	</htmltext>
<tokenext>I work on a really big hunk of C code and one place I would like to see more comments is in the start and end of blocks .
This is because during the life of the code people come in and paste maybe 1000 lines of code from elsewhere into the block and totally stuff up the indenting so its hard to see what is supposed to match to what.If the only tool you have is a hammer , every problem looks like a nail .
You comments are in this case the nail you desperately want to hammer in , when in reality you need a refactoring .
And you need to give the idiot , who pastes the additional 1000 lines , a hearty kick in the ass .</tokentext>
<sentencetext>I work on a really big hunk of C code and one place I would like to see more comments is in the start and end of blocks.
This is because during the life of the code people come in and paste maybe 1000 lines of code from elsewhere into the block and totally stuff up the indenting so its hard to see what is supposed to match to what.If the only tool you have is a hammer, every problem looks like a nail.
You comments are in this case the nail you desperately want to hammer in, when in reality you need a refactoring.
And you need to give the idiot, who pastes the additional 1000 lines, a hearty kick in the ass.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616750</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618106</id>
	<title>Re:Warning - war story ahead</title>
	<author>Anonymous</author>
	<datestamp>1262355540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Soo, who else wants to know what 'midlertidig' actually means? Google gave me various pages that seem to indicate something like 'temporarily', heh. Might be wrong though.</p></htmltext>
<tokenext>Soo , who else wants to know what 'midlertidig ' actually means ?
Google gave me various pages that seem to indicate something like 'temporarily ' , heh .
Might be wrong though .</tokentext>
<sentencetext>Soo, who else wants to know what 'midlertidig' actually means?
Google gave me various pages that seem to indicate something like 'temporarily', heh.
Might be wrong though.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617380</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617430</id>
	<title>Re:More verbose == less readable?</title>
	<author>jbolden</author>
	<datestamp>1262351400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It depends on whether we are talking a one liner like Haskell or a one liner like Perl.</p><p>Perl and C have an incredibly powerful syntax which allows for mashing programs down to one cool line of code.  These techniques can be used for structuring the program to keep the emphasis where it should be.</p><p>Conversely Haskell tends to make you think long and hard about the true nature of the problem.  That one line represents a perfect understanding of the algorithm if it doesn't make absolute sense, in a "it could be no other way" you shouldn't be touching the code.  The result is 3000 line programs become 60 lines of really interesting ideas.</p></htmltext>
<tokenext>It depends on whether we are talking a one liner like Haskell or a one liner like Perl.Perl and C have an incredibly powerful syntax which allows for mashing programs down to one cool line of code .
These techniques can be used for structuring the program to keep the emphasis where it should be.Conversely Haskell tends to make you think long and hard about the true nature of the problem .
That one line represents a perfect understanding of the algorithm if it does n't make absolute sense , in a " it could be no other way " you should n't be touching the code .
The result is 3000 line programs become 60 lines of really interesting ideas .</tokentext>
<sentencetext>It depends on whether we are talking a one liner like Haskell or a one liner like Perl.Perl and C have an incredibly powerful syntax which allows for mashing programs down to one cool line of code.
These techniques can be used for structuring the program to keep the emphasis where it should be.Conversely Haskell tends to make you think long and hard about the true nature of the problem.
That one line represents a perfect understanding of the algorithm if it doesn't make absolute sense, in a "it could be no other way" you shouldn't be touching the code.
The result is 3000 line programs become 60 lines of really interesting ideas.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616770</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618444</id>
	<title>Re:"would you rather use a one-liner"</title>
	<author>careysub</author>
	<datestamp>1262357280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>After writing a couple of million lines of code, the more code I write, the more I unwind it. Somewhere along the line, adolescent programmers got the idea that jamming all your logic into as few unreadable lines as possible is the fastest way to manliness. Way, way wrong.</p></div><p>Amen to that brother!</p><p>I am also much aggrieved by the corollary: junior developers coming up to me to complain about my "bad coding" - i.e. writing visibly nested loops with clear indentation of each level, and separating different logic tests into different statements, instead of mashing everything together into a few unindented lines.</p></div>
	</htmltext>
<tokenext>After writing a couple of million lines of code , the more code I write , the more I unwind it .
Somewhere along the line , adolescent programmers got the idea that jamming all your logic into as few unreadable lines as possible is the fastest way to manliness .
Way , way wrong.Amen to that brother ! I am also much aggrieved by the corollary : junior developers coming up to me to complain about my " bad coding " - i.e .
writing visibly nested loops with clear indentation of each level , and separating different logic tests into different statements , instead of mashing everything together into a few unindented lines .</tokentext>
<sentencetext>After writing a couple of million lines of code, the more code I write, the more I unwind it.
Somewhere along the line, adolescent programmers got the idea that jamming all your logic into as few unreadable lines as possible is the fastest way to manliness.
Way, way wrong.Amen to that brother!I am also much aggrieved by the corollary: junior developers coming up to me to complain about my "bad coding" - i.e.
writing visibly nested loops with clear indentation of each level, and separating different logic tests into different statements, instead of mashing everything together into a few unindented lines.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616920</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618680</id>
	<title>Re:One person's myth is another person's fact.</title>
	<author>GeckoAddict</author>
	<datestamp>1262359140000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>This is because during the life of the code people come in and paste maybe 1000 lines of code from elsewhere into the block</p></div><p>Your design is horribly wrong.</p><p><div class="quote"><p>so its hard to see what is supposed to match to what</p></div><p>Branches or not, you need a coding standard, fast.</p><p><div class="quote"><p>Where I work comments get used to abuse people. </p></div><p>Your development team is in need of some management and/or personal communication skills.</p></div>
	</htmltext>
<tokenext>This is because during the life of the code people come in and paste maybe 1000 lines of code from elsewhere into the blockYour design is horribly wrong.so its hard to see what is supposed to match to whatBranches or not , you need a coding standard , fast.Where I work comments get used to abuse people .
Your development team is in need of some management and/or personal communication skills .</tokentext>
<sentencetext>This is because during the life of the code people come in and paste maybe 1000 lines of code from elsewhere into the blockYour design is horribly wrong.so its hard to see what is supposed to match to whatBranches or not, you need a coding standard, fast.Where I work comments get used to abuse people.
Your development team is in need of some management and/or personal communication skills.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616750</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617520</id>
	<title>Comments are useful</title>
	<author>trbarry</author>
	<datestamp>1262352060000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>There is another myth that says just because something is mathematically unambiguous it also intuitively obvious.  And yet the real implications may be lost in the complexity of the situation or problem.  Comments can point out anything useful to the code reader.</p><p>Also, if you spend enough time staring at a piece of code you can usually figure out what it does.  But that does not at all mean you can figure out what the programmer was really trying to do.  His/her internt may have been quite different.  You can also not figure out all the possibly erroneous assumptions made about the problem space at the time of coding.</p><p>Comments form a useful redundancy and sanity check.  Being cutely terse in comments is as bad as the clever but incomprehensible code one liner.</p><p>You should add comments anywhere you can predict a reader may have a high probability of misunderstanding.</p><p>- Tom</p></htmltext>
<tokenext>There is another myth that says just because something is mathematically unambiguous it also intuitively obvious .
And yet the real implications may be lost in the complexity of the situation or problem .
Comments can point out anything useful to the code reader.Also , if you spend enough time staring at a piece of code you can usually figure out what it does .
But that does not at all mean you can figure out what the programmer was really trying to do .
His/her internt may have been quite different .
You can also not figure out all the possibly erroneous assumptions made about the problem space at the time of coding.Comments form a useful redundancy and sanity check .
Being cutely terse in comments is as bad as the clever but incomprehensible code one liner.You should add comments anywhere you can predict a reader may have a high probability of misunderstanding.- Tom</tokentext>
<sentencetext>There is another myth that says just because something is mathematically unambiguous it also intuitively obvious.
And yet the real implications may be lost in the complexity of the situation or problem.
Comments can point out anything useful to the code reader.Also, if you spend enough time staring at a piece of code you can usually figure out what it does.
But that does not at all mean you can figure out what the programmer was really trying to do.
His/her internt may have been quite different.
You can also not figure out all the possibly erroneous assumptions made about the problem space at the time of coding.Comments form a useful redundancy and sanity check.
Being cutely terse in comments is as bad as the clever but incomprehensible code one liner.You should add comments anywhere you can predict a reader may have a high probability of misunderstanding.- Tom</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618278</id>
	<title>It depends on the quality of the comments</title>
	<author>MartinSchou</author>
	<datestamp>1262356380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>As others have said, if the comments are along the lines of  </p><blockquote><div><p> <tt>i++;//increment i</tt></p></div> </blockquote><p> then it's just complete rubbish.</p><p>What I would like to see though, is some very complicated encryption algorithm with and without useful comments (useful being the why). See which of them are easier for the average developer to get a grasp of.</p></div>
	</htmltext>
<tokenext>As others have said , if the comments are along the lines of i + + ; //increment i then it 's just complete rubbish.What I would like to see though , is some very complicated encryption algorithm with and without useful comments ( useful being the why ) .
See which of them are easier for the average developer to get a grasp of .</tokentext>
<sentencetext>As others have said, if the comments are along the lines of   i++;//increment i  then it's just complete rubbish.What I would like to see though, is some very complicated encryption algorithm with and without useful comments (useful being the why).
See which of them are easier for the average developer to get a grasp of.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620940</id>
	<title>Re:One person's myth is another person's fact.</title>
	<author>jrbrtsn</author>
	<datestamp>1262430480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Run the source file through the GNU 'indent' program, and the indenting will be perfect.  Use a better text editor. Vim understands the difference between a commented brace and an uncommented brace. Vim even understands '#if 0<nobr> <wbr></nobr>... #endif', which is a common way to comment out large blocks of code.</p></htmltext>
<tokenext>Run the source file through the GNU 'indent ' program , and the indenting will be perfect .
Use a better text editor .
Vim understands the difference between a commented brace and an uncommented brace .
Vim even understands ' # if 0 ... # endif ' , which is a common way to comment out large blocks of code .</tokentext>
<sentencetext>Run the source file through the GNU 'indent' program, and the indenting will be perfect.
Use a better text editor.
Vim understands the difference between a commented brace and an uncommented brace.
Vim even understands '#if 0 ... #endif', which is a common way to comment out large blocks of code.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616750</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618534</id>
	<title>Re:Has No One Actually Studied This?</title>
	<author>Anonymous</author>
	<datestamp>1262358000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Shouldn't it have measured the comment-to-code ratio rather than the number of comments?  More lines of code imply more comments, and more lines of code (generally) give a larger chance of something going wrong.</p></htmltext>
<tokenext>Should n't it have measured the comment-to-code ratio rather than the number of comments ?
More lines of code imply more comments , and more lines of code ( generally ) give a larger chance of something going wrong .</tokentext>
<sentencetext>Shouldn't it have measured the comment-to-code ratio rather than the number of comments?
More lines of code imply more comments, and more lines of code (generally) give a larger chance of something going wrong.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616776</id>
	<title>In other news...</title>
	<author>CAIMLAS</author>
	<datestamp>1262346180000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>In other news, people have personal preferences, just as they do in the literary world. Some people like Ayn Rand, others hate her. Some like Stephen King, others hate him. Not so much their stories, but their writing styles.</p><p>Snowcrash is an awesome story; one many can appreciate, but most people couldn't get through his writing style to finish the book.</p><p>I think that if more people wrote code (or, for that matter, books) like George Orwell wrote his books, code (and books) would be generally more readable: shorter sentences (lines of code) which convey a single meaning (function), strung together into short paragraphs (code blocks), chained together into a larger cohesive whole.</p></htmltext>
<tokenext>In other news , people have personal preferences , just as they do in the literary world .
Some people like Ayn Rand , others hate her .
Some like Stephen King , others hate him .
Not so much their stories , but their writing styles.Snowcrash is an awesome story ; one many can appreciate , but most people could n't get through his writing style to finish the book.I think that if more people wrote code ( or , for that matter , books ) like George Orwell wrote his books , code ( and books ) would be generally more readable : shorter sentences ( lines of code ) which convey a single meaning ( function ) , strung together into short paragraphs ( code blocks ) , chained together into a larger cohesive whole .</tokentext>
<sentencetext>In other news, people have personal preferences, just as they do in the literary world.
Some people like Ayn Rand, others hate her.
Some like Stephen King, others hate him.
Not so much their stories, but their writing styles.Snowcrash is an awesome story; one many can appreciate, but most people couldn't get through his writing style to finish the book.I think that if more people wrote code (or, for that matter, books) like George Orwell wrote his books, code (and books) would be generally more readable: shorter sentences (lines of code) which convey a single meaning (function), strung together into short paragraphs (code blocks), chained together into a larger cohesive whole.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618174</id>
	<title>Tbis is why COBOL is the best...</title>
	<author>cts5678</author>
	<datestamp>1262355840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>language: it's self-documenting code.</htmltext>
<tokenext>language : it 's self-documenting code .</tokentext>
<sentencetext>language: it's self-documenting code.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619016</id>
	<title>Do it in blocks</title>
	<author>phred75</author>
	<datestamp>1262362020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Unless I'm coding some high speed spASM code... In regular C/C++ I stick to commenting a whole block as opposed to each line. I've worked with overly anal coders who code each line.. I want to kick them in the teeth.</htmltext>
<tokenext>Unless I 'm coding some high speed spASM code... In regular C/C + + I stick to commenting a whole block as opposed to each line .
I 've worked with overly anal coders who code each line.. I want to kick them in the teeth .</tokentext>
<sentencetext>Unless I'm coding some high speed spASM code... In regular C/C++ I stick to commenting a whole block as opposed to each line.
I've worked with overly anal coders who code each line.. I want to kick them in the teeth.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762</id>
	<title>Has No One Actually Studied This?</title>
	<author>Anonymous</author>
	<datestamp>1262346120000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext>In thirty years of programming, I've heard one person after another argue about how to comment and how much to comment, but what I've never seen is any kind of serious study attempting to measure what actually works best. I personally like to make comments paragraphs, not lines, and generally end up with code that's 1/3 to 1/2 comment lines, but the most I can claim is "it works for me."
<p>
I do think good commenting has to be a key part of software engineering (when it finally becomes a real engineering discipline), and I know software engineering is a hot topic these days, so perhaps there's a paper on this that I just haven't seen yet. If not, someone really ought to do a serious study. And then start teaching people something that's actually known to work.
</p><p>
--Greg</p></htmltext>
<tokenext>In thirty years of programming , I 've heard one person after another argue about how to comment and how much to comment , but what I 've never seen is any kind of serious study attempting to measure what actually works best .
I personally like to make comments paragraphs , not lines , and generally end up with code that 's 1/3 to 1/2 comment lines , but the most I can claim is " it works for me .
" I do think good commenting has to be a key part of software engineering ( when it finally becomes a real engineering discipline ) , and I know software engineering is a hot topic these days , so perhaps there 's a paper on this that I just have n't seen yet .
If not , someone really ought to do a serious study .
And then start teaching people something that 's actually known to work .
--Greg</tokentext>
<sentencetext>In thirty years of programming, I've heard one person after another argue about how to comment and how much to comment, but what I've never seen is any kind of serious study attempting to measure what actually works best.
I personally like to make comments paragraphs, not lines, and generally end up with code that's 1/3 to 1/2 comment lines, but the most I can claim is "it works for me.
"

I do think good commenting has to be a key part of software engineering (when it finally becomes a real engineering discipline), and I know software engineering is a hot topic these days, so perhaps there's a paper on this that I just haven't seen yet.
If not, someone really ought to do a serious study.
And then start teaching people something that's actually known to work.
--Greg</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622044</id>
	<title>Re:every line of code should be commented</title>
	<author>Anonymous</author>
	<datestamp>1262445840000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You forgot to comment the line that says "else"; in addition, it's not an "if" block, but an "else" block.</p><p>You just pointed out (intentionally?) what I dislike the most about comments. First I read the code, *then* the comments, *then* whether *both* are consistent and make sense with each other. In case they don't (they often don't) which one should prevail?</p></htmltext>
<tokenext>You forgot to comment the line that says " else " ; in addition , it 's not an " if " block , but an " else " block.You just pointed out ( intentionally ?
) what I dislike the most about comments .
First I read the code , * then * the comments , * then * whether * both * are consistent and make sense with each other .
In case they do n't ( they often do n't ) which one should prevail ?</tokentext>
<sentencetext>You forgot to comment the line that says "else"; in addition, it's not an "if" block, but an "else" block.You just pointed out (intentionally?
) what I dislike the most about comments.
First I read the code, *then* the comments, *then* whether *both* are consistent and make sense with each other.
In case they don't (they often don't) which one should prevail?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30623100</id>
	<title>interpreted?</title>
	<author>Anonymous</author>
	<datestamp>1262453220000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>noone seems to have remembered the burden caused by over zealous commenting in interpreted languages as opposed to compiled where they comfortably vanish and save otherwise wasted clocktime.</p></htmltext>
<tokenext>noone seems to have remembered the burden caused by over zealous commenting in interpreted languages as opposed to compiled where they comfortably vanish and save otherwise wasted clocktime .</tokentext>
<sentencetext>noone seems to have remembered the burden caused by over zealous commenting in interpreted languages as opposed to compiled where they comfortably vanish and save otherwise wasted clocktime.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617394</id>
	<title>Fun</title>
	<author>Anonymous</author>
	<datestamp>1262351100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>http://xkcd.com/156/</p></htmltext>
<tokenext>http : //xkcd.com/156/</tokentext>
<sentencetext>http://xkcd.com/156/</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618942</id>
	<title>Re:Warning - war story ahead</title>
	<author>vorpal^</author>
	<datestamp>1262361180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You are correct, as per Google translate. Note, though, that slashdot breaks the below link; you have to fix it manually. (Apparently | indicates an end of URL in slashdot logic.)</p><p><a href="http://translate.google.com/#da" title="google.com">http://translate.google.com/#da</a> [google.com]|en|midlertidig</p></htmltext>
<tokenext>You are correct , as per Google translate .
Note , though , that slashdot breaks the below link ; you have to fix it manually .
( Apparently | indicates an end of URL in slashdot logic .
) http : //translate.google.com/ # da [ google.com ] | en | midlertidig</tokentext>
<sentencetext>You are correct, as per Google translate.
Note, though, that slashdot breaks the below link; you have to fix it manually.
(Apparently | indicates an end of URL in slashdot logic.
)http://translate.google.com/#da [google.com]|en|midlertidig</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618106</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617052</id>
	<title>Strongly RESTRICT Code Commenting</title>
	<author>omb</author>
	<datestamp>1262348520000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>There are just 3 good reasons for comments in code: (a) to refer to a published paper describing an (obscure) algorithm, eg '[fast graph traversal algorithm, M. M. Balakrishnarajan and P. Venuvanalingam<nobr> <wbr></nobr>,Computers &amp; Chemistry, Volume 19, Issue 2, June 1995, Pages 101-106] , (b) to indicate an arcane, obscure usage, which would be better eliminated, but sometimes cannot be eg in device drivers, when merely addressing a device register has side effects, (c) to very briefly document major parts of program flow-meaning, if this isn't otherwise obvious.<br><br>In addition, temporary development comments help while writing or refactoring code, but they come out and become empty or (a)-(c), eg<nobr> <wbr></nobr>// XXXX I dont understand this; or # Class is defined in Foo.pm.<br><br>Usually code is OVER commented, or the comments are facile eg 'i++;<nobr> <wbr></nobr>// increment i' and this CRAP should be avoided at all costs.<br><br>The other thing to be avoided is lengthy legalese or copyright information spread all over code. If this is necessary, at all, it should fit on one line and if necessary reference a COPYRIGHT or LEGAL file<br><br>OK<nobr> <wbr></nobr>// Copyright (c) 2001-2010 Foo.Bar, all rights reserved, Licenced under the MIT license.<br><br>BAD<nobr> <wbr></nobr>/* Error constants.  Linux specific version.<br><br>-- 15 lines deleted<br><br>
&nbsp; &nbsp; &nbsp; 02111-1307 USA.  */<br><br>Finally, never believe the comments, at minimum they didnt get debugged!</htmltext>
<tokenext>There are just 3 good reasons for comments in code : ( a ) to refer to a published paper describing an ( obscure ) algorithm , eg ' [ fast graph traversal algorithm , M. M. Balakrishnarajan and P. Venuvanalingam ,Computers &amp; Chemistry , Volume 19 , Issue 2 , June 1995 , Pages 101-106 ] , ( b ) to indicate an arcane , obscure usage , which would be better eliminated , but sometimes can not be eg in device drivers , when merely addressing a device register has side effects , ( c ) to very briefly document major parts of program flow-meaning , if this is n't otherwise obvious.In addition , temporary development comments help while writing or refactoring code , but they come out and become empty or ( a ) - ( c ) , eg // XXXX I dont understand this ; or # Class is defined in Foo.pm.Usually code is OVER commented , or the comments are facile eg 'i + + ; // increment i ' and this CRAP should be avoided at all costs.The other thing to be avoided is lengthy legalese or copyright information spread all over code .
If this is necessary , at all , it should fit on one line and if necessary reference a COPYRIGHT or LEGAL fileOK // Copyright ( c ) 2001-2010 Foo.Bar , all rights reserved , Licenced under the MIT license.BAD / * Error constants .
Linux specific version.-- 15 lines deleted       02111-1307 USA .
* /Finally , never believe the comments , at minimum they didnt get debugged !</tokentext>
<sentencetext>There are just 3 good reasons for comments in code: (a) to refer to a published paper describing an (obscure) algorithm, eg '[fast graph traversal algorithm, M. M. Balakrishnarajan and P. Venuvanalingam ,Computers &amp; Chemistry, Volume 19, Issue 2, June 1995, Pages 101-106] , (b) to indicate an arcane, obscure usage, which would be better eliminated, but sometimes cannot be eg in device drivers, when merely addressing a device register has side effects, (c) to very briefly document major parts of program flow-meaning, if this isn't otherwise obvious.In addition, temporary development comments help while writing or refactoring code, but they come out and become empty or (a)-(c), eg // XXXX I dont understand this; or # Class is defined in Foo.pm.Usually code is OVER commented, or the comments are facile eg 'i++; // increment i' and this CRAP should be avoided at all costs.The other thing to be avoided is lengthy legalese or copyright information spread all over code.
If this is necessary, at all, it should fit on one line and if necessary reference a COPYRIGHT or LEGAL fileOK // Copyright (c) 2001-2010 Foo.Bar, all rights reserved, Licenced under the MIT license.BAD /* Error constants.
Linux specific version.-- 15 lines deleted
      02111-1307 USA.
*/Finally, never believe the comments, at minimum they didnt get debugged!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932</id>
	<title>every line of code should be commented</title>
	<author>caywen</author>
	<datestamp>1262347500000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext><p>Every line should be commented, like:<nobr> <wbr></nobr>// Declare function called doit with one int param that returns an int<br>int doit(int i)<nobr> <wbr></nobr>// See above comment<br>{<nobr> <wbr></nobr>// The function's open brace. I like to put braces on their own line. You should too!! BTW, this is C code, so braces are totally the way to go.<br>
&nbsp; &nbsp; &nbsp; if(i == 0)<nobr> <wbr></nobr>// Check if i is 0. You know, in C, "==" is the way to compare values, unlike in VB where you use a single "=". Just thought u should know.<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return 0;<nobr> <wbr></nobr>// Return 0. That is, all the bits of the return value are 0. We could also return i, because i is 0, too. That is, all the bits of i are 0. On a 32 bit system, there would be, like, 32 0's.<br>
&nbsp; &nbsp; &nbsp; else<br>
&nbsp; &nbsp; &nbsp; {<nobr> <wbr></nobr>// Begin an if block using a brace (this is C syntax!!!)<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; int j = i - 1;<nobr> <wbr></nobr>// Declare an int variable named j that is one less than i<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return i + doit(j);<nobr> <wbr></nobr>// Return the sum of i and the value of calling doit with j<br>
&nbsp; &nbsp; &nbsp; }<nobr> <wbr></nobr>// Finish the if block with a C close brace. By the way, we could have written the above code as return i + doit(i - 1) without using the braces.<br>}<nobr> <wbr></nobr>// The function's close brace.</p><p>There! Now that is both way readable and informative. Anything less would just not pass my code review.</p></htmltext>
<tokenext>Every line should be commented , like : // Declare function called doit with one int param that returns an intint doit ( int i ) // See above comment { // The function 's open brace .
I like to put braces on their own line .
You should too ! !
BTW , this is C code , so braces are totally the way to go .
      if ( i = = 0 ) // Check if i is 0 .
You know , in C , " = = " is the way to compare values , unlike in VB where you use a single " = " .
Just thought u should know .
            return 0 ; // Return 0 .
That is , all the bits of the return value are 0 .
We could also return i , because i is 0 , too .
That is , all the bits of i are 0 .
On a 32 bit system , there would be , like , 32 0 's .
      else       { // Begin an if block using a brace ( this is C syntax ! ! !
)             int j = i - 1 ; // Declare an int variable named j that is one less than i             return i + doit ( j ) ; // Return the sum of i and the value of calling doit with j       } // Finish the if block with a C close brace .
By the way , we could have written the above code as return i + doit ( i - 1 ) without using the braces .
} // The function 's close brace.There !
Now that is both way readable and informative .
Anything less would just not pass my code review .</tokentext>
<sentencetext>Every line should be commented, like: // Declare function called doit with one int param that returns an intint doit(int i) // See above comment{ // The function's open brace.
I like to put braces on their own line.
You should too!!
BTW, this is C code, so braces are totally the way to go.
      if(i == 0) // Check if i is 0.
You know, in C, "==" is the way to compare values, unlike in VB where you use a single "=".
Just thought u should know.
            return 0; // Return 0.
That is, all the bits of the return value are 0.
We could also return i, because i is 0, too.
That is, all the bits of i are 0.
On a 32 bit system, there would be, like, 32 0's.
      else
      { // Begin an if block using a brace (this is C syntax!!!
)
            int j = i - 1; // Declare an int variable named j that is one less than i
            return i + doit(j); // Return the sum of i and the value of calling doit with j
      } // Finish the if block with a C close brace.
By the way, we could have written the above code as return i + doit(i - 1) without using the braces.
} // The function's close brace.There!
Now that is both way readable and informative.
Anything less would just not pass my code review.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622508</id>
	<title>No Comment</title>
	<author>Rambo Tribble</author>
	<datestamp>1262449860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It needed to be said.</htmltext>
<tokenext>It needed to be said .</tokentext>
<sentencetext>It needed to be said.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621436</id>
	<title>Troll indeed</title>
	<author>mrjb</author>
	<datestamp>1262438100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>"Comments aren't actually executable code, therefore they aren't maintenance costs, right?"<br> <br>
Absolutely right, yes. Although comments also need to be maintained when the code is updated, their maintenance costs are negative, because they SAVE TIME (That's why they were invented)! <br> <br>
The same goes for other forms of documentation- some code would not only take *more* time to maintain without documentation, but would simply be impossible to maintain without it.<br> <br>
"Comments make code more readable."<br> <br>
Yes. Not all of them, but when used properly, they damn well do. Example: If there is a 'magic number' in the code, a comment can help explain how the author arrived at that magic number, and allows the next
developer to change the magic number to another value as needed. Without the comment, this would be impossible.<br> <br>

Another example:<br> <br>

unsigned long lastsectornum()<br>
{<br>
if (!(this-&gt;foundlastsectornum))<br>
{<br><nobr> <wbr></nobr>// cache result.<br>
this-&gt;m\_lastsectornum<br>
  =lookuplastsectornum();<br>
this-&gt;foundlastsectornum=true;<br>
}<br>
return this-&gt;m\_lastsectornum;<br>
}<br>

I'd say in the above example, the two-word comment makes it a lot more clear what is going on.<br>
<br>
"You should comment every function, method, class, and module"<br>
<br>
Jason goes on to use this as an example:<br>
<br>
def get\_x(self):   <br>
 """   <br>
 This method gets x.   <br>
 """   <br>
<br>
That's simply a bad comment, but it doesn't invalidate the statement. We still want a comment there- one that explains what 'x' is. Without comment, there is no way to tell. The problem here is not that there *is* a comment, but that the author (in this case Jason) wrote one without added value. For any function with parameters, however, we'd want to know what upper/boundaries they have.
<br> <br>
def get\_x(self):   <br>
 """   <br>
 Returns horizontal pos. of the mouse cursor<br>
 """   <br>
<br>

See, this is much clearer! (though arguably, the method name is wrong and the comment unnecessary). There's still a use for a comment here: What does the method return if no mouse is present? Is it the responsibility of the method to check for this, or is it simply not allowed to call the method in such cases? Comments to the rescue once again.<br>
<br>
"Code must always be self-documenting"<br>
<br>
Jason calls this a myth as well, and this time I have to agree with him. Although we should strive to make our code as clear as possible, it *can* not always be self-documenting. Comments were invented to solve that (see above).<br>
<br>
However, "In most cases, comments should be viewed as code smells." is utter bull. Jason should spend a few years writing assembly language. Perhaps then he'll learn to value comments for what they're worth. Personally, I have a strong feeling I wouldn't want to maintain Jason's code, as he feels that he need neither document his code nor write self-documenting code.</htmltext>
<tokenext>" Comments are n't actually executable code , therefore they are n't maintenance costs , right ?
" Absolutely right , yes .
Although comments also need to be maintained when the code is updated , their maintenance costs are negative , because they SAVE TIME ( That 's why they were invented ) !
The same goes for other forms of documentation- some code would not only take * more * time to maintain without documentation , but would simply be impossible to maintain without it .
" Comments make code more readable .
" Yes .
Not all of them , but when used properly , they damn well do .
Example : If there is a 'magic number ' in the code , a comment can help explain how the author arrived at that magic number , and allows the next developer to change the magic number to another value as needed .
Without the comment , this would be impossible .
Another example : unsigned long lastsectornum ( ) { if ( !
( this- &gt; foundlastsectornum ) ) { // cache result .
this- &gt; m \ _lastsectornum = lookuplastsectornum ( ) ; this- &gt; foundlastsectornum = true ; } return this- &gt; m \ _lastsectornum ; } I 'd say in the above example , the two-word comment makes it a lot more clear what is going on .
" You should comment every function , method , class , and module " Jason goes on to use this as an example : def get \ _x ( self ) : " " " This method gets x .
" " " That 's simply a bad comment , but it does n't invalidate the statement .
We still want a comment there- one that explains what 'x ' is .
Without comment , there is no way to tell .
The problem here is not that there * is * a comment , but that the author ( in this case Jason ) wrote one without added value .
For any function with parameters , however , we 'd want to know what upper/boundaries they have .
def get \ _x ( self ) : " " " Returns horizontal pos .
of the mouse cursor " " " See , this is much clearer !
( though arguably , the method name is wrong and the comment unnecessary ) .
There 's still a use for a comment here : What does the method return if no mouse is present ?
Is it the responsibility of the method to check for this , or is it simply not allowed to call the method in such cases ?
Comments to the rescue once again .
" Code must always be self-documenting " Jason calls this a myth as well , and this time I have to agree with him .
Although we should strive to make our code as clear as possible , it * can * not always be self-documenting .
Comments were invented to solve that ( see above ) .
However , " In most cases , comments should be viewed as code smells .
" is utter bull .
Jason should spend a few years writing assembly language .
Perhaps then he 'll learn to value comments for what they 're worth .
Personally , I have a strong feeling I would n't want to maintain Jason 's code , as he feels that he need neither document his code nor write self-documenting code .</tokentext>
<sentencetext>"Comments aren't actually executable code, therefore they aren't maintenance costs, right?
" 
Absolutely right, yes.
Although comments also need to be maintained when the code is updated, their maintenance costs are negative, because they SAVE TIME (That's why they were invented)!
The same goes for other forms of documentation- some code would not only take *more* time to maintain without documentation, but would simply be impossible to maintain without it.
"Comments make code more readable.
" 
Yes.
Not all of them, but when used properly, they damn well do.
Example: If there is a 'magic number' in the code, a comment can help explain how the author arrived at that magic number, and allows the next
developer to change the magic number to another value as needed.
Without the comment, this would be impossible.
Another example: 

unsigned long lastsectornum()
{
if (!
(this-&gt;foundlastsectornum))
{ // cache result.
this-&gt;m\_lastsectornum
  =lookuplastsectornum();
this-&gt;foundlastsectornum=true;
}
return this-&gt;m\_lastsectornum;
}

I'd say in the above example, the two-word comment makes it a lot more clear what is going on.
"You should comment every function, method, class, and module"

Jason goes on to use this as an example:

def get\_x(self):   
 """   
 This method gets x.
"""   

That's simply a bad comment, but it doesn't invalidate the statement.
We still want a comment there- one that explains what 'x' is.
Without comment, there is no way to tell.
The problem here is not that there *is* a comment, but that the author (in this case Jason) wrote one without added value.
For any function with parameters, however, we'd want to know what upper/boundaries they have.
def get\_x(self):   
 """   
 Returns horizontal pos.
of the mouse cursor
 """   


See, this is much clearer!
(though arguably, the method name is wrong and the comment unnecessary).
There's still a use for a comment here: What does the method return if no mouse is present?
Is it the responsibility of the method to check for this, or is it simply not allowed to call the method in such cases?
Comments to the rescue once again.
"Code must always be self-documenting"

Jason calls this a myth as well, and this time I have to agree with him.
Although we should strive to make our code as clear as possible, it *can* not always be self-documenting.
Comments were invented to solve that (see above).
However, "In most cases, comments should be viewed as code smells.
" is utter bull.
Jason should spend a few years writing assembly language.
Perhaps then he'll learn to value comments for what they're worth.
Personally, I have a strong feeling I wouldn't want to maintain Jason's code, as he feels that he need neither document his code nor write self-documenting code.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620200</id>
	<title>Literate Programing</title>
	<author>os2fan</author>
	<datestamp>1262462580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Don Knuth described Literate Programming in which the program is embedded in comments, one using a preprocessor to write the program.  The preprocessor runs as a command processor, using the source as a batch file.  One gets a properly sorted batch file as output.  Because of this, one can overcome limitations of the programming language, use pre-processor variables etc, and produce several linked files etc.

</p><p>Documentation is relatively straight forward, since one writes what one wants to get, limitations, API and examples by way of a wish-list, and then create the routines that make this happen.  You can write a tight section like "File I/O", for fileopen() and fileclose() along with getline(), putline(),  etc, without exposing the filenames to all of the subroutines.  I've written a program to write Web pages in it, for example, http:\\www.os2fan2.com\pgloss\index.html and its attendent pages. It's pretty elegant really.

</p><p>The temptation of LP is to use it to solve a problem per source, a note that Jon Bentley (Pearls of Programming) noted.  LP is about sorting problems: however, the sort of problems that Knuth sought to solve are complete things in an educational setting, not bits of problems in the real world.  None the less, I use it to write terse batch files etc, where the LP source is the help file too.</p></htmltext>
<tokenext>Don Knuth described Literate Programming in which the program is embedded in comments , one using a preprocessor to write the program .
The preprocessor runs as a command processor , using the source as a batch file .
One gets a properly sorted batch file as output .
Because of this , one can overcome limitations of the programming language , use pre-processor variables etc , and produce several linked files etc .
Documentation is relatively straight forward , since one writes what one wants to get , limitations , API and examples by way of a wish-list , and then create the routines that make this happen .
You can write a tight section like " File I/O " , for fileopen ( ) and fileclose ( ) along with getline ( ) , putline ( ) , etc , without exposing the filenames to all of the subroutines .
I 've written a program to write Web pages in it , for example , http : \ \ www.os2fan2.com \ pgloss \ index.html and its attendent pages .
It 's pretty elegant really .
The temptation of LP is to use it to solve a problem per source , a note that Jon Bentley ( Pearls of Programming ) noted .
LP is about sorting problems : however , the sort of problems that Knuth sought to solve are complete things in an educational setting , not bits of problems in the real world .
None the less , I use it to write terse batch files etc , where the LP source is the help file too .</tokentext>
<sentencetext>Don Knuth described Literate Programming in which the program is embedded in comments, one using a preprocessor to write the program.
The preprocessor runs as a command processor, using the source as a batch file.
One gets a properly sorted batch file as output.
Because of this, one can overcome limitations of the programming language, use pre-processor variables etc, and produce several linked files etc.
Documentation is relatively straight forward, since one writes what one wants to get, limitations, API and examples by way of a wish-list, and then create the routines that make this happen.
You can write a tight section like "File I/O", for fileopen() and fileclose() along with getline(), putline(),  etc, without exposing the filenames to all of the subroutines.
I've written a program to write Web pages in it, for example, http:\\www.os2fan2.com\pgloss\index.html and its attendent pages.
It's pretty elegant really.
The temptation of LP is to use it to solve a problem per source, a note that Jon Bentley (Pearls of Programming) noted.
LP is about sorting problems: however, the sort of problems that Knuth sought to solve are complete things in an educational setting, not bits of problems in the real world.
None the less, I use it to write terse batch files etc, where the LP source is the help file too.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617550</id>
	<title>Proper commenting</title>
	<author>elgee</author>
	<datestamp>1262352300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Proper commenting is a blessing, not a curse. But I have noticed over the years that many coders need to learn proper grammar and spelling.</p><p>&ldquo;This are a funktion to comput the valu of pie&rdquo;</p></htmltext>
<tokenext>Proper commenting is a blessing , not a curse .
But I have noticed over the years that many coders need to learn proper grammar and spelling.    This are a funktion to comput the valu of pie   </tokentext>
<sentencetext>Proper commenting is a blessing, not a curse.
But I have noticed over the years that many coders need to learn proper grammar and spelling.“This are a funktion to comput the valu of pie”</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618564</id>
	<title>Re:"would you rather use a one-liner"</title>
	<author>Anonymous</author>
	<datestamp>1262358300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>&gt; (OK, Lisp and APL are special cases, but really, when's the last time you wrote Lisp or APL, other than for fun?)</p><p>Yesterday.</p></htmltext>
<tokenext>&gt; ( OK , Lisp and APL are special cases , but really , when 's the last time you wrote Lisp or APL , other than for fun ?
) Yesterday .</tokentext>
<sentencetext>&gt; (OK, Lisp and APL are special cases, but really, when's the last time you wrote Lisp or APL, other than for fun?
)Yesterday.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616920</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618632</id>
	<title>Re:Strongly RESTRICT Code Commenting</title>
	<author>jhp64</author>
	<datestamp>1262358900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>There are just 3 good reasons for comments in code: (a) to refer to a published paper describing an (obscure) algorithm, eg '[fast graph traversal algorithm, M. M. Balakrishnarajan and P. Venuvanalingam<nobr> <wbr></nobr>,Computers &amp; Chemistry, Volume 19, Issue 2, June 1995, Pages 101-106] , (b) to indicate an arcane, obscure usage, which would be better eliminated, but sometimes cannot be eg in device drivers, when merely addressing a device register has side effects, (c) to very briefly document major parts of program flow-meaning, if this isn't otherwise obvious.</p></div><p>A fourth reason: if you use something like <a href="http://sphinx.pocoo.org/" title="pocoo.org" rel="nofollow">Sphinx</a> [pocoo.org] to autogenerate documentation from your code, then you should probably include at least a one-liner saying what each function or method does, and maybe you want to describe the parameters and the return values.  (If you're using a language like Python, then of course you don't have the types of the parameters or the return values in the function definition, so you should document them.)</p></div>
	</htmltext>
<tokenext>There are just 3 good reasons for comments in code : ( a ) to refer to a published paper describing an ( obscure ) algorithm , eg ' [ fast graph traversal algorithm , M. M. Balakrishnarajan and P. Venuvanalingam ,Computers &amp; Chemistry , Volume 19 , Issue 2 , June 1995 , Pages 101-106 ] , ( b ) to indicate an arcane , obscure usage , which would be better eliminated , but sometimes can not be eg in device drivers , when merely addressing a device register has side effects , ( c ) to very briefly document major parts of program flow-meaning , if this is n't otherwise obvious.A fourth reason : if you use something like Sphinx [ pocoo.org ] to autogenerate documentation from your code , then you should probably include at least a one-liner saying what each function or method does , and maybe you want to describe the parameters and the return values .
( If you 're using a language like Python , then of course you do n't have the types of the parameters or the return values in the function definition , so you should document them .
)</tokentext>
<sentencetext>There are just 3 good reasons for comments in code: (a) to refer to a published paper describing an (obscure) algorithm, eg '[fast graph traversal algorithm, M. M. Balakrishnarajan and P. Venuvanalingam ,Computers &amp; Chemistry, Volume 19, Issue 2, June 1995, Pages 101-106] , (b) to indicate an arcane, obscure usage, which would be better eliminated, but sometimes cannot be eg in device drivers, when merely addressing a device register has side effects, (c) to very briefly document major parts of program flow-meaning, if this isn't otherwise obvious.A fourth reason: if you use something like Sphinx [pocoo.org] to autogenerate documentation from your code, then you should probably include at least a one-liner saying what each function or method does, and maybe you want to describe the parameters and the return values.
(If you're using a language like Python, then of course you don't have the types of the parameters or the return values in the function definition, so you should document them.
)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617052</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621872</id>
	<title>Who???</title>
	<author>will\_die</author>
	<datestamp>1262444040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The only Jason Baker of note is a football(American) punter.<br>
So are the submitter and the author the same person and this is just a 15 seconds of fame?</htmltext>
<tokenext>The only Jason Baker of note is a football ( American ) punter .
So are the submitter and the author the same person and this is just a 15 seconds of fame ?</tokentext>
<sentencetext>The only Jason Baker of note is a football(American) punter.
So are the submitter and the author the same person and this is just a 15 seconds of fame?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30623770</id>
	<title>Myths about not commenting</title>
	<author>buzzn</author>
	<datestamp>1262456700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>
1) Comments have a cost ("When you update the code that the comment references, you usually have to update the comment as well")<br> <br>

Worst case, sure. But the future maintenance cost of having no comments, or wrong comments, is higher than the cost of no comments. For example, if you code to an interface, and the interface does not specify what it does, then you have to go look at how it's implemented, which takes a lot more time. You might then say, well if the interface is wrongly documented... but then you're begging the question. Interfaces are contracts, and contracts require precise definitions.<br> <br>

2) Comments make code less readable<br> <br>

Wrong comments make code less readable, sure. But take a simple example:<br> <br>

<tt>
insertPositionalMarker(context);
</tt> <br> <br>

Why does this routine get called? What happens if I change it? Contrast with:<br> <br>

<tt><nobr> <wbr></nobr>// this fixes defect 12345, by ensuring list order validity:<br>
insertPositionalMarker(list);
</tt> <br> <br>

Woohoo, now I know why it's there, and if I later need to understand the context, I can easily back reference to the original bug, and if I feel the need to make changes, I can regress the defect.<br> <br>

3) There is no need to document something that is obvious, and documenting same is a bad idea.<br> <br>

Maybe, if you are a genius and know (or want to frequently review) every line of code. In the real world, however, we call other people's modules, and we use context sensitive editors that hint a range of possible calls, including overloads. Which one do you pick and why? Does the call have side effects? A concise description of the interface contract is imperative for productivity. Not having documentation requires asking them, or wading through their code. Either one is a waste of time.<br> <br>

The fourth one in the article, code must always be self documenting, is correct, but trivial. Some code constructs are not obvious or readable, because they are complicated -- e.g. written by a domain expert.<br> <br>

The original article is fine for simplistic code bases, but doesn't work in the real world of high productivity, large scale applications. Anyone who doesn't comment their code is trading a small amount of their time for a large amount of everyone else's, and that's not scalable or efficient. In fact, it's just rude.</htmltext>
<tokenext>1 ) Comments have a cost ( " When you update the code that the comment references , you usually have to update the comment as well " ) Worst case , sure .
But the future maintenance cost of having no comments , or wrong comments , is higher than the cost of no comments .
For example , if you code to an interface , and the interface does not specify what it does , then you have to go look at how it 's implemented , which takes a lot more time .
You might then say , well if the interface is wrongly documented... but then you 're begging the question .
Interfaces are contracts , and contracts require precise definitions .
2 ) Comments make code less readable Wrong comments make code less readable , sure .
But take a simple example : insertPositionalMarker ( context ) ; Why does this routine get called ?
What happens if I change it ?
Contrast with : // this fixes defect 12345 , by ensuring list order validity : insertPositionalMarker ( list ) ; Woohoo , now I know why it 's there , and if I later need to understand the context , I can easily back reference to the original bug , and if I feel the need to make changes , I can regress the defect .
3 ) There is no need to document something that is obvious , and documenting same is a bad idea .
Maybe , if you are a genius and know ( or want to frequently review ) every line of code .
In the real world , however , we call other people 's modules , and we use context sensitive editors that hint a range of possible calls , including overloads .
Which one do you pick and why ?
Does the call have side effects ?
A concise description of the interface contract is imperative for productivity .
Not having documentation requires asking them , or wading through their code .
Either one is a waste of time .
The fourth one in the article , code must always be self documenting , is correct , but trivial .
Some code constructs are not obvious or readable , because they are complicated -- e.g .
written by a domain expert .
The original article is fine for simplistic code bases , but does n't work in the real world of high productivity , large scale applications .
Anyone who does n't comment their code is trading a small amount of their time for a large amount of everyone else 's , and that 's not scalable or efficient .
In fact , it 's just rude .</tokentext>
<sentencetext>
1) Comments have a cost ("When you update the code that the comment references, you usually have to update the comment as well") 

Worst case, sure.
But the future maintenance cost of having no comments, or wrong comments, is higher than the cost of no comments.
For example, if you code to an interface, and the interface does not specify what it does, then you have to go look at how it's implemented, which takes a lot more time.
You might then say, well if the interface is wrongly documented... but then you're begging the question.
Interfaces are contracts, and contracts require precise definitions.
2) Comments make code less readable 

Wrong comments make code less readable, sure.
But take a simple example: 


insertPositionalMarker(context);
  

Why does this routine get called?
What happens if I change it?
Contrast with: 

 // this fixes defect 12345, by ensuring list order validity:
insertPositionalMarker(list);
  

Woohoo, now I know why it's there, and if I later need to understand the context, I can easily back reference to the original bug, and if I feel the need to make changes, I can regress the defect.
3) There is no need to document something that is obvious, and documenting same is a bad idea.
Maybe, if you are a genius and know (or want to frequently review) every line of code.
In the real world, however, we call other people's modules, and we use context sensitive editors that hint a range of possible calls, including overloads.
Which one do you pick and why?
Does the call have side effects?
A concise description of the interface contract is imperative for productivity.
Not having documentation requires asking them, or wading through their code.
Either one is a waste of time.
The fourth one in the article, code must always be self documenting, is correct, but trivial.
Some code constructs are not obvious or readable, because they are complicated -- e.g.
written by a domain expert.
The original article is fine for simplistic code bases, but doesn't work in the real world of high productivity, large scale applications.
Anyone who doesn't comment their code is trading a small amount of their time for a large amount of everyone else's, and that's not scalable or efficient.
In fact, it's just rude.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622518</id>
	<title>Re:Please no</title>
	<author>Anonymous</author>
	<datestamp>1262449920000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>"Self-documenting code" is probably an oxymoron. Code is <i>how</i>. Comments should be <i>why</i>. And <i>what</i>.</p><p>Except in the most trivial and obvious cases, Code without comments is only half the program. Granted, it's the half that does the actual work, but if you want programs that are "write only", use APL. Or Perl.</p></htmltext>
<tokenext>" Self-documenting code " is probably an oxymoron .
Code is how .
Comments should be why .
And what.Except in the most trivial and obvious cases , Code without comments is only half the program .
Granted , it 's the half that does the actual work , but if you want programs that are " write only " , use APL .
Or Perl .</tokentext>
<sentencetext>"Self-documenting code" is probably an oxymoron.
Code is how.
Comments should be why.
And what.Except in the most trivial and obvious cases, Code without comments is only half the program.
Granted, it's the half that does the actual work, but if you want programs that are "write only", use APL.
Or Perl.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616836</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617588</id>
	<title>Re:Please no</title>
	<author>owlstead</author>
	<datestamp>1262352540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"(As an aside why is it in Uni that recursive code is held in such high regard as being elegant whereas in day to day like its almost always a bad idea. I made that mistake a few times early on in my professional life)."</p><p>Oh, that one is easy. Recursive code is a nice mathematical concept, used a lot in functional programming. As computer science more or less evolved from mathematics (and maybe physics) there is a lot of influence from those fields. You'll probably see it a lot less in studies for applied software engineering.</p><p>Yes, and it's something you *should* certainly avoid, even when the platform does not suffer easily from stack overflows. I normally try and replace it with a state machine (I think, nowadays recursive methods have somehow disappeared from all of my designs).</p></htmltext>
<tokenext>" ( As an aside why is it in Uni that recursive code is held in such high regard as being elegant whereas in day to day like its almost always a bad idea .
I made that mistake a few times early on in my professional life ) .
" Oh , that one is easy .
Recursive code is a nice mathematical concept , used a lot in functional programming .
As computer science more or less evolved from mathematics ( and maybe physics ) there is a lot of influence from those fields .
You 'll probably see it a lot less in studies for applied software engineering.Yes , and it 's something you * should * certainly avoid , even when the platform does not suffer easily from stack overflows .
I normally try and replace it with a state machine ( I think , nowadays recursive methods have somehow disappeared from all of my designs ) .</tokentext>
<sentencetext>"(As an aside why is it in Uni that recursive code is held in such high regard as being elegant whereas in day to day like its almost always a bad idea.
I made that mistake a few times early on in my professional life).
"Oh, that one is easy.
Recursive code is a nice mathematical concept, used a lot in functional programming.
As computer science more or less evolved from mathematics (and maybe physics) there is a lot of influence from those fields.
You'll probably see it a lot less in studies for applied software engineering.Yes, and it's something you *should* certainly avoid, even when the platform does not suffer easily from stack overflows.
I normally try and replace it with a state machine (I think, nowadays recursive methods have somehow disappeared from all of my designs).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617030</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618302</id>
	<title>Re:Not commenting is a sign of not thinking or car</title>
	<author>Anonymous</author>
	<datestamp>1262356500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>that's a whole lot of free-floating ad-hominum based on<br>the shaky generalization that every class or public method<br>needs a comment.</p></htmltext>
<tokenext>that 's a whole lot of free-floating ad-hominum based onthe shaky generalization that every class or public methodneeds a comment .</tokentext>
<sentencetext>that's a whole lot of free-floating ad-hominum based onthe shaky generalization that every class or public methodneeds a comment.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616936</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620650</id>
	<title>Both Sides</title>
	<author>Anonymous</author>
	<datestamp>1262425740000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I've worked on both ends of the spectrum.</p><p>In my first job out of college, the boss was an old school C programmer who was beyond hardcore about his coding standard. The code not only had to be commented (with a comment on EVERY SINGLE LINE), but also properly formatted. What's the difference between:</p><p>}//for numPoints</p><p>and</p><p>}<nobr> <wbr></nobr>// for numPoints</p><p>If you said, "Having the boss yell at you for five minutes." you win the prize. I'm not kidding or exaggerating.</p><p>-----</p><p>My current job is very lax. If the code works, it doesn't even matter if it's been run through an obfuscater.</p><p>Of course, if something is wrong with the site, then I (or my co-worker) better be able to fix it -- quickly.</p><p>So, either write it 100\% perfect the first time, or keep the non-obfuscated code around; keeping the site working as expected is the *only* thing that matters.</p><p>-----</p><p>As a software engineer, I prefer the rigor of the first. (I can do without the yelling, though.)<br>As a code monkey, I prefer the pragmatism of the second.</p><p>Maybe my next job will put me somewhere in the middle.</p></htmltext>
<tokenext>I 've worked on both ends of the spectrum.In my first job out of college , the boss was an old school C programmer who was beyond hardcore about his coding standard .
The code not only had to be commented ( with a comment on EVERY SINGLE LINE ) , but also properly formatted .
What 's the difference between : } //for numPointsand } // for numPointsIf you said , " Having the boss yell at you for five minutes .
" you win the prize .
I 'm not kidding or exaggerating.-----My current job is very lax .
If the code works , it does n't even matter if it 's been run through an obfuscater.Of course , if something is wrong with the site , then I ( or my co-worker ) better be able to fix it -- quickly.So , either write it 100 \ % perfect the first time , or keep the non-obfuscated code around ; keeping the site working as expected is the * only * thing that matters.-----As a software engineer , I prefer the rigor of the first .
( I can do without the yelling , though .
) As a code monkey , I prefer the pragmatism of the second.Maybe my next job will put me somewhere in the middle .</tokentext>
<sentencetext>I've worked on both ends of the spectrum.In my first job out of college, the boss was an old school C programmer who was beyond hardcore about his coding standard.
The code not only had to be commented (with a comment on EVERY SINGLE LINE), but also properly formatted.
What's the difference between:}//for numPointsand} // for numPointsIf you said, "Having the boss yell at you for five minutes.
" you win the prize.
I'm not kidding or exaggerating.-----My current job is very lax.
If the code works, it doesn't even matter if it's been run through an obfuscater.Of course, if something is wrong with the site, then I (or my co-worker) better be able to fix it -- quickly.So, either write it 100\% perfect the first time, or keep the non-obfuscated code around; keeping the site working as expected is the *only* thing that matters.-----As a software engineer, I prefer the rigor of the first.
(I can do without the yelling, though.
)As a code monkey, I prefer the pragmatism of the second.Maybe my next job will put me somewhere in the middle.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619350</id>
	<title>The Elements of Programming Style</title>
	<author>ajcarr</author>
	<datestamp>1262365680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>For heaven's sake, just read:</p><p>Kernighan, B. W. and Plauger P. J. (1978) The Elements of Programming Style, 2nd edn. McGraw-Hill</p><p>They deal with commenting and its pitfalls perfectly adequately.</p></htmltext>
<tokenext>For heaven 's sake , just read : Kernighan , B. W. and Plauger P. J. ( 1978 ) The Elements of Programming Style , 2nd edn .
McGraw-HillThey deal with commenting and its pitfalls perfectly adequately .</tokentext>
<sentencetext>For heaven's sake, just read:Kernighan, B. W. and Plauger P. J. (1978) The Elements of Programming Style, 2nd edn.
McGraw-HillThey deal with commenting and its pitfalls perfectly adequately.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622912</id>
	<title>"Comments make code more readable" - Myth?</title>
	<author>Assmasher</author>
	<datestamp>1262452200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'm sorry, but that's not a myth.  I'm sure, like all things, it depends upon time and place, but I assure you that the scanline hidden surface removal code I recently wrote that uses a span based methodology is entirely dependent upon good commenting so that debugging can involve someone other than myself.  There aren't many software rendering specialists out there anymore.  My code has excellent naming conventions, is organized clearly, but if you don't understand all the factors involved it would be laborious even for myself to debug this a year from now.  Documenting the edge cases, the oddities, the factors other design decisions elsewhere in the system have made to impact choices in this code, it critically important.</p><p>Hopefully it is commented thoroughly enough that someone reasonably proficient in Java and 3D could understand why things work they way they do.  All of this is, of course, also included in a design overview document for this aspect of the system, but documents like that tend to get lost as time goes by.  Documenting in the code why exactly we, for example, interpolate colors the way we do and then clamp them to an applicable range in critical to avoid someone messing up overbright lighting.</p><p>Now, of course, this need doesn't apply in all scenarios.  I don't heavily comment the model loader's methods (although they are well commented) to explain how we manage endian-ness and why, although I do mention to beware of this issue, but that's because in 3D this is a fairly common thing to have to support; ergo, I expect a developer with 3D experience to understand basic issues with modeling formats (if not the specifics of a particular format.)</p></htmltext>
<tokenext>I 'm sorry , but that 's not a myth .
I 'm sure , like all things , it depends upon time and place , but I assure you that the scanline hidden surface removal code I recently wrote that uses a span based methodology is entirely dependent upon good commenting so that debugging can involve someone other than myself .
There are n't many software rendering specialists out there anymore .
My code has excellent naming conventions , is organized clearly , but if you do n't understand all the factors involved it would be laborious even for myself to debug this a year from now .
Documenting the edge cases , the oddities , the factors other design decisions elsewhere in the system have made to impact choices in this code , it critically important.Hopefully it is commented thoroughly enough that someone reasonably proficient in Java and 3D could understand why things work they way they do .
All of this is , of course , also included in a design overview document for this aspect of the system , but documents like that tend to get lost as time goes by .
Documenting in the code why exactly we , for example , interpolate colors the way we do and then clamp them to an applicable range in critical to avoid someone messing up overbright lighting.Now , of course , this need does n't apply in all scenarios .
I do n't heavily comment the model loader 's methods ( although they are well commented ) to explain how we manage endian-ness and why , although I do mention to beware of this issue , but that 's because in 3D this is a fairly common thing to have to support ; ergo , I expect a developer with 3D experience to understand basic issues with modeling formats ( if not the specifics of a particular format .
)</tokentext>
<sentencetext>I'm sorry, but that's not a myth.
I'm sure, like all things, it depends upon time and place, but I assure you that the scanline hidden surface removal code I recently wrote that uses a span based methodology is entirely dependent upon good commenting so that debugging can involve someone other than myself.
There aren't many software rendering specialists out there anymore.
My code has excellent naming conventions, is organized clearly, but if you don't understand all the factors involved it would be laborious even for myself to debug this a year from now.
Documenting the edge cases, the oddities, the factors other design decisions elsewhere in the system have made to impact choices in this code, it critically important.Hopefully it is commented thoroughly enough that someone reasonably proficient in Java and 3D could understand why things work they way they do.
All of this is, of course, also included in a design overview document for this aspect of the system, but documents like that tend to get lost as time goes by.
Documenting in the code why exactly we, for example, interpolate colors the way we do and then clamp them to an applicable range in critical to avoid someone messing up overbright lighting.Now, of course, this need doesn't apply in all scenarios.
I don't heavily comment the model loader's methods (although they are well commented) to explain how we manage endian-ness and why, although I do mention to beware of this issue, but that's because in 3D this is a fairly common thing to have to support; ergo, I expect a developer with 3D experience to understand basic issues with modeling formats (if not the specifics of a particular format.
)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617402</id>
	<title>Re:Has No One Actually Studied This?</title>
	<author>jbolden</author>
	<datestamp>1262351160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Actually there have been tests.  The problem they are very specific to platform / language / development techniques in vogue.   For example the whole hungarian variables debates from 20 years ago.</p></htmltext>
<tokenext>Actually there have been tests .
The problem they are very specific to platform / language / development techniques in vogue .
For example the whole hungarian variables debates from 20 years ago .</tokentext>
<sentencetext>Actually there have been tests.
The problem they are very specific to platform / language / development techniques in vogue.
For example the whole hungarian variables debates from 20 years ago.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619530</id>
	<title>has anybody noticed...</title>
	<author>Anonymous</author>
	<datestamp>1262367840000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>that the people against commenting sound like they've worked in environments where they were forced to write comments</p><p>and the pro commenting people sound like they've been struggling through some poorly commented and hard to read stuff.</p><p>It's about balance.<br>Some comments help a lot to make code more intelligible.<br>Some is pointless noise.(ie<nobr> <wbr></nobr>//increment x)<br>A lot would not be necessary at all if the code was sensibly structured, with good variable names</p></htmltext>
<tokenext>that the people against commenting sound like they 've worked in environments where they were forced to write commentsand the pro commenting people sound like they 've been struggling through some poorly commented and hard to read stuff.It 's about balance.Some comments help a lot to make code more intelligible.Some is pointless noise .
( ie //increment x ) A lot would not be necessary at all if the code was sensibly structured , with good variable names</tokentext>
<sentencetext>that the people against commenting sound like they've worked in environments where they were forced to write commentsand the pro commenting people sound like they've been struggling through some poorly commented and hard to read stuff.It's about balance.Some comments help a lot to make code more intelligible.Some is pointless noise.
(ie //increment x)A lot would not be necessary at all if the code was sensibly structured, with good variable names</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620922</id>
	<title>Re:Please no</title>
	<author>Anonymous</author>
	<datestamp>1262430240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><i>masquerade as pieces of modularly reusable code</i></p><p>Where in fuck's name did you get the encephalitic idea that something being a function necessarily implies that it is reusable?!?</p></htmltext>
<tokenext>masquerade as pieces of modularly reusable codeWhere in fuck 's name did you get the encephalitic idea that something being a function necessarily implies that it is reusable ? !
?</tokentext>
<sentencetext>masquerade as pieces of modularly reusable codeWhere in fuck's name did you get the encephalitic idea that something being a function necessarily implies that it is reusable?!
?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617030</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30628308</id>
	<title>In reality, comments are secondary...</title>
	<author>Turzyx</author>
	<datestamp>1262442660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>... to the primary objective of getting the program working. Okay, okay, perhaps not... However, trying to construct coherent descriptions and code analysis during a 2am coffee-fuelled session usually results in the babble people complain about. I don't think I've ever opened up source code to see everything perfectly explained, and to be honest, it doesn't need to be.<br> <br>
To me, the most useful comments are usually the ones that give a brief explanation of the objective (of that section of code). Any developer worth his salt can figure out what has been hacked together to achieve said objective. Having text blocks littering the page is just useless unless the original developer was a world class author.</htmltext>
<tokenext>... to the primary objective of getting the program working .
Okay , okay , perhaps not... However , trying to construct coherent descriptions and code analysis during a 2am coffee-fuelled session usually results in the babble people complain about .
I do n't think I 've ever opened up source code to see everything perfectly explained , and to be honest , it does n't need to be .
To me , the most useful comments are usually the ones that give a brief explanation of the objective ( of that section of code ) .
Any developer worth his salt can figure out what has been hacked together to achieve said objective .
Having text blocks littering the page is just useless unless the original developer was a world class author .</tokentext>
<sentencetext>... to the primary objective of getting the program working.
Okay, okay, perhaps not... However, trying to construct coherent descriptions and code analysis during a 2am coffee-fuelled session usually results in the babble people complain about.
I don't think I've ever opened up source code to see everything perfectly explained, and to be honest, it doesn't need to be.
To me, the most useful comments are usually the ones that give a brief explanation of the objective (of that section of code).
Any developer worth his salt can figure out what has been hacked together to achieve said objective.
Having text blocks littering the page is just useless unless the original developer was a world class author.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617512</id>
	<title>Why?</title>
	<author>Anonymous</author>
	<datestamp>1262352060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Because expressing an algorithm recursively provides A LOT of clarity when the operation is in fact recursive. A proper language (like Scheme) that implements proper tail recursion this works really well. For other languages, its a fail due to the inability of the system to perform the calculation in constant space (due to pushing stack frames). That being said, most languages (including C, C++, Java) *could* be made to do proper tail recursion, then that wouldn't be an issue and you would be able to have the clarity of expressing a recursively solved problem with a recursive algorithm. Blame the problem on poorly written compilers and poorly implemented languages.</htmltext>
<tokenext>Because expressing an algorithm recursively provides A LOT of clarity when the operation is in fact recursive .
A proper language ( like Scheme ) that implements proper tail recursion this works really well .
For other languages , its a fail due to the inability of the system to perform the calculation in constant space ( due to pushing stack frames ) .
That being said , most languages ( including C , C + + , Java ) * could * be made to do proper tail recursion , then that would n't be an issue and you would be able to have the clarity of expressing a recursively solved problem with a recursive algorithm .
Blame the problem on poorly written compilers and poorly implemented languages .</tokentext>
<sentencetext>Because expressing an algorithm recursively provides A LOT of clarity when the operation is in fact recursive.
A proper language (like Scheme) that implements proper tail recursion this works really well.
For other languages, its a fail due to the inability of the system to perform the calculation in constant space (due to pushing stack frames).
That being said, most languages (including C, C++, Java) *could* be made to do proper tail recursion, then that wouldn't be an issue and you would be able to have the clarity of expressing a recursively solved problem with a recursive algorithm.
Blame the problem on poorly written compilers and poorly implemented languages.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617030</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617022</id>
	<title>Re:In other news...</title>
	<author>Anonymous</author>
	<datestamp>1262348160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>undocumented code is unprofessional.</p><p>unprofessionals dont get hired often or keep their jobs for long.</p><p>if you work for me, you document your code, cause unless specifically agreed to beforehand, your code is part of a product belonging to my company, and i will not be screwed over down the road cause you left, and the code is nigh undecipherable except by the one who wrote it.</p></htmltext>
<tokenext>undocumented code is unprofessional.unprofessionals dont get hired often or keep their jobs for long.if you work for me , you document your code , cause unless specifically agreed to beforehand , your code is part of a product belonging to my company , and i will not be screwed over down the road cause you left , and the code is nigh undecipherable except by the one who wrote it .</tokentext>
<sentencetext>undocumented code is unprofessional.unprofessionals dont get hired often or keep their jobs for long.if you work for me, you document your code, cause unless specifically agreed to beforehand, your code is part of a product belonging to my company, and i will not be screwed over down the road cause you left, and the code is nigh undecipherable except by the one who wrote it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616776</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616846</id>
	<title>Re:Wrong on all accounts</title>
	<author>tomhath</author>
	<datestamp>1262346780000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p><div class="quote"><p>Wrong on all accounts</p></div><p>RTFA, the article starts out with these two sentences:</p><p><div class="quote"><p>It seems to me getting good at writing comments is an under-appreciated part of a Programmer's development. However, I feel that this is a part of programming that's almost as important as writing code itself.</p></div><p>His point is that worthless comments are worse than no comments at all. Unfortunately a large percentage of the comments you see in code today were autogenerated by the IDE and are just noise.</p></div>
	</htmltext>
<tokenext>Wrong on all accountsRTFA , the article starts out with these two sentences : It seems to me getting good at writing comments is an under-appreciated part of a Programmer 's development .
However , I feel that this is a part of programming that 's almost as important as writing code itself.His point is that worthless comments are worse than no comments at all .
Unfortunately a large percentage of the comments you see in code today were autogenerated by the IDE and are just noise .</tokentext>
<sentencetext>Wrong on all accountsRTFA, the article starts out with these two sentences:It seems to me getting good at writing comments is an under-appreciated part of a Programmer's development.
However, I feel that this is a part of programming that's almost as important as writing code itself.His point is that worthless comments are worse than no comments at all.
Unfortunately a large percentage of the comments you see in code today were autogenerated by the IDE and are just noise.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617218</id>
	<title>Don't listen to this crap</title>
	<author>MacGyver2210</author>
	<datestamp>1262349720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>FTA: "If anything, comments make code less readable. Nine times out of ten, I ignore comments unless I'm stumped. In fact, I'm tempted to make emacs hide all comments unless I explicitly expand them."<p>

I stopped reading at this point, because the author is clearly a terrible programmer and not someone I want to take coding/commenting advice from. If you do comments right, which this guy clearly doesn't, they can save your ass repeatedly and avoid having to go to deeper, harder-to-reach documentation to make it work. Clearly not someone with any real programming experience behind this 'article' (although it looks more like a twitter feed).</p></htmltext>
<tokenext>FTA : " If anything , comments make code less readable .
Nine times out of ten , I ignore comments unless I 'm stumped .
In fact , I 'm tempted to make emacs hide all comments unless I explicitly expand them .
" I stopped reading at this point , because the author is clearly a terrible programmer and not someone I want to take coding/commenting advice from .
If you do comments right , which this guy clearly does n't , they can save your ass repeatedly and avoid having to go to deeper , harder-to-reach documentation to make it work .
Clearly not someone with any real programming experience behind this 'article ' ( although it looks more like a twitter feed ) .</tokentext>
<sentencetext>FTA: "If anything, comments make code less readable.
Nine times out of ten, I ignore comments unless I'm stumped.
In fact, I'm tempted to make emacs hide all comments unless I explicitly expand them.
"

I stopped reading at this point, because the author is clearly a terrible programmer and not someone I want to take coding/commenting advice from.
If you do comments right, which this guy clearly doesn't, they can save your ass repeatedly and avoid having to go to deeper, harder-to-reach documentation to make it work.
Clearly not someone with any real programming experience behind this 'article' (although it looks more like a twitter feed).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621336</id>
	<title>Code review failed.  Please resubmit</title>
	<author>baileydau</author>
	<datestamp>1262436540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Every line should be commented, like:<nobr> <wbr></nobr>// Declare function called doit with one int param that returns an int<br>int doit(int i)<nobr> <wbr></nobr>// See above comment<br>{<nobr> <wbr></nobr>// The function's open brace. I like to put braces on their own line. You should too!! BTW, this is C code, so braces are totally the way to go.</p><p>
&nbsp; &nbsp; &nbsp; if(i == 0)<nobr> <wbr></nobr>// Check if i is 0. You know, in C, "==" is the way to compare values, unlike in VB where you use a single "=". Just thought u should know.</p><p>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return 0;<nobr> <wbr></nobr>// Return 0. That is, all the bits of the return value are 0. We could also return i, because i is 0, too. That is, all the bits of i are 0. On a 32 bit system, there would be, like, 32 0's.</p><p>
&nbsp; &nbsp; &nbsp; else<nobr> <wbr></nobr>// &lt;-- But you forgot to comment the meaning of this line!!!  Please redo and resubmit to code review</p><p>
&nbsp; &nbsp; &nbsp; {<nobr> <wbr></nobr>// Begin an if block using a brace (this is C syntax!!!)</p><p>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; int j = i - 1;<nobr> <wbr></nobr>// Declare an int variable named j that is one less than i</p><p>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return i + doit(j);<nobr> <wbr></nobr>// Return the sum of i and the value of calling doit with j</p><p>
&nbsp; &nbsp; &nbsp; }<nobr> <wbr></nobr>// Finish the if block with a C close brace. By the way, we could have written the above code as return i + doit(i - 1) without using the braces.<br>}<nobr> <wbr></nobr>// The function's close brace.</p><p>There! Now that is both way readable and informative. Anything less would just not pass my code review.</p></div></div>
	</htmltext>
<tokenext>Every line should be commented , like : // Declare function called doit with one int param that returns an intint doit ( int i ) // See above comment { // The function 's open brace .
I like to put braces on their own line .
You should too ! !
BTW , this is C code , so braces are totally the way to go .
      if ( i = = 0 ) // Check if i is 0 .
You know , in C , " = = " is the way to compare values , unlike in VB where you use a single " = " .
Just thought u should know .
            return 0 ; // Return 0 .
That is , all the bits of the return value are 0 .
We could also return i , because i is 0 , too .
That is , all the bits of i are 0 .
On a 32 bit system , there would be , like , 32 0 's .
      else //       { // Begin an if block using a brace ( this is C syntax ! ! !
)             int j = i - 1 ; // Declare an int variable named j that is one less than i             return i + doit ( j ) ; // Return the sum of i and the value of calling doit with j       } // Finish the if block with a C close brace .
By the way , we could have written the above code as return i + doit ( i - 1 ) without using the braces .
} // The function 's close brace.There !
Now that is both way readable and informative .
Anything less would just not pass my code review .</tokentext>
<sentencetext>Every line should be commented, like: // Declare function called doit with one int param that returns an intint doit(int i) // See above comment{ // The function's open brace.
I like to put braces on their own line.
You should too!!
BTW, this is C code, so braces are totally the way to go.
      if(i == 0) // Check if i is 0.
You know, in C, "==" is the way to compare values, unlike in VB where you use a single "=".
Just thought u should know.
            return 0; // Return 0.
That is, all the bits of the return value are 0.
We could also return i, because i is 0, too.
That is, all the bits of i are 0.
On a 32 bit system, there would be, like, 32 0's.
      else // 
      { // Begin an if block using a brace (this is C syntax!!!
)
            int j = i - 1; // Declare an int variable named j that is one less than i
            return i + doit(j); // Return the sum of i and the value of calling doit with j
      } // Finish the if block with a C close brace.
By the way, we could have written the above code as return i + doit(i - 1) without using the braces.
} // The function's close brace.There!
Now that is both way readable and informative.
Anything less would just not pass my code review.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617182</id>
	<title>Re:Please no</title>
	<author>farnsworth</author>
	<datestamp>1262349420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Christ, I know everyone has their own personal style and everything, but this is just pernicious.</p></div><p>
Every is entitled to their own personal style, but context is also very important.
</p><p>
If you are writing a math-heavy algorithm in c, comments are crucial, both at the API level and within the implementation.
</p><p>
On the other hand, if you are writing a webapp in c#, an organizational mandate to "document every public method and public class" can be a huge waste of time if not harmful.</p></div>
	</htmltext>
<tokenext>Christ , I know everyone has their own personal style and everything , but this is just pernicious .
Every is entitled to their own personal style , but context is also very important .
If you are writing a math-heavy algorithm in c , comments are crucial , both at the API level and within the implementation .
On the other hand , if you are writing a webapp in c # , an organizational mandate to " document every public method and public class " can be a huge waste of time if not harmful .</tokentext>
<sentencetext>Christ, I know everyone has their own personal style and everything, but this is just pernicious.
Every is entitled to their own personal style, but context is also very important.
If you are writing a math-heavy algorithm in c, comments are crucial, both at the API level and within the implementation.
On the other hand, if you are writing a webapp in c#, an organizational mandate to "document every public method and public class" can be a huge waste of time if not harmful.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616836</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617984</id>
	<title>Comment first</title>
	<author>MrKaos</author>
	<datestamp>1262354820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I actually comment the main parts of my code before I write the code. Reason being is I like to get the general layout of the code down first and then add further comments as I go along to explain my reasoning *to me*. </p><p>
I don't know how long it's going to be before I come back to a piece of code and nothing annoys me more than having mental clutter in my mind. I don't want to have to *remember* what why or how certain bit of code does what it does. I just want to pull up my code and explain it to myself and say "thanks me of the past for considering me today". Coders that don't explain what they are doing in their code are just hard to work with.</p><p>
Well commented code helps code look beautiful and flow like poetry. When you look at code you can see almost immediately if it is going to be painful to modify. I try to put as much back onto the machine as I can, like using database design tools so I don't have to keep stuff in my mind. </p><p>
I use Nassi-Shneiderman mixed with pseudo-code on paper to do a design (I'm getting better at UML tools - so soon I hope to upgrade this part of my coding practise) and when I'm happy with that I move to comment before writing the actual functional parts of code, increasing the detail of the comments as I go along. I used to be shy about my code but now I'd be embarrassed if I didn't comment my code - because it's not polite to my colleagues. Comments mean I don't have to waste time trying to remember where I was up to as it's simple for me to compare it with my design and away I go.</p></htmltext>
<tokenext>I actually comment the main parts of my code before I write the code .
Reason being is I like to get the general layout of the code down first and then add further comments as I go along to explain my reasoning * to me * .
I do n't know how long it 's going to be before I come back to a piece of code and nothing annoys me more than having mental clutter in my mind .
I do n't want to have to * remember * what why or how certain bit of code does what it does .
I just want to pull up my code and explain it to myself and say " thanks me of the past for considering me today " .
Coders that do n't explain what they are doing in their code are just hard to work with .
Well commented code helps code look beautiful and flow like poetry .
When you look at code you can see almost immediately if it is going to be painful to modify .
I try to put as much back onto the machine as I can , like using database design tools so I do n't have to keep stuff in my mind .
I use Nassi-Shneiderman mixed with pseudo-code on paper to do a design ( I 'm getting better at UML tools - so soon I hope to upgrade this part of my coding practise ) and when I 'm happy with that I move to comment before writing the actual functional parts of code , increasing the detail of the comments as I go along .
I used to be shy about my code but now I 'd be embarrassed if I did n't comment my code - because it 's not polite to my colleagues .
Comments mean I do n't have to waste time trying to remember where I was up to as it 's simple for me to compare it with my design and away I go .</tokentext>
<sentencetext>I actually comment the main parts of my code before I write the code.
Reason being is I like to get the general layout of the code down first and then add further comments as I go along to explain my reasoning *to me*.
I don't know how long it's going to be before I come back to a piece of code and nothing annoys me more than having mental clutter in my mind.
I don't want to have to *remember* what why or how certain bit of code does what it does.
I just want to pull up my code and explain it to myself and say "thanks me of the past for considering me today".
Coders that don't explain what they are doing in their code are just hard to work with.
Well commented code helps code look beautiful and flow like poetry.
When you look at code you can see almost immediately if it is going to be painful to modify.
I try to put as much back onto the machine as I can, like using database design tools so I don't have to keep stuff in my mind.
I use Nassi-Shneiderman mixed with pseudo-code on paper to do a design (I'm getting better at UML tools - so soon I hope to upgrade this part of my coding practise) and when I'm happy with that I move to comment before writing the actual functional parts of code, increasing the detail of the comments as I go along.
I used to be shy about my code but now I'd be embarrassed if I didn't comment my code - because it's not polite to my colleagues.
Comments mean I don't have to waste time trying to remember where I was up to as it's simple for me to compare it with my design and away I go.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616832</id>
	<title>Re:Wrong on all accounts</title>
	<author>TheRaven64</author>
	<datestamp>1262346720000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p><div class="quote"><p> Your code is not as
good as you think it is</p></div><p>Even if it is, the person reading it might not be as good a developer as you, or may be as good (or better) but with different experiences.  In both cases, they may not be able to read and understand your good code without comments.  When they change it and it breaks as a result, then it's your fault.</p></div>
	</htmltext>
<tokenext>Your code is not as good as you think it isEven if it is , the person reading it might not be as good a developer as you , or may be as good ( or better ) but with different experiences .
In both cases , they may not be able to read and understand your good code without comments .
When they change it and it breaks as a result , then it 's your fault .</tokentext>
<sentencetext> Your code is not as
good as you think it isEven if it is, the person reading it might not be as good a developer as you, or may be as good (or better) but with different experiences.
In both cases, they may not be able to read and understand your good code without comments.
When they change it and it breaks as a result, then it's your fault.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617282</id>
	<title>Experience</title>
	<author>GrahamCox</author>
	<datestamp>1262350200000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>Experience shows how much you need to comment and what the comments worth writing consist of, just as experience tells you how to structure the code in the first place. "Rules" about commenting are perhaps useful starting points for the inexperienced, but with experience you can write your own rules.</htmltext>
<tokenext>Experience shows how much you need to comment and what the comments worth writing consist of , just as experience tells you how to structure the code in the first place .
" Rules " about commenting are perhaps useful starting points for the inexperienced , but with experience you can write your own rules .</tokentext>
<sentencetext>Experience shows how much you need to comment and what the comments worth writing consist of, just as experience tells you how to structure the code in the first place.
"Rules" about commenting are perhaps useful starting points for the inexperienced, but with experience you can write your own rules.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30626992</id>
	<title>Think of the guy reading it.</title>
	<author>Dark$ide</author>
	<datestamp>1262432820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The whole nature of the comments in code is to explain why the result that the code creates or the function returns isn't as simple as you'd expect when you first look at the code. If there's nothing strange in the code, don't bother with the comment. If the code uses some funky technique explain in a concise way why you've written it that way and not used a possibly more obvious method.<p>Too many folks create "write only" code that isn't worth debugging when it goes wrong and the better way to cure the bug is a rewrite. In those cases the comments are essential to avoid the need for the next guy maintaining the code to have to re-analyse the problem and rewrite.</p><p>It gets worse when you add complexity. One thing guaranteed to make code unreadable is when folks create SQL statements with hundreds of predicates and tens of joined tables.</p><p>1st simple rule is trust the code not the comments.</p><p>2nd simple rule is don't comment the obvious.</p></htmltext>
<tokenext>The whole nature of the comments in code is to explain why the result that the code creates or the function returns is n't as simple as you 'd expect when you first look at the code .
If there 's nothing strange in the code , do n't bother with the comment .
If the code uses some funky technique explain in a concise way why you 've written it that way and not used a possibly more obvious method.Too many folks create " write only " code that is n't worth debugging when it goes wrong and the better way to cure the bug is a rewrite .
In those cases the comments are essential to avoid the need for the next guy maintaining the code to have to re-analyse the problem and rewrite.It gets worse when you add complexity .
One thing guaranteed to make code unreadable is when folks create SQL statements with hundreds of predicates and tens of joined tables.1st simple rule is trust the code not the comments.2nd simple rule is do n't comment the obvious .</tokentext>
<sentencetext>The whole nature of the comments in code is to explain why the result that the code creates or the function returns isn't as simple as you'd expect when you first look at the code.
If there's nothing strange in the code, don't bother with the comment.
If the code uses some funky technique explain in a concise way why you've written it that way and not used a possibly more obvious method.Too many folks create "write only" code that isn't worth debugging when it goes wrong and the better way to cure the bug is a rewrite.
In those cases the comments are essential to avoid the need for the next guy maintaining the code to have to re-analyse the problem and rewrite.It gets worse when you add complexity.
One thing guaranteed to make code unreadable is when folks create SQL statements with hundreds of predicates and tens of joined tables.1st simple rule is trust the code not the comments.2nd simple rule is don't comment the obvious.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621404</id>
	<title>Re:In other news...</title>
	<author>Anonymous</author>
	<datestamp>1262437500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>People hate Stephen King? News.</p></htmltext>
<tokenext>People hate Stephen King ?
News .</tokentext>
<sentencetext>People hate Stephen King?
News.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616776</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30624008</id>
	<title>Re:More verbose == less readable?</title>
	<author>ninjagin</author>
	<datestamp>1262457900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I used to do a lot of sh/ksh/perl scripting, and once I developed a little facility with sed and awk and regular expressions (not to mention 'eval', my all-time fave ksh function), I found that commenting these kinds of filters and parsing tricks was very helpful as I looked back at what I was doing. Keeping things short and sweet and efficient (if need be) is great, no question. Being able to hand what I wrote to someone else, or being able to revisit something years later and make sense of something without having to pick up a book to re-acquaint myself with the syntax rules, was a real time-saver. I'm a manager, now, but every now and again the guys on my team show me things I wrote and tell me how helpful those little notes were.</htmltext>
<tokenext>I used to do a lot of sh/ksh/perl scripting , and once I developed a little facility with sed and awk and regular expressions ( not to mention 'eval ' , my all-time fave ksh function ) , I found that commenting these kinds of filters and parsing tricks was very helpful as I looked back at what I was doing .
Keeping things short and sweet and efficient ( if need be ) is great , no question .
Being able to hand what I wrote to someone else , or being able to revisit something years later and make sense of something without having to pick up a book to re-acquaint myself with the syntax rules , was a real time-saver .
I 'm a manager , now , but every now and again the guys on my team show me things I wrote and tell me how helpful those little notes were .</tokentext>
<sentencetext>I used to do a lot of sh/ksh/perl scripting, and once I developed a little facility with sed and awk and regular expressions (not to mention 'eval', my all-time fave ksh function), I found that commenting these kinds of filters and parsing tricks was very helpful as I looked back at what I was doing.
Keeping things short and sweet and efficient (if need be) is great, no question.
Being able to hand what I wrote to someone else, or being able to revisit something years later and make sense of something without having to pick up a book to re-acquaint myself with the syntax rules, was a real time-saver.
I'm a manager, now, but every now and again the guys on my team show me things I wrote and tell me how helpful those little notes were.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617308</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620330</id>
	<title>Doxygen rules</title>
	<author>Anonymous</author>
	<datestamp>1262464800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>We have to meet formal documentation requirements. (FIPS 140-2, Common Criteria).<br>Doxygen makes that a breeze - the documentation in the source isn't particularly readable (but not useless either), being able to annotate the sources and produce the documentation you have to have with the push of a button is great.</p><p>It has improved code quality and found a few bugs as well, but that's a long term gain not short term  -i.e. if the call tree's look like spaghetti it's probably clean up time.</p><p>All in all - taking the long view (several years), it's been a massive gain. Short term, it's a looser - it eats time putting good docs in place - so for most software companies - where "push it out the door" seems to be the rule, you aren't going to be winning.</p></htmltext>
<tokenext>We have to meet formal documentation requirements .
( FIPS 140-2 , Common Criteria ) .Doxygen makes that a breeze - the documentation in the source is n't particularly readable ( but not useless either ) , being able to annotate the sources and produce the documentation you have to have with the push of a button is great.It has improved code quality and found a few bugs as well , but that 's a long term gain not short term -i.e .
if the call tree 's look like spaghetti it 's probably clean up time.All in all - taking the long view ( several years ) , it 's been a massive gain .
Short term , it 's a looser - it eats time putting good docs in place - so for most software companies - where " push it out the door " seems to be the rule , you are n't going to be winning .</tokentext>
<sentencetext>We have to meet formal documentation requirements.
(FIPS 140-2, Common Criteria).Doxygen makes that a breeze - the documentation in the source isn't particularly readable (but not useless either), being able to annotate the sources and produce the documentation you have to have with the push of a button is great.It has improved code quality and found a few bugs as well, but that's a long term gain not short term  -i.e.
if the call tree's look like spaghetti it's probably clean up time.All in all - taking the long view (several years), it's been a massive gain.
Short term, it's a looser - it eats time putting good docs in place - so for most software companies - where "push it out the door" seems to be the rule, you aren't going to be winning.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622408</id>
	<title>Only a neophyte would post this drivil</title>
	<author>bwanagary</author>
	<datestamp>1262449020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Well, all I can say is that "Empty vessels make the most noise."</p></htmltext>
<tokenext>Well , all I can say is that " Empty vessels make the most noise .
"</tokentext>
<sentencetext>Well, all I can say is that "Empty vessels make the most noise.
"</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617192</id>
	<title>Knuth</title>
	<author>SEWilco</author>
	<datestamp>1262349480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I believe that Knuth had volumes to say about code and documentation.</htmltext>
<tokenext>I believe that Knuth had volumes to say about code and documentation .</tokentext>
<sentencetext>I believe that Knuth had volumes to say about code and documentation.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621720</id>
	<title>Re:every line of code should be commented</title>
	<author>mehrotra.akash</author>
	<datestamp>1262442480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>somehow all my C/C++ books are written like this</p></htmltext>
<tokenext>somehow all my C/C + + books are written like this</tokentext>
<sentencetext>somehow all my C/C++ books are written like this</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621470</id>
	<title>Self documenting code</title>
	<author>Anonymous</author>
	<datestamp>1262438760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Self documenting code is a desirable side effect of a clean coding practice that has something more in mind. Writing very 'verbose' code is like drawing a precise picture of the analysis of the problem the code is supposed to solve. It 'tells you a story' of divide and conquer. This serves you so much when it comes to bug fixing or more important: bug preventing. And it gives you an extra level of reflecting about what you're actually doing.</p><p>To many programmers such a discipline may seem like talking to little children and explaining each and every bit of obvious information. I had the experience to get bad grades in my math tests because i thought myself to have good memorizing abilities so i preferred not to note too much intermediate results. That's where I discovered my psychology of introducing bugs.</p></htmltext>
<tokenext>Self documenting code is a desirable side effect of a clean coding practice that has something more in mind .
Writing very 'verbose ' code is like drawing a precise picture of the analysis of the problem the code is supposed to solve .
It 'tells you a story ' of divide and conquer .
This serves you so much when it comes to bug fixing or more important : bug preventing .
And it gives you an extra level of reflecting about what you 're actually doing.To many programmers such a discipline may seem like talking to little children and explaining each and every bit of obvious information .
I had the experience to get bad grades in my math tests because i thought myself to have good memorizing abilities so i preferred not to note too much intermediate results .
That 's where I discovered my psychology of introducing bugs .</tokentext>
<sentencetext>Self documenting code is a desirable side effect of a clean coding practice that has something more in mind.
Writing very 'verbose' code is like drawing a precise picture of the analysis of the problem the code is supposed to solve.
It 'tells you a story' of divide and conquer.
This serves you so much when it comes to bug fixing or more important: bug preventing.
And it gives you an extra level of reflecting about what you're actually doing.To many programmers such a discipline may seem like talking to little children and explaining each and every bit of obvious information.
I had the experience to get bad grades in my math tests because i thought myself to have good memorizing abilities so i preferred not to note too much intermediate results.
That's where I discovered my psychology of introducing bugs.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617238</id>
	<title>some comments good..</title>
	<author>itzdandy</author>
	<datestamp>1262349840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I believe that some comments are good but overcommenting is messy.  I prefer to do my commenting in blocks as small descriptions of what the code is indended to do.</p><p>I like to organize my subroutines and objects etc by their type.  This way I can search my code for 'OBJECTS' and fine the section that describes objects or 'SUBROUTINES' and I will have made sub sections via comments 'SUBROUTINES\_SEARCH' etc etc.  I like few, simple, concise comments.  I do a lot of work in bash for administering servers but bash scripts should be clean and properly commented just like C or PHP etc.</p><p>#!/bin/BASH<br>#Code specific to bash or bash compatible shells. author *ME*</p><p># INCLUDES<br>include<nobr> <wbr></nobr>/etc/script.conf<br>include<nobr> <wbr></nobr>/usr/share/script/functions/*</p><p># SUBROUTINES<br>[item1]<br>
&nbsp; #workorder5678 custom;<br>
&nbsp; function1;function2;#end wo5678 1/1/2007, edit 3/18/2007;<br>
&nbsp; function3;end;</p><p>[item2]<br>
&nbsp; function1;function2;function3;end;</p><p>#end</p><p>NOT</p><p>#this is item1.  i like to put long comments that are as big as the code.<br>#i dont consider the fact that anyone reading these scripts in the future only<br>#needs to know why I did this and what it is supposed to do, not how it does it.  if you dont know how it does it then you are in the wrong job<br>[item1]<br>function1;function2;function3;end;</p><p>#this is item2.  it is almost like item1 above.<br>#I know I shouldn't reference physical locations in a file because they might move for organization but<br>#I thought id put a note in here that item2 references item3 with is at line 652 and item3 references item1 which is right above this on line 601.<br>[item2]<br>function1;function2;function3;end;</p><p>I think an important definition to point out is that 'comment' is not the same as 'document'.  Put comments in to assist you in the future, to find code, to give a quick hint at the functions intended use so you can use that code better.  Dont describe how to do a if/fi statement or how to use a function.</p></htmltext>
<tokenext>I believe that some comments are good but overcommenting is messy .
I prefer to do my commenting in blocks as small descriptions of what the code is indended to do.I like to organize my subroutines and objects etc by their type .
This way I can search my code for 'OBJECTS ' and fine the section that describes objects or 'SUBROUTINES ' and I will have made sub sections via comments 'SUBROUTINES \ _SEARCH ' etc etc .
I like few , simple , concise comments .
I do a lot of work in bash for administering servers but bash scripts should be clean and properly commented just like C or PHP etc. # ! /bin/BASH # Code specific to bash or bash compatible shells .
author * ME * # INCLUDESinclude /etc/script.confinclude /usr/share/script/functions/ * # SUBROUTINES [ item1 ]   # workorder5678 custom ;   function1 ; function2 ; # end wo5678 1/1/2007 , edit 3/18/2007 ;   function3 ; end ; [ item2 ]   function1 ; function2 ; function3 ; end ; # endNOT # this is item1 .
i like to put long comments that are as big as the code. # i dont consider the fact that anyone reading these scripts in the future only # needs to know why I did this and what it is supposed to do , not how it does it .
if you dont know how it does it then you are in the wrong job [ item1 ] function1 ; function2 ; function3 ; end ; # this is item2 .
it is almost like item1 above. # I know I should n't reference physical locations in a file because they might move for organization but # I thought id put a note in here that item2 references item3 with is at line 652 and item3 references item1 which is right above this on line 601 .
[ item2 ] function1 ; function2 ; function3 ; end ; I think an important definition to point out is that 'comment ' is not the same as 'document' .
Put comments in to assist you in the future , to find code , to give a quick hint at the functions intended use so you can use that code better .
Dont describe how to do a if/fi statement or how to use a function .</tokentext>
<sentencetext>I believe that some comments are good but overcommenting is messy.
I prefer to do my commenting in blocks as small descriptions of what the code is indended to do.I like to organize my subroutines and objects etc by their type.
This way I can search my code for 'OBJECTS' and fine the section that describes objects or 'SUBROUTINES' and I will have made sub sections via comments 'SUBROUTINES\_SEARCH' etc etc.
I like few, simple, concise comments.
I do a lot of work in bash for administering servers but bash scripts should be clean and properly commented just like C or PHP etc.#!/bin/BASH#Code specific to bash or bash compatible shells.
author *ME*# INCLUDESinclude /etc/script.confinclude /usr/share/script/functions/*# SUBROUTINES[item1]
  #workorder5678 custom;
  function1;function2;#end wo5678 1/1/2007, edit 3/18/2007;
  function3;end;[item2]
  function1;function2;function3;end;#endNOT#this is item1.
i like to put long comments that are as big as the code.#i dont consider the fact that anyone reading these scripts in the future only#needs to know why I did this and what it is supposed to do, not how it does it.
if you dont know how it does it then you are in the wrong job[item1]function1;function2;function3;end;#this is item2.
it is almost like item1 above.#I know I shouldn't reference physical locations in a file because they might move for organization but#I thought id put a note in here that item2 references item3 with is at line 652 and item3 references item1 which is right above this on line 601.
[item2]function1;function2;function3;end;I think an important definition to point out is that 'comment' is not the same as 'document'.
Put comments in to assist you in the future, to find code, to give a quick hint at the functions intended use so you can use that code better.
Dont describe how to do a if/fi statement or how to use a function.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619470</id>
	<title>Re:Wrong on all accounts</title>
	<author>Anonymous</author>
	<datestamp>1262367120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I'm the guy with half the staff required to do the minimum job, while the "comments are god" guy in the office has twice as many as he needs.</p><p>If you ever work for me I will personally fire you, or worse, you can go work for Sean - he's a fuck.</p><p>Comments are good, but to hell if you think that commenting the following is useful.</p><p>My appologies for being a mix of many languages in one litlte psedocode comment.</p><p>int ProcessRecords(Records &amp;recs)<nobr> <wbr></nobr>// if there aren't any records to process exit<br>if(recs.length()==0)<br>
&nbsp; &nbsp; &nbsp; &nbsp; return;<br>else<nobr> <wbr></nobr>// records to process, process them!<br>
&nbsp; &nbsp; &nbsp; &nbsp; foreach record in recs<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ProcessRecords(record);<br>
&nbsp; &nbsp; &nbsp; &nbsp; endforeach<br>endif</p><p>
&nbsp; &nbsp; &nbsp; &nbsp;</p></htmltext>
<tokenext>I 'm the guy with half the staff required to do the minimum job , while the " comments are god " guy in the office has twice as many as he needs.If you ever work for me I will personally fire you , or worse , you can go work for Sean - he 's a fuck.Comments are good , but to hell if you think that commenting the following is useful.My appologies for being a mix of many languages in one litlte psedocode comment.int ProcessRecords ( Records &amp;recs ) // if there are n't any records to process exitif ( recs.length ( ) = = 0 )         return ; else // records to process , process them !
        foreach record in recs                 ProcessRecords ( record ) ;         endforeachendif        </tokentext>
<sentencetext>I'm the guy with half the staff required to do the minimum job, while the "comments are god" guy in the office has twice as many as he needs.If you ever work for me I will personally fire you, or worse, you can go work for Sean - he's a fuck.Comments are good, but to hell if you think that commenting the following is useful.My appologies for being a mix of many languages in one litlte psedocode comment.int ProcessRecords(Records &amp;recs) // if there aren't any records to process exitif(recs.length()==0)
        return;else // records to process, process them!
        foreach record in recs
                ProcessRecords(record);
        endforeachendif
       </sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30646222</id>
	<title>Re:Does he think comments are pseudocode?</title>
	<author>Dom2</author>
	<datestamp>1262599680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Exactly the point of the article...</p></htmltext>
<tokenext>Exactly the point of the article.. .</tokentext>
<sentencetext>Exactly the point of the article...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616868</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617056</id>
	<title>Less verbose is more writeable</title>
	<author>Anonymous</author>
	<datestamp>1262348580000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>Early COBOL and Fortran computation code proves you wrong here. COBOL, without COMPUTE, required a separate line for each operation. Fortran from the start showed simple algebraic equations.</p><p>COBOL<br>======<br>MULTIPLY B BY B GIVING B-SQUARED.<br>MULTIPLY A BY C GIVING A-C.<br>MULTIPLY A-C BY 4 GIVING A-C-4.<br>MULTIPLY A BY 2 GIVING A-2.<br>SUBTRACT A-C-4 FROM B-SQUARED GIVING DISCR.<br>CALL SQRT USING DISCR GIVING RT-DISCR.<br>SUBTRACT B FROM RT-DISCR.<br>DIVIDE RT-DISCR BY A-2 GIVING ROOT-1.</p><p>Fortran<br>=====<br>R1 = (-B + SQRT(B**2 - 4*A*C))/(2*A)</p><p>Do you want 8 lines of code to write out the quadradic formula? Is that any clearer than one line? A simple one-line comment explains what *root-1* means to the program as a whole.</p><p>I've seen people write out intermediate variables like that using PHP or Python. Both languages handle that for you.</p></htmltext>
<tokenext>Early COBOL and Fortran computation code proves you wrong here .
COBOL , without COMPUTE , required a separate line for each operation .
Fortran from the start showed simple algebraic equations.COBOL = = = = = = MULTIPLY B BY B GIVING B-SQUARED.MULTIPLY A BY C GIVING A-C.MULTIPLY A-C BY 4 GIVING A-C-4.MULTIPLY A BY 2 GIVING A-2.SUBTRACT A-C-4 FROM B-SQUARED GIVING DISCR.CALL SQRT USING DISCR GIVING RT-DISCR.SUBTRACT B FROM RT-DISCR.DIVIDE RT-DISCR BY A-2 GIVING ROOT-1.Fortran = = = = = R1 = ( -B + SQRT ( B * * 2 - 4 * A * C ) ) / ( 2 * A ) Do you want 8 lines of code to write out the quadradic formula ?
Is that any clearer than one line ?
A simple one-line comment explains what * root-1 * means to the program as a whole.I 've seen people write out intermediate variables like that using PHP or Python .
Both languages handle that for you .</tokentext>
<sentencetext>Early COBOL and Fortran computation code proves you wrong here.
COBOL, without COMPUTE, required a separate line for each operation.
Fortran from the start showed simple algebraic equations.COBOL======MULTIPLY B BY B GIVING B-SQUARED.MULTIPLY A BY C GIVING A-C.MULTIPLY A-C BY 4 GIVING A-C-4.MULTIPLY A BY 2 GIVING A-2.SUBTRACT A-C-4 FROM B-SQUARED GIVING DISCR.CALL SQRT USING DISCR GIVING RT-DISCR.SUBTRACT B FROM RT-DISCR.DIVIDE RT-DISCR BY A-2 GIVING ROOT-1.Fortran=====R1 = (-B + SQRT(B**2 - 4*A*C))/(2*A)Do you want 8 lines of code to write out the quadradic formula?
Is that any clearer than one line?
A simple one-line comment explains what *root-1* means to the program as a whole.I've seen people write out intermediate variables like that using PHP or Python.
Both languages handle that for you.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616770</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622486</id>
	<title>Re:One person's myth is another person's fact.</title>
	<author>bingoUV</author>
	<datestamp>1262449740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You are right. I'd like to add here that for a programmer to write such comments, he must be able think all the possible ways the thing can be done. Often, the only reason WHY a particular way is chosen is : that is the only one that occurs to the programer at the time and it seems good enough. The simplest way does not always occur to people first.</p></htmltext>
<tokenext>You are right .
I 'd like to add here that for a programmer to write such comments , he must be able think all the possible ways the thing can be done .
Often , the only reason WHY a particular way is chosen is : that is the only one that occurs to the programer at the time and it seems good enough .
The simplest way does not always occur to people first .</tokentext>
<sentencetext>You are right.
I'd like to add here that for a programmer to write such comments, he must be able think all the possible ways the thing can be done.
Often, the only reason WHY a particular way is chosen is : that is the only one that occurs to the programer at the time and it seems good enough.
The simplest way does not always occur to people first.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616748</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622308</id>
	<title>Real world code and programmers please ...</title>
	<author>Anonymous</author>
	<datestamp>1262448180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Very clean and easy code<nobr> <wbr></nobr>... No comments required<nobr> <wbr></nobr>... Obvious<nobr> <wbr></nobr>...</p><p>Okay then, without looking this one up on google or fishing from your CS books etc. Please explain this simple piece of code.</p><p>int n = (count + 7) / 8;<br>switch (count \% 8) {<br>case 0: do { *to = *from++;<br>case 7:      *to = *from++;<br>case 6:      *to = *from++;<br>case 5:      *to = *from++;<br>case 4:      *to = *from++;<br>case 3:      *to = *from++;<br>case 2:      *to = *from++;<br>case 1:      *to = *from++;<br>} while (--n &gt; 0);</p><p>Also some very nice ways of counting bits in a variable, traversing lists, sorting arrays etc. Very neat and clean code samples can be found on the internet I challenge every one to explain some of the 'cool' samples you find without reading any comments on it.</p><p>So here is the deal:<br>Professional code base == years of development and tons of business logic from tens or hundreds of different developers with &gt; 1 million lines of multi-threaded code. So you're telling me that all you need is to look at the code base and you immediately understand the full extend of every line of code you read ?<br>Have you ever looked at code from India or at code from a freshmen ? Have you ever tried to re-factor functions with 6000 lines of code or more and source files with &gt; 60.000 lines of code with directories of more then 500 source code files ?</p><p>If this is so and you can naturally fix all bugs in these multi-threaded morass of code, I would like to interview you for a position at our company and am willing to pay you more then any other offer you currently have.</p><p>You are talking about hypothetical code that does not exist in the real world unless the code base was written by only one person. And even then. Point in case, we have a cool library that is at the core of our multi-threaded application base. Written by one guy. No comments. Very clever, dense code. So clever in fact, it is unreadable for any one but this guy. So lets assume he is mortal and / or he decides to leave the company at some point in time. I am sure you have no issues to re-write the code base that is at the center of a whole companies product line and makes the product stand out from any one else's product. Or you have no problems figuring out all the bit shifting etc that is taking place with mutex's and pthread calls all over the place in no time at all and fix problems in a matter of minutes.</p><p>BTW, the same guys who say source code comments are useless also ignore compiler warnings and are the same type of people who insist they can re-write a whole application suite in a matter of weeks that has taken a team of 10 multiple years to write ( usually because they are too lazy to read and understand the code ).</p><p>I could go on, but I am so upset with this article I better stop here.</p></htmltext>
<tokenext>Very clean and easy code ... No comments required ... Obvious ...Okay then , without looking this one up on google or fishing from your CS books etc .
Please explain this simple piece of code.int n = ( count + 7 ) / 8 ; switch ( count \ % 8 ) { case 0 : do { * to = * from + + ; case 7 : * to = * from + + ; case 6 : * to = * from + + ; case 5 : * to = * from + + ; case 4 : * to = * from + + ; case 3 : * to = * from + + ; case 2 : * to = * from + + ; case 1 : * to = * from + + ; } while ( --n &gt; 0 ) ; Also some very nice ways of counting bits in a variable , traversing lists , sorting arrays etc .
Very neat and clean code samples can be found on the internet I challenge every one to explain some of the 'cool ' samples you find without reading any comments on it.So here is the deal : Professional code base = = years of development and tons of business logic from tens or hundreds of different developers with &gt; 1 million lines of multi-threaded code .
So you 're telling me that all you need is to look at the code base and you immediately understand the full extend of every line of code you read ? Have you ever looked at code from India or at code from a freshmen ?
Have you ever tried to re-factor functions with 6000 lines of code or more and source files with &gt; 60.000 lines of code with directories of more then 500 source code files ? If this is so and you can naturally fix all bugs in these multi-threaded morass of code , I would like to interview you for a position at our company and am willing to pay you more then any other offer you currently have.You are talking about hypothetical code that does not exist in the real world unless the code base was written by only one person .
And even then .
Point in case , we have a cool library that is at the core of our multi-threaded application base .
Written by one guy .
No comments .
Very clever , dense code .
So clever in fact , it is unreadable for any one but this guy .
So lets assume he is mortal and / or he decides to leave the company at some point in time .
I am sure you have no issues to re-write the code base that is at the center of a whole companies product line and makes the product stand out from any one else 's product .
Or you have no problems figuring out all the bit shifting etc that is taking place with mutex 's and pthread calls all over the place in no time at all and fix problems in a matter of minutes.BTW , the same guys who say source code comments are useless also ignore compiler warnings and are the same type of people who insist they can re-write a whole application suite in a matter of weeks that has taken a team of 10 multiple years to write ( usually because they are too lazy to read and understand the code ) .I could go on , but I am so upset with this article I better stop here .</tokentext>
<sentencetext>Very clean and easy code ... No comments required ... Obvious ...Okay then, without looking this one up on google or fishing from your CS books etc.
Please explain this simple piece of code.int n = (count + 7) / 8;switch (count \% 8) {case 0: do { *to = *from++;case 7:      *to = *from++;case 6:      *to = *from++;case 5:      *to = *from++;case 4:      *to = *from++;case 3:      *to = *from++;case 2:      *to = *from++;case 1:      *to = *from++;} while (--n &gt; 0);Also some very nice ways of counting bits in a variable, traversing lists, sorting arrays etc.
Very neat and clean code samples can be found on the internet I challenge every one to explain some of the 'cool' samples you find without reading any comments on it.So here is the deal:Professional code base == years of development and tons of business logic from tens or hundreds of different developers with &gt; 1 million lines of multi-threaded code.
So you're telling me that all you need is to look at the code base and you immediately understand the full extend of every line of code you read ?Have you ever looked at code from India or at code from a freshmen ?
Have you ever tried to re-factor functions with 6000 lines of code or more and source files with &gt; 60.000 lines of code with directories of more then 500 source code files ?If this is so and you can naturally fix all bugs in these multi-threaded morass of code, I would like to interview you for a position at our company and am willing to pay you more then any other offer you currently have.You are talking about hypothetical code that does not exist in the real world unless the code base was written by only one person.
And even then.
Point in case, we have a cool library that is at the core of our multi-threaded application base.
Written by one guy.
No comments.
Very clever, dense code.
So clever in fact, it is unreadable for any one but this guy.
So lets assume he is mortal and / or he decides to leave the company at some point in time.
I am sure you have no issues to re-write the code base that is at the center of a whole companies product line and makes the product stand out from any one else's product.
Or you have no problems figuring out all the bit shifting etc that is taking place with mutex's and pthread calls all over the place in no time at all and fix problems in a matter of minutes.BTW, the same guys who say source code comments are useless also ignore compiler warnings and are the same type of people who insist they can re-write a whole application suite in a matter of weeks that has taken a team of 10 multiple years to write ( usually because they are too lazy to read and understand the code ).I could go on, but I am so upset with this article I better stop here.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617292</id>
	<title>Job Security</title>
	<author>jamesh</author>
	<datestamp>1262350260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Wasn't one of the mantra's of the humorous Job Security paper that someone published a while back that you should comment only the obvious stuff, eg:</p><p>while (i  epsilon(n))<br>{<br>
&nbsp; &nbsp; i += (j + 47) * 55 - sqrt(r) + j * j - r * r - pom();<br>}<br>i++;<nobr> <wbr></nobr>// increment i by 1</p><p>Myself, I comment next to nothing unless I suspect that I won't know what I was thinking if I come back to the code in 6 months. If I come back to code in 6 months and can't remember what it does or why it does it that way, I'll put comments in for next time.</p></htmltext>
<tokenext>Was n't one of the mantra 's of the humorous Job Security paper that someone published a while back that you should comment only the obvious stuff , eg : while ( i epsilon ( n ) ) {     i + = ( j + 47 ) * 55 - sqrt ( r ) + j * j - r * r - pom ( ) ; } i + + ; // increment i by 1Myself , I comment next to nothing unless I suspect that I wo n't know what I was thinking if I come back to the code in 6 months .
If I come back to code in 6 months and ca n't remember what it does or why it does it that way , I 'll put comments in for next time .</tokentext>
<sentencetext>Wasn't one of the mantra's of the humorous Job Security paper that someone published a while back that you should comment only the obvious stuff, eg:while (i  epsilon(n)){
    i += (j + 47) * 55 - sqrt(r) + j * j - r * r - pom();}i++; // increment i by 1Myself, I comment next to nothing unless I suspect that I won't know what I was thinking if I come back to the code in 6 months.
If I come back to code in 6 months and can't remember what it does or why it does it that way, I'll put comments in for next time.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619266</id>
	<title>Re:Has No One Actually Studied This?</title>
	<author>adamrut</author>
	<datestamp>1262364660000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>If not, someone really ought to do a serious study. And then start teaching people something that's actually known to work.</p></div><p>I'd be interested to see a study, but I'm sure it'd create more questions than answers given how hotly every side of this argument is debated.

I think that writing good comments is much like writing good code, the only way you get good at it is reading, writing and re-writing lots and lots of code/comments. After a while you know what needs to be commented, the way it needs to be commented and you know what doesn't need to be commented. Writing relevant information clearly and concisely is a skill that must be learned and practiced.</p></div>
	</htmltext>
<tokenext>If not , someone really ought to do a serious study .
And then start teaching people something that 's actually known to work.I 'd be interested to see a study , but I 'm sure it 'd create more questions than answers given how hotly every side of this argument is debated .
I think that writing good comments is much like writing good code , the only way you get good at it is reading , writing and re-writing lots and lots of code/comments .
After a while you know what needs to be commented , the way it needs to be commented and you know what does n't need to be commented .
Writing relevant information clearly and concisely is a skill that must be learned and practiced .</tokentext>
<sentencetext>If not, someone really ought to do a serious study.
And then start teaching people something that's actually known to work.I'd be interested to see a study, but I'm sure it'd create more questions than answers given how hotly every side of this argument is debated.
I think that writing good comments is much like writing good code, the only way you get good at it is reading, writing and re-writing lots and lots of code/comments.
After a while you know what needs to be commented, the way it needs to be commented and you know what doesn't need to be commented.
Writing relevant information clearly and concisely is a skill that must be learned and practiced.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622224</id>
	<title>I'm a fan of [useful] comments</title>
	<author>eggy78</author>
	<datestamp>1262447520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My employer has a very large, and, IMO very organized, but incomprehensibly so, codebase. There aren't a lot of high-level specs, and there aren't a lot of good comments in the code. There are a lot of times where I will be tasked with finding a bug, and I can see where the program breaks as well as why it breaks, but without knowing what it's <i>supposed</i> to do, it's hard for me to make the right fix. There are a lot of places where we have some 1500-line (don't even get me started on this) C++ function handling some <i>enormous</i> data structures (20+ member variables, of which roughly half of those are equally-large data structures) and there's basically no info on what any of it is really supposed to do (other than whatever function/variable names there are).
</p><p>
Whenever I'm not cleaning up other peoples' messes, I tend to focus on making sure it's obvious what I was <i>trying</i> to do and that the input/output of my function is well-specified, so if someone comes along behind me it's easier for them to locate the "true" problem by looking at the specifications than just finding a "problem" and trying to make sure it doesn't happen again with some quick fix. I also try to keep my functions as task-specific as possible and small enough to be somewhat comprehensible on their own while considering that we don't have unlimited stack space on our devices.
</p><p>
But, then again, I'm relatively new there. They might break my will eventually...
</p></htmltext>
<tokenext>My employer has a very large , and , IMO very organized , but incomprehensibly so , codebase .
There are n't a lot of high-level specs , and there are n't a lot of good comments in the code .
There are a lot of times where I will be tasked with finding a bug , and I can see where the program breaks as well as why it breaks , but without knowing what it 's supposed to do , it 's hard for me to make the right fix .
There are a lot of places where we have some 1500-line ( do n't even get me started on this ) C + + function handling some enormous data structures ( 20 + member variables , of which roughly half of those are equally-large data structures ) and there 's basically no info on what any of it is really supposed to do ( other than whatever function/variable names there are ) .
Whenever I 'm not cleaning up other peoples ' messes , I tend to focus on making sure it 's obvious what I was trying to do and that the input/output of my function is well-specified , so if someone comes along behind me it 's easier for them to locate the " true " problem by looking at the specifications than just finding a " problem " and trying to make sure it does n't happen again with some quick fix .
I also try to keep my functions as task-specific as possible and small enough to be somewhat comprehensible on their own while considering that we do n't have unlimited stack space on our devices .
But , then again , I 'm relatively new there .
They might break my will eventually.. .</tokentext>
<sentencetext>My employer has a very large, and, IMO very organized, but incomprehensibly so, codebase.
There aren't a lot of high-level specs, and there aren't a lot of good comments in the code.
There are a lot of times where I will be tasked with finding a bug, and I can see where the program breaks as well as why it breaks, but without knowing what it's supposed to do, it's hard for me to make the right fix.
There are a lot of places where we have some 1500-line (don't even get me started on this) C++ function handling some enormous data structures (20+ member variables, of which roughly half of those are equally-large data structures) and there's basically no info on what any of it is really supposed to do (other than whatever function/variable names there are).
Whenever I'm not cleaning up other peoples' messes, I tend to focus on making sure it's obvious what I was trying to do and that the input/output of my function is well-specified, so if someone comes along behind me it's easier for them to locate the "true" problem by looking at the specifications than just finding a "problem" and trying to make sure it doesn't happen again with some quick fix.
I also try to keep my functions as task-specific as possible and small enough to be somewhat comprehensible on their own while considering that we don't have unlimited stack space on our devices.
But, then again, I'm relatively new there.
They might break my will eventually...
</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619162</id>
	<title>Re:every line of code should be commented</title>
	<author>Imagix</author>
	<datestamp>1262363580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Sorry, you've failed code review.  I don't see a comments on the "else" line.</htmltext>
<tokenext>Sorry , you 've failed code review .
I do n't see a comments on the " else " line .</tokentext>
<sentencetext>Sorry, you've failed code review.
I don't see a comments on the "else" line.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618092</id>
	<title>My Real Problem ...</title>
	<author>smpoole7</author>
	<datestamp>1262355420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Isn't the lack of comments, it's getting lost in a dozen (or two or fifteen dozen) different source code files, trying to figure out what the original programmer wanted to do. F/OSS is a beautiful, wonderful thing, and I'm fully committed to it, but I can't tell you how many times I've downloaded a F/OSS project with the intention to tinker with the code, only to get completely lost in it.<br><br>Just for record, I'm a commenter, and I like comments that explain what the code is doing. But to help address the aforementioned, my code contains lines like "SomeFunction()<nobr> <wbr></nobr>/* see doodat.h */" and "function( SOMEVALUE );<nobr> <wbr></nobr>/* see heredat.h for SOMEVALUE */" because I know that even I, the guy who wrote the stuff, will come back years later and be totally lost.<br><br>If I had a dollar for every time I've grep'd for the main() function, then followed the execution thread just to see what a program was really doing, I could take us all to dinner.<nobr> <wbr></nobr>:)</htmltext>
<tokenext>Is n't the lack of comments , it 's getting lost in a dozen ( or two or fifteen dozen ) different source code files , trying to figure out what the original programmer wanted to do .
F/OSS is a beautiful , wonderful thing , and I 'm fully committed to it , but I ca n't tell you how many times I 've downloaded a F/OSS project with the intention to tinker with the code , only to get completely lost in it.Just for record , I 'm a commenter , and I like comments that explain what the code is doing .
But to help address the aforementioned , my code contains lines like " SomeFunction ( ) / * see doodat.h * / " and " function ( SOMEVALUE ) ; / * see heredat.h for SOMEVALUE * / " because I know that even I , the guy who wrote the stuff , will come back years later and be totally lost.If I had a dollar for every time I 've grep 'd for the main ( ) function , then followed the execution thread just to see what a program was really doing , I could take us all to dinner .
: )</tokentext>
<sentencetext>Isn't the lack of comments, it's getting lost in a dozen (or two or fifteen dozen) different source code files, trying to figure out what the original programmer wanted to do.
F/OSS is a beautiful, wonderful thing, and I'm fully committed to it, but I can't tell you how many times I've downloaded a F/OSS project with the intention to tinker with the code, only to get completely lost in it.Just for record, I'm a commenter, and I like comments that explain what the code is doing.
But to help address the aforementioned, my code contains lines like "SomeFunction() /* see doodat.h */" and "function( SOMEVALUE ); /* see heredat.h for SOMEVALUE */" because I know that even I, the guy who wrote the stuff, will come back years later and be totally lost.If I had a dollar for every time I've grep'd for the main() function, then followed the execution thread just to see what a program was really doing, I could take us all to dinner.
:)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618738</id>
	<title>Re:every line of code should be commented</title>
	<author>Anonymous</author>
	<datestamp>1262359620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I'm honestly suprised nobody has taken this seriously and tried to admonish you for it.</p><p>This is Slashdot, after all.</p></htmltext>
<tokenext>I 'm honestly suprised nobody has taken this seriously and tried to admonish you for it.This is Slashdot , after all .</tokentext>
<sentencetext>I'm honestly suprised nobody has taken this seriously and tried to admonish you for it.This is Slashdot, after all.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616696</id>
	<title>One person's myth is another person's fact.</title>
	<author>Anonymous</author>
	<datestamp>1262345400000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>Well, everyone's welcome to their opinion, but it's pretty well proven after decades of software engineering that code should be commented.  The price of maintaining comment-free code is well known.</p><p>There is a school of thought among programmers who consider themselves hotshots that if you are not a hotshot you have no business touching their code.  The problem with this attitude is that it has little to do with the real world, where people change jobs and programmers inherit someone else's code.  If you want to write perfect, comment free code in your perfect little world, go right ahead, but don't expect to make a living at it most of the time.</p><p>It's surprising to me that someone has submitted this as a "news" item.  News flash!  Everything you know is wrong.  Sorry I don't buy that.  If you don't comment your code, I won't pay you for it.  I'll inform the management that you neglected an important step and don't deserve a good reference.  I won't be able to give you the benefit of the doubt when your code doesn't make perfect sense.  I'll trash talk your code in front of your colleagues.  Look at all the mistakes in this guy's work; I'll sure never recommend him if his resume crosses my desk.  We may need to just rewrite this stuff because it's not maintainable as written.</p><p>What's really annoying is when they put comments that don't elucidate the code or their intent; they're just snide little messages from one know-it-all to another.  They're too embarrassed to actually explain the code because that implies a level of insecurity they would rather not admit to.  So instead they say things like:<nobr> <wbr></nobr>/* yeah, I don't like this either */<br>or<br># hack, to be fixed later</p><p>Wooooo, really helpful comments there.  I've seen this sort of thing countless times in my career and most others I know have as well.</p></htmltext>
<tokenext>Well , everyone 's welcome to their opinion , but it 's pretty well proven after decades of software engineering that code should be commented .
The price of maintaining comment-free code is well known.There is a school of thought among programmers who consider themselves hotshots that if you are not a hotshot you have no business touching their code .
The problem with this attitude is that it has little to do with the real world , where people change jobs and programmers inherit someone else 's code .
If you want to write perfect , comment free code in your perfect little world , go right ahead , but do n't expect to make a living at it most of the time.It 's surprising to me that someone has submitted this as a " news " item .
News flash !
Everything you know is wrong .
Sorry I do n't buy that .
If you do n't comment your code , I wo n't pay you for it .
I 'll inform the management that you neglected an important step and do n't deserve a good reference .
I wo n't be able to give you the benefit of the doubt when your code does n't make perfect sense .
I 'll trash talk your code in front of your colleagues .
Look at all the mistakes in this guy 's work ; I 'll sure never recommend him if his resume crosses my desk .
We may need to just rewrite this stuff because it 's not maintainable as written.What 's really annoying is when they put comments that do n't elucidate the code or their intent ; they 're just snide little messages from one know-it-all to another .
They 're too embarrassed to actually explain the code because that implies a level of insecurity they would rather not admit to .
So instead they say things like : / * yeah , I do n't like this either * /or # hack , to be fixed laterWooooo , really helpful comments there .
I 've seen this sort of thing countless times in my career and most others I know have as well .</tokentext>
<sentencetext>Well, everyone's welcome to their opinion, but it's pretty well proven after decades of software engineering that code should be commented.
The price of maintaining comment-free code is well known.There is a school of thought among programmers who consider themselves hotshots that if you are not a hotshot you have no business touching their code.
The problem with this attitude is that it has little to do with the real world, where people change jobs and programmers inherit someone else's code.
If you want to write perfect, comment free code in your perfect little world, go right ahead, but don't expect to make a living at it most of the time.It's surprising to me that someone has submitted this as a "news" item.
News flash!
Everything you know is wrong.
Sorry I don't buy that.
If you don't comment your code, I won't pay you for it.
I'll inform the management that you neglected an important step and don't deserve a good reference.
I won't be able to give you the benefit of the doubt when your code doesn't make perfect sense.
I'll trash talk your code in front of your colleagues.
Look at all the mistakes in this guy's work; I'll sure never recommend him if his resume crosses my desk.
We may need to just rewrite this stuff because it's not maintainable as written.What's really annoying is when they put comments that don't elucidate the code or their intent; they're just snide little messages from one know-it-all to another.
They're too embarrassed to actually explain the code because that implies a level of insecurity they would rather not admit to.
So instead they say things like: /* yeah, I don't like this either */or# hack, to be fixed laterWooooo, really helpful comments there.
I've seen this sort of thing countless times in my career and most others I know have as well.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618464</id>
	<title>Re:every line of code should be commented</title>
	<author>careysub</author>
	<datestamp>1262357400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'd rate if funny too... if I hadn't actually worked in environments where commenting of this sort was actually required...</p></htmltext>
<tokenext>I 'd rate if funny too... if I had n't actually worked in environments where commenting of this sort was actually required.. .</tokentext>
<sentencetext>I'd rate if funny too... if I hadn't actually worked in environments where commenting of this sort was actually required...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618724</id>
	<title>Re:Has No One Actually Studied This?</title>
	<author>Anonymous</author>
	<datestamp>1262359500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Another characteristic of bad programmers that I noticed was their tendency to keep copying data from one data structure to another instead of using it in place. Obviously an indication of bad design, and it introduced lots of bugs. You knew as soon as you opened a source file and saw comments like "Copy blah-blah data from abc array to xyz array" that you were in trouble.</p></div><p>This is a ridiculous statement.  Depending on the implementation sometimes it is certainly nice to change data in place for performance reasons and to reduce potential mistakes in the copy (buffer overruns being an extreme example).  However, sometimes maintaining two copies of data is crucial (i.e. current and previous states).   When you see a copy block explaining what it is trying to do it is easy to figure out if it is actually doing that task correctly.</p></div>
	</htmltext>
<tokenext>Another characteristic of bad programmers that I noticed was their tendency to keep copying data from one data structure to another instead of using it in place .
Obviously an indication of bad design , and it introduced lots of bugs .
You knew as soon as you opened a source file and saw comments like " Copy blah-blah data from abc array to xyz array " that you were in trouble.This is a ridiculous statement .
Depending on the implementation sometimes it is certainly nice to change data in place for performance reasons and to reduce potential mistakes in the copy ( buffer overruns being an extreme example ) .
However , sometimes maintaining two copies of data is crucial ( i.e .
current and previous states ) .
When you see a copy block explaining what it is trying to do it is easy to figure out if it is actually doing that task correctly .</tokentext>
<sentencetext>Another characteristic of bad programmers that I noticed was their tendency to keep copying data from one data structure to another instead of using it in place.
Obviously an indication of bad design, and it introduced lots of bugs.
You knew as soon as you opened a source file and saw comments like "Copy blah-blah data from abc array to xyz array" that you were in trouble.This is a ridiculous statement.
Depending on the implementation sometimes it is certainly nice to change data in place for performance reasons and to reduce potential mistakes in the copy (buffer overruns being an extreme example).
However, sometimes maintaining two copies of data is crucial (i.e.
current and previous states).
When you see a copy block explaining what it is trying to do it is easy to figure out if it is actually doing that task correctly.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621434</id>
	<title>Re:More verbose == less readable?</title>
	<author>Cederic</author>
	<datestamp>1262438040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Efficient code is fine, but what's the efficiency you're measuring?</p><p>Efficient code writing? Efficient code maintenance? Efficient compilation times? Efficient code execution?</p><p>Three of those cost a lot of money, yet many programmers focus on the fourth (and still cock it up).</p><p>Of course, it's pretty easy to write the 4 line script you provided in a single line by explicitly stating the variables, but that's less re-usable<nobr> <wbr></nobr>:)</p></htmltext>
<tokenext>Efficient code is fine , but what 's the efficiency you 're measuring ? Efficient code writing ?
Efficient code maintenance ?
Efficient compilation times ?
Efficient code execution ? Three of those cost a lot of money , yet many programmers focus on the fourth ( and still cock it up ) .Of course , it 's pretty easy to write the 4 line script you provided in a single line by explicitly stating the variables , but that 's less re-usable : )</tokentext>
<sentencetext>Efficient code is fine, but what's the efficiency you're measuring?Efficient code writing?
Efficient code maintenance?
Efficient compilation times?
Efficient code execution?Three of those cost a lot of money, yet many programmers focus on the fourth (and still cock it up).Of course, it's pretty easy to write the 4 line script you provided in a single line by explicitly stating the variables, but that's less re-usable :)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617308</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619206</id>
	<title>Re:One person's myth is another person's fact.</title>
	<author>daVinci1980</author>
	<datestamp>1262364000000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>I say this in a slightly different, but more concise way:</p><p>Comments (and self-documenting code) should tell you "what" and "why", because the code is telling you "how".</p></htmltext>
<tokenext>I say this in a slightly different , but more concise way : Comments ( and self-documenting code ) should tell you " what " and " why " , because the code is telling you " how " .</tokentext>
<sentencetext>I say this in a slightly different, but more concise way:Comments (and self-documenting code) should tell you "what" and "why", because the code is telling you "how".</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616748</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617884</id>
	<title>Principles Over Rules</title>
	<author>ed.markovich</author>
	<datestamp>1262354340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>There's a quote in Code Complete ( I think ) that one should be able to read code in the evening in one's armchair with a glass of brandy as if it were a novel. My personal version of it - and the criteria I impose on my team - is that I should be able to read and understand the code w/o having to think too hard or knowing much about what the programmer is trying to do. It's really easy to enforce this in code review - if I can sit at someone's desk and quietly read their code and know what's going on, it's good enough - either sufficiently-commented or self-commenting. On the other hand, if I have to ask what a section does, whatever the developer says to me verbally is also a good candidate for a comment.

The other key factor in commenting is that it must be clear not only what the code is doing, but why. For example, if I encounter the following in the code:

if (productType != SOME\_TYPE and client != SOME\_CLIENT) {
   sendReportToCleint()
}

it doesn't help to have a comment saying<nobr> <wbr></nobr>// Send the report, unless it's SOME\_CLIENT buying SOME\_TYPE.
I already know that... what helps is<nobr> <wbr></nobr>// Don't send reports to SOME\_CLIENT for SOME\_TYPE because their system<nobr> <wbr></nobr>// crashes on this message and they don't know how to fix it. This is<nobr> <wbr></nobr>// as per discussion with Jon Doe on mm/dd/yyyy

This is basically the principle of least astonishment</div>
	</htmltext>
<tokenext>There 's a quote in Code Complete ( I think ) that one should be able to read code in the evening in one 's armchair with a glass of brandy as if it were a novel .
My personal version of it - and the criteria I impose on my team - is that I should be able to read and understand the code w/o having to think too hard or knowing much about what the programmer is trying to do .
It 's really easy to enforce this in code review - if I can sit at someone 's desk and quietly read their code and know what 's going on , it 's good enough - either sufficiently-commented or self-commenting .
On the other hand , if I have to ask what a section does , whatever the developer says to me verbally is also a good candidate for a comment .
The other key factor in commenting is that it must be clear not only what the code is doing , but why .
For example , if I encounter the following in the code : if ( productType ! = SOME \ _TYPE and client ! = SOME \ _CLIENT ) { sendReportToCleint ( ) } it does n't help to have a comment saying // Send the report , unless it 's SOME \ _CLIENT buying SOME \ _TYPE .
I already know that... what helps is // Do n't send reports to SOME \ _CLIENT for SOME \ _TYPE because their system // crashes on this message and they do n't know how to fix it .
This is // as per discussion with Jon Doe on mm/dd/yyyy This is basically the principle of least astonishment</tokentext>
<sentencetext>There's a quote in Code Complete ( I think ) that one should be able to read code in the evening in one's armchair with a glass of brandy as if it were a novel.
My personal version of it - and the criteria I impose on my team - is that I should be able to read and understand the code w/o having to think too hard or knowing much about what the programmer is trying to do.
It's really easy to enforce this in code review - if I can sit at someone's desk and quietly read their code and know what's going on, it's good enough - either sufficiently-commented or self-commenting.
On the other hand, if I have to ask what a section does, whatever the developer says to me verbally is also a good candidate for a comment.
The other key factor in commenting is that it must be clear not only what the code is doing, but why.
For example, if I encounter the following in the code:

if (productType != SOME\_TYPE and client != SOME\_CLIENT) {
   sendReportToCleint()
}

it doesn't help to have a comment saying // Send the report, unless it's SOME\_CLIENT buying SOME\_TYPE.
I already know that... what helps is // Don't send reports to SOME\_CLIENT for SOME\_TYPE because their system // crashes on this message and they don't know how to fix it.
This is // as per discussion with Jon Doe on mm/dd/yyyy

This is basically the principle of least astonishment
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619942</id>
	<title>Re:every line of code should be commented</title>
	<author>Anonymous</author>
	<datestamp>1262372940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>cool! what does that "else" line do ?</p></htmltext>
<tokenext>cool !
what does that " else " line do ?</tokentext>
<sentencetext>cool!
what does that "else" line do ?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617800</id>
	<title>Re:Code format</title>
	<author>TheRaven64</author>
	<datestamp>1262353800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The 80-column limit is based on the human visual system's ability to track lines of text, not the width of the terminal.  A better constraint would be that a line can't contain more than 66 non-space characters, but 80 columns is a good rough approximation of this that also ties in prevention of excessive scope nesting.</htmltext>
<tokenext>The 80-column limit is based on the human visual system 's ability to track lines of text , not the width of the terminal .
A better constraint would be that a line ca n't contain more than 66 non-space characters , but 80 columns is a good rough approximation of this that also ties in prevention of excessive scope nesting .</tokentext>
<sentencetext>The 80-column limit is based on the human visual system's ability to track lines of text, not the width of the terminal.
A better constraint would be that a line can't contain more than 66 non-space characters, but 80 columns is a good rough approximation of this that also ties in prevention of excessive scope nesting.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617176</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618474</id>
	<title>Re:every line of code should be commented</title>
	<author>JoeMerchant</author>
	<datestamp>1262357520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>
You know, I do those close brace comments, but usually with a copy of whatever opened them:<br> <br>

    }<nobr> <wbr></nobr>// if ( dome )<br> <br>

Yes, the smart editor will highlight the block for me, but many times (especially in code I didn't write) the block is bigger than the page....</htmltext>
<tokenext>You know , I do those close brace comments , but usually with a copy of whatever opened them : } // if ( dome ) Yes , the smart editor will highlight the block for me , but many times ( especially in code I did n't write ) the block is bigger than the page... .</tokentext>
<sentencetext>
You know, I do those close brace comments, but usually with a copy of whatever opened them: 

    } // if ( dome ) 

Yes, the smart editor will highlight the block for me, but many times (especially in code I didn't write) the block is bigger than the page....</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616804</id>
	<title>Blame my professor</title>
	<author>Quila</author>
	<datestamp>1262346480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I had excessive commenting drilled into me in college. It's one of the things I've had to unlearn.</p></htmltext>
<tokenext>I had excessive commenting drilled into me in college .
It 's one of the things I 've had to unlearn .</tokentext>
<sentencetext>I had excessive commenting drilled into me in college.
It's one of the things I've had to unlearn.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617176</id>
	<title>Code format</title>
	<author>Anonymous</author>
	<datestamp>1262349420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Is very important, and it be consistent is more so; a good editor Vim or Emacs and code beautifier is your friend. Often you will need to temporarily re-format code, as you work on it, but in a big code base root-nd-branch reformats must be very rare, it screws up the SCM history, so I often re-format, fix get patch, revert, apply patch. Git etc makes this very easy.<br><br>Personally I hate the KR if (foo) {<br><br>} style. I like<br><br>{<br>}<br><br>An 80 column line limit is also OLD, I never edit in narrow windows &gt;160 common.<br><br>drop, but I cant always get what I like.</htmltext>
<tokenext>Is very important , and it be consistent is more so ; a good editor Vim or Emacs and code beautifier is your friend .
Often you will need to temporarily re-format code , as you work on it , but in a big code base root-nd-branch reformats must be very rare , it screws up the SCM history , so I often re-format , fix get patch , revert , apply patch .
Git etc makes this very easy.Personally I hate the KR if ( foo ) { } style .
I like { } An 80 column line limit is also OLD , I never edit in narrow windows &gt; 160 common.drop , but I cant always get what I like .</tokentext>
<sentencetext>Is very important, and it be consistent is more so; a good editor Vim or Emacs and code beautifier is your friend.
Often you will need to temporarily re-format code, as you work on it, but in a big code base root-nd-branch reformats must be very rare, it screws up the SCM history, so I often re-format, fix get patch, revert, apply patch.
Git etc makes this very easy.Personally I hate the KR if (foo) {} style.
I like{}An 80 column line limit is also OLD, I never edit in narrow windows &gt;160 common.drop, but I cant always get what I like.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616750</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620210</id>
	<title>Re:Not commenting is a sign of not thinking or car</title>
	<author>Anonymous</author>
	<datestamp>1262462820000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>One of the places I worked at extended the "no comments" rule to "no Javadoc, no documentation except on the Wiki". Of course, once the code is passed to another company the Wiki won't be (since it was blocked from customer sight it will be considered "company confidential") and there will be absolutely nothing to tell the next group how to change anything. The same project engineering head said that since this is an Agile project there should be no design documentation (at all).<br>The only answer for this is "comments are evil". I gave up and removed my comments (he typically changed code without consulting the programmers anyways).<br>This is what the "comments are evil" line gets you if handed to morons.</p></htmltext>
<tokenext>One of the places I worked at extended the " no comments " rule to " no Javadoc , no documentation except on the Wiki " .
Of course , once the code is passed to another company the Wiki wo n't be ( since it was blocked from customer sight it will be considered " company confidential " ) and there will be absolutely nothing to tell the next group how to change anything .
The same project engineering head said that since this is an Agile project there should be no design documentation ( at all ) .The only answer for this is " comments are evil " .
I gave up and removed my comments ( he typically changed code without consulting the programmers anyways ) .This is what the " comments are evil " line gets you if handed to morons .</tokentext>
<sentencetext>One of the places I worked at extended the "no comments" rule to "no Javadoc, no documentation except on the Wiki".
Of course, once the code is passed to another company the Wiki won't be (since it was blocked from customer sight it will be considered "company confidential") and there will be absolutely nothing to tell the next group how to change anything.
The same project engineering head said that since this is an Agile project there should be no design documentation (at all).The only answer for this is "comments are evil".
I gave up and removed my comments (he typically changed code without consulting the programmers anyways).This is what the "comments are evil" line gets you if handed to morons.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616936</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619952</id>
	<title>Re:Wrong on all accounts</title>
	<author>grimw</author>
	<datestamp>1262373060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You really have all that experience and need all that commenting?  I think you need to check your experience at the door.  Hell, I've got "two years real world experience outside school", and no one comments their code where I work, including me.  I would hardly call them unprofessional or bad programmers, even if occasional things do pop up that seem, and may be, retarded, because it's almost always a big waste of time.  After looking at code like that for over two years, across several projects in several languages, I can say it's not as hard to read uncommented code as you make it out to be.  In fact, I often skip reading comments for the sheer fact that they're usually incorrect because they're either not maintained as the code is updated or were always wrong.</p><p>Except for some extremely obscure pieces of code, generally revolving around optimizations, architecture-specific workarounds, compiler-bug workarounds, etc., have I ever found comments to be useful outside of documenting an API.  In point of fact, there will never be a comment stating more correctly what the code is doing than the code itself.</p><p>As one caveat, I've seen good use of comments in ASM.  However, with the ability to use more advanced assembler features in GCC or LLVM these days, you can put pretty sophisticated names on your code-flow elements and not require nearly as many comments as in the past.  And with being able to inline ASM into code for those cases you need it, you can even use sophisticated meta-names for your registers that are obvious to the reader.  Also, being the fact that the only person that work on an optimized piece of code would be someone that already knows that architecture's ASM or can learn what they need, you can rest assured that they'll have all the tools necessary to read and modify your code.</p></htmltext>
<tokenext>You really have all that experience and need all that commenting ?
I think you need to check your experience at the door .
Hell , I 've got " two years real world experience outside school " , and no one comments their code where I work , including me .
I would hardly call them unprofessional or bad programmers , even if occasional things do pop up that seem , and may be , retarded , because it 's almost always a big waste of time .
After looking at code like that for over two years , across several projects in several languages , I can say it 's not as hard to read uncommented code as you make it out to be .
In fact , I often skip reading comments for the sheer fact that they 're usually incorrect because they 're either not maintained as the code is updated or were always wrong.Except for some extremely obscure pieces of code , generally revolving around optimizations , architecture-specific workarounds , compiler-bug workarounds , etc. , have I ever found comments to be useful outside of documenting an API .
In point of fact , there will never be a comment stating more correctly what the code is doing than the code itself.As one caveat , I 've seen good use of comments in ASM .
However , with the ability to use more advanced assembler features in GCC or LLVM these days , you can put pretty sophisticated names on your code-flow elements and not require nearly as many comments as in the past .
And with being able to inline ASM into code for those cases you need it , you can even use sophisticated meta-names for your registers that are obvious to the reader .
Also , being the fact that the only person that work on an optimized piece of code would be someone that already knows that architecture 's ASM or can learn what they need , you can rest assured that they 'll have all the tools necessary to read and modify your code .</tokentext>
<sentencetext>You really have all that experience and need all that commenting?
I think you need to check your experience at the door.
Hell, I've got "two years real world experience outside school", and no one comments their code where I work, including me.
I would hardly call them unprofessional or bad programmers, even if occasional things do pop up that seem, and may be, retarded, because it's almost always a big waste of time.
After looking at code like that for over two years, across several projects in several languages, I can say it's not as hard to read uncommented code as you make it out to be.
In fact, I often skip reading comments for the sheer fact that they're usually incorrect because they're either not maintained as the code is updated or were always wrong.Except for some extremely obscure pieces of code, generally revolving around optimizations, architecture-specific workarounds, compiler-bug workarounds, etc., have I ever found comments to be useful outside of documenting an API.
In point of fact, there will never be a comment stating more correctly what the code is doing than the code itself.As one caveat, I've seen good use of comments in ASM.
However, with the ability to use more advanced assembler features in GCC or LLVM these days, you can put pretty sophisticated names on your code-flow elements and not require nearly as many comments as in the past.
And with being able to inline ASM into code for those cases you need it, you can even use sophisticated meta-names for your registers that are obvious to the reader.
Also, being the fact that the only person that work on an optimized piece of code would be someone that already knows that architecture's ASM or can learn what they need, you can rest assured that they'll have all the tools necessary to read and modify your code.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620372</id>
	<title>Re:Does he think comments are pseudocode?</title>
	<author>Anonymous</author>
	<datestamp>1262465280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If your comments don't need to change when you change the way you do something then YOU are doing it wrong. You should be saying why you chose to do it that way and of you choose to change the way you do something then you should probably be saying:</p><p>1/  Why the obvious way you chose before doesn't work.</p><p>2/ Why you are doing it the new way.</p><p>Comments are to help someone else (or you in 2 years) understand the WHYs of the code. Especially the hidden ones, such as dependencies on other code.</p></htmltext>
<tokenext>If your comments do n't need to change when you change the way you do something then YOU are doing it wrong .
You should be saying why you chose to do it that way and of you choose to change the way you do something then you should probably be saying : 1/ Why the obvious way you chose before does n't work.2/ Why you are doing it the new way.Comments are to help someone else ( or you in 2 years ) understand the WHYs of the code .
Especially the hidden ones , such as dependencies on other code .</tokentext>
<sentencetext>If your comments don't need to change when you change the way you do something then YOU are doing it wrong.
You should be saying why you chose to do it that way and of you choose to change the way you do something then you should probably be saying:1/  Why the obvious way you chose before doesn't work.2/ Why you are doing it the new way.Comments are to help someone else (or you in 2 years) understand the WHYs of the code.
Especially the hidden ones, such as dependencies on other code.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616868</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621988</id>
	<title>There's no "myths" here...</title>
	<author>QuietLagoon</author>
	<datestamp>1262445300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Just someone trying to create a news story.<p>.<br>

The reality is that there are good comments and there are bad comments.  Good comments are helpful, bad comments are not.   I forgot to mention that there is a third type of comment, the evil ones.  The evil comments are wrong, leading subsequent programmers astray.</p></htmltext>
<tokenext>Just someone trying to create a news story. . The reality is that there are good comments and there are bad comments .
Good comments are helpful , bad comments are not .
I forgot to mention that there is a third type of comment , the evil ones .
The evil comments are wrong , leading subsequent programmers astray .</tokentext>
<sentencetext>Just someone trying to create a news story..

The reality is that there are good comments and there are bad comments.
Good comments are helpful, bad comments are not.
I forgot to mention that there is a third type of comment, the evil ones.
The evil comments are wrong, leading subsequent programmers astray.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617108</id>
	<title>Useful comment:</title>
	<author>Albert Sandberg</author>
	<datestamp>1262349060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>// Message below is written by an idiot, jsyk</p></htmltext>
<tokenext>// Message below is written by an idiot , jsyk</tokentext>
<sentencetext>// Message below is written by an idiot, jsyk</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617072</id>
	<title>I can answer that one!</title>
	<author>Zero\_\_Kelvin</author>
	<datestamp>1262348700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>"This is about as close to being a canonical "bad comment ", and yet people who should know better still do it. Why? Because they feel that they should document every function or class. The reality is that documenting something that needs no documentation is universally a bad idea."</p></div></blockquote><p>The reality is people might know more than you, and you are assuming that you are an uber-programmer when you are not!  Maybe the programmer is more qualified than you to write Python (the language the example is in in TFA) and uses pylint.  Maybe he doesn't want to sift through 272 warning messages to see which are important and which are superfluous, so he is consistent.  Maybe consistency is a good thing in the software domain.  Maybe he also wants every member method to be consistintly documented since docstrings are tied in memory to the object and available via <i>help(</i>object<i>)</i>.<br> <br>I am encouraged by most of the comments about comments here on Slashdot thus far.  Most people seem to get why comments are a good thing.  The author doesn't write them off completely of course, but he is not qualified to write this article either.  There is just too much he doesn't yet understand, and he would do well to ask these questions of a qualified software engineer rather than posing them as rhetorical, since in a lot of cases he doesn't know the answers but mistakenly thinks he does, as I have shown.<br> <br>There is a reason why language designers pretty much universally include a comment mechanism, and why that mechanism has been trending toward the docstring / formal approach away from the "willy nilly" techniques of old rather than removing  the ability to comment completely.</p></div>
	</htmltext>
<tokenext>" This is about as close to being a canonical " bad comment " , and yet people who should know better still do it .
Why ? Because they feel that they should document every function or class .
The reality is that documenting something that needs no documentation is universally a bad idea .
" The reality is people might know more than you , and you are assuming that you are an uber-programmer when you are not !
Maybe the programmer is more qualified than you to write Python ( the language the example is in in TFA ) and uses pylint .
Maybe he does n't want to sift through 272 warning messages to see which are important and which are superfluous , so he is consistent .
Maybe consistency is a good thing in the software domain .
Maybe he also wants every member method to be consistintly documented since docstrings are tied in memory to the object and available via help ( object ) .
I am encouraged by most of the comments about comments here on Slashdot thus far .
Most people seem to get why comments are a good thing .
The author does n't write them off completely of course , but he is not qualified to write this article either .
There is just too much he does n't yet understand , and he would do well to ask these questions of a qualified software engineer rather than posing them as rhetorical , since in a lot of cases he does n't know the answers but mistakenly thinks he does , as I have shown .
There is a reason why language designers pretty much universally include a comment mechanism , and why that mechanism has been trending toward the docstring / formal approach away from the " willy nilly " techniques of old rather than removing the ability to comment completely .</tokentext>
<sentencetext>"This is about as close to being a canonical "bad comment ", and yet people who should know better still do it.
Why? Because they feel that they should document every function or class.
The reality is that documenting something that needs no documentation is universally a bad idea.
"The reality is people might know more than you, and you are assuming that you are an uber-programmer when you are not!
Maybe the programmer is more qualified than you to write Python (the language the example is in in TFA) and uses pylint.
Maybe he doesn't want to sift through 272 warning messages to see which are important and which are superfluous, so he is consistent.
Maybe consistency is a good thing in the software domain.
Maybe he also wants every member method to be consistintly documented since docstrings are tied in memory to the object and available via help(object).
I am encouraged by most of the comments about comments here on Slashdot thus far.
Most people seem to get why comments are a good thing.
The author doesn't write them off completely of course, but he is not qualified to write this article either.
There is just too much he doesn't yet understand, and he would do well to ask these questions of a qualified software engineer rather than posing them as rhetorical, since in a lot of cases he doesn't know the answers but mistakenly thinks he does, as I have shown.
There is a reason why language designers pretty much universally include a comment mechanism, and why that mechanism has been trending toward the docstring / formal approach away from the "willy nilly" techniques of old rather than removing  the ability to comment completely.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618372</id>
	<title>Re:Wrong on all accounts</title>
	<author>digitig</author>
	<datestamp>1262356920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>And therein lies the problem.</p><p>There are two major problems:</p><p>1) As much as I would like to say that documentation helps, I actually don't think it helps unless you writing an API.  But even then I wonder. The real problem with documentation is that as much as we would like to keep it up to date, it does not happen. I personally would prefer modular code that works without tricks than code with comments and tricks.</p></div><p>Solution: rigorous peer review.</p><p><div class="quote"><p>2) The problem with comments is that it fails the psychological test. When I write something down it does not necessarily mean that another programmer is going to understand what I mean. The reason has to do with the words I choose and how I phrase things.</p></div><p>Solution: rigorous peer review.</p></div>
	</htmltext>
<tokenext>And therein lies the problem.There are two major problems : 1 ) As much as I would like to say that documentation helps , I actually do n't think it helps unless you writing an API .
But even then I wonder .
The real problem with documentation is that as much as we would like to keep it up to date , it does not happen .
I personally would prefer modular code that works without tricks than code with comments and tricks.Solution : rigorous peer review.2 ) The problem with comments is that it fails the psychological test .
When I write something down it does not necessarily mean that another programmer is going to understand what I mean .
The reason has to do with the words I choose and how I phrase things.Solution : rigorous peer review .</tokentext>
<sentencetext>And therein lies the problem.There are two major problems:1) As much as I would like to say that documentation helps, I actually don't think it helps unless you writing an API.
But even then I wonder.
The real problem with documentation is that as much as we would like to keep it up to date, it does not happen.
I personally would prefer modular code that works without tricks than code with comments and tricks.Solution: rigorous peer review.2) The problem with comments is that it fails the psychological test.
When I write something down it does not necessarily mean that another programmer is going to understand what I mean.
The reason has to do with the words I choose and how I phrase things.Solution: rigorous peer review.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616880</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617966</id>
	<title>Re:Strongly RESTRICT Code Commenting</title>
	<author>Xugumad</author>
	<datestamp>1262354760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Okay, so lets talk some of the code I have to deal with on a day to day basis...</p><p>int getGradeSourceHumanPosition(int sourceID)</p><p>What does that do? What's a source ID? What does human position mean? That's a method in an API, as listed. We argue over this a lot, but I maintain that it's essentially impossible for the initial developer to understand what someone coming to the API later on will find confusing, and at the very least exposed methods need to be documented...</p></htmltext>
<tokenext>Okay , so lets talk some of the code I have to deal with on a day to day basis...int getGradeSourceHumanPosition ( int sourceID ) What does that do ?
What 's a source ID ?
What does human position mean ?
That 's a method in an API , as listed .
We argue over this a lot , but I maintain that it 's essentially impossible for the initial developer to understand what someone coming to the API later on will find confusing , and at the very least exposed methods need to be documented.. .</tokentext>
<sentencetext>Okay, so lets talk some of the code I have to deal with on a day to day basis...int getGradeSourceHumanPosition(int sourceID)What does that do?
What's a source ID?
What does human position mean?
That's a method in an API, as listed.
We argue over this a lot, but I maintain that it's essentially impossible for the initial developer to understand what someone coming to the API later on will find confusing, and at the very least exposed methods need to be documented...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617052</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30623824</id>
	<title>Verbose variables</title>
	<author>4D6963</author>
	<datestamp>1262457000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Slightly off-topic : what annoys me most is being asked to use very verbose variable names (think 20+ characters), because it supposedly makes it more readable. That's utter bullshit, and the people who ask me this never did anything very complicated. It's much harder to juggle with a bunch of long variables than to juggle with two-letter variables. I prefer to use short variable names and comment them in a block at the beginning of the function.

</p><p>That's the very reason why mathematicians use one-letter 'variable' names. Think about it.</p></htmltext>
<tokenext>Slightly off-topic : what annoys me most is being asked to use very verbose variable names ( think 20 + characters ) , because it supposedly makes it more readable .
That 's utter bullshit , and the people who ask me this never did anything very complicated .
It 's much harder to juggle with a bunch of long variables than to juggle with two-letter variables .
I prefer to use short variable names and comment them in a block at the beginning of the function .
That 's the very reason why mathematicians use one-letter 'variable ' names .
Think about it .</tokentext>
<sentencetext>Slightly off-topic : what annoys me most is being asked to use very verbose variable names (think 20+ characters), because it supposedly makes it more readable.
That's utter bullshit, and the people who ask me this never did anything very complicated.
It's much harder to juggle with a bunch of long variables than to juggle with two-letter variables.
I prefer to use short variable names and comment them in a block at the beginning of the function.
That's the very reason why mathematicians use one-letter 'variable' names.
Think about it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616976</id>
	<title>Re:Wrong on all accounts</title>
	<author>Nerdfest</author>
	<datestamp>1262347800000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>You shouldn't need to decipher the code. Most of the problem is not the missing documentation, but the poorly written code.</htmltext>
<tokenext>You should n't need to decipher the code .
Most of the problem is not the missing documentation , but the poorly written code .</tokentext>
<sentencetext>You shouldn't need to decipher the code.
Most of the problem is not the missing documentation, but the poorly written code.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619146</id>
	<title>Sam I am!</title>
	<author>DomNF15</author>
	<datestamp>1262363400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I like the comparison to literature and how it illustrates personal preferences, but respectfully disagree with the idea that literature will all eventually converge into very short, efficient, single purpose works.  The entire point of literature is to convey some theme(s) through the medium of a story.  Stories are not meant to be efficient or singular in purpose or meaning, necessarily.  When you read a book, you are along for whatever ride the author wishes to take you on.  And it is exactly that ride, not some re-factored or boiled down version, that he/she wants to experience.  If you've ever read Cliffnotes instead of an original text, you'll understand.  I don't think all literature needs to be more "readable", sometimes it's ok for something to be a little beyond your comfort threshold, it makes your brain work just a little harder, and I think that's a good thing.  Unless of course you want all books to read like Green Eggs and Ham<nobr> <wbr></nobr>:-)</htmltext>
<tokenext>I like the comparison to literature and how it illustrates personal preferences , but respectfully disagree with the idea that literature will all eventually converge into very short , efficient , single purpose works .
The entire point of literature is to convey some theme ( s ) through the medium of a story .
Stories are not meant to be efficient or singular in purpose or meaning , necessarily .
When you read a book , you are along for whatever ride the author wishes to take you on .
And it is exactly that ride , not some re-factored or boiled down version , that he/she wants to experience .
If you 've ever read Cliffnotes instead of an original text , you 'll understand .
I do n't think all literature needs to be more " readable " , sometimes it 's ok for something to be a little beyond your comfort threshold , it makes your brain work just a little harder , and I think that 's a good thing .
Unless of course you want all books to read like Green Eggs and Ham : - )</tokentext>
<sentencetext>I like the comparison to literature and how it illustrates personal preferences, but respectfully disagree with the idea that literature will all eventually converge into very short, efficient, single purpose works.
The entire point of literature is to convey some theme(s) through the medium of a story.
Stories are not meant to be efficient or singular in purpose or meaning, necessarily.
When you read a book, you are along for whatever ride the author wishes to take you on.
And it is exactly that ride, not some re-factored or boiled down version, that he/she wants to experience.
If you've ever read Cliffnotes instead of an original text, you'll understand.
I don't think all literature needs to be more "readable", sometimes it's ok for something to be a little beyond your comfort threshold, it makes your brain work just a little harder, and I think that's a good thing.
Unless of course you want all books to read like Green Eggs and Ham :-)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616776</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617082</id>
	<title>Re:Does he think comments are pseudocode?</title>
	<author>Arimus</author>
	<datestamp>1262348760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Depends, if you are using doxygen style comments and change the function header then the comment changes...</p></htmltext>
<tokenext>Depends , if you are using doxygen style comments and change the function header then the comment changes.. .</tokentext>
<sentencetext>Depends, if you are using doxygen style comments and change the function header then the comment changes...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616868</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619360</id>
	<title>Re:Wrong on all accounts</title>
	<author>Thing 1</author>
	<datestamp>1262365800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>The real problem with documentation is that as much as we would like to keep it up to date, it does not happen. I personally would prefer modular code that works without tricks than code with comments and tricks.</p></div>
</blockquote><p>It sounds like you would prefer unit tests that function, in place of comments.</p><p>I don't disagree -- although useful comments would be a helpful addition...</p></div>
	</htmltext>
<tokenext>The real problem with documentation is that as much as we would like to keep it up to date , it does not happen .
I personally would prefer modular code that works without tricks than code with comments and tricks .
It sounds like you would prefer unit tests that function , in place of comments.I do n't disagree -- although useful comments would be a helpful addition.. .</tokentext>
<sentencetext>The real problem with documentation is that as much as we would like to keep it up to date, it does not happen.
I personally would prefer modular code that works without tricks than code with comments and tricks.
It sounds like you would prefer unit tests that function, in place of comments.I don't disagree -- although useful comments would be a helpful addition...
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616880</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962</id>
	<title>Re:Has No One Actually Studied This?</title>
	<author>tomhath</author>
	<datestamp>1262347680000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>A former employer (a very big multinational corporation) did a study that tried to correlate the number of comments in code to the number of problem reports against it. Not surprising to me, they found that in general the more comments in the code, the more problems were reported against it. That was my observation as well; bad programmers couldn't figure out a straightforward solution to a problem so they wrote messy code with lots of comments trying to explain what they were doing. The really good programmers  wrote simple clean code that only needed a few comments.</p><p>Another characteristic of bad programmers that I noticed was their tendency to keep copying data from one data structure to another instead of using it in place. Obviously an indication of bad design, and it introduced lots of bugs. You knew as soon as you opened a source file and saw comments like "Copy blah-blah data from abc array to xyz array" that you were in trouble.</p></htmltext>
<tokenext>A former employer ( a very big multinational corporation ) did a study that tried to correlate the number of comments in code to the number of problem reports against it .
Not surprising to me , they found that in general the more comments in the code , the more problems were reported against it .
That was my observation as well ; bad programmers could n't figure out a straightforward solution to a problem so they wrote messy code with lots of comments trying to explain what they were doing .
The really good programmers wrote simple clean code that only needed a few comments.Another characteristic of bad programmers that I noticed was their tendency to keep copying data from one data structure to another instead of using it in place .
Obviously an indication of bad design , and it introduced lots of bugs .
You knew as soon as you opened a source file and saw comments like " Copy blah-blah data from abc array to xyz array " that you were in trouble .</tokentext>
<sentencetext>A former employer (a very big multinational corporation) did a study that tried to correlate the number of comments in code to the number of problem reports against it.
Not surprising to me, they found that in general the more comments in the code, the more problems were reported against it.
That was my observation as well; bad programmers couldn't figure out a straightforward solution to a problem so they wrote messy code with lots of comments trying to explain what they were doing.
The really good programmers  wrote simple clean code that only needed a few comments.Another characteristic of bad programmers that I noticed was their tendency to keep copying data from one data structure to another instead of using it in place.
Obviously an indication of bad design, and it introduced lots of bugs.
You knew as soon as you opened a source file and saw comments like "Copy blah-blah data from abc array to xyz array" that you were in trouble.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617038</id>
	<title>Employment prospects</title>
	<author>paylett</author>
	<datestamp>1262348400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This, in an age when prospective employers are known to check out candidates blogs. Entertaining.</htmltext>
<tokenext>This , in an age when prospective employers are known to check out candidates blogs .
Entertaining .</tokentext>
<sentencetext>This, in an age when prospective employers are known to check out candidates blogs.
Entertaining.</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619942
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_51</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616976
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621636
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_53</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616936
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618302
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617052
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618632
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_99</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618320
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_52</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616696
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616748
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621112
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616770
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617308
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621434
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618738
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_103</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616770
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617014
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617782
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_77</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616872
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617196
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618486
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617380
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619628
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_102</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617380
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618106
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618942
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_80</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617380
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617760
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_71</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619960
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_94</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617552
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617380
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620578
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_68</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616936
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30625112
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_70</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616936
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620210
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616776
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619146
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617060
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_58</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617052
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618620
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_63</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616810
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30626218
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618630
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_65</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616872
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617264
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618664
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_86</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616868
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620372
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617052
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617966
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620020
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_101</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30623060
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616770
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617240
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_93</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619162
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618464
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_89</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619266
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_92</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616836
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622518
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_83</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618080
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_66</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619326
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_57</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621266
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_60</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616872
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617120
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620898
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_56</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617052
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618414
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618610
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616696
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616748
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619206
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_50</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621850
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616836
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617182
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616696
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620940
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_84</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616836
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618546
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_75</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619360
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618778
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_98</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619470
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616776
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617022
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_91</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618372
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_74</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616776
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621404
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_48</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616836
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617030
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620922
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_76</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618534
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618724
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617380
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619428
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_81</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616868
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617188
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_55</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616696
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617176
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617800
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619292
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618474
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30630790
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_69</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616920
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618444
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622044
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620018
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_97</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619838
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616846
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617636
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616836
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617030
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617588
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_73</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616696
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_96</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616770
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617140
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_87</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30665132
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618032
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_100</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620278
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619562
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616868
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30646222
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_67</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616770
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617308
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30624008
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619610
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616776
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617126
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_61</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617402
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617380
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622364
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617380
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620276
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616836
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618118
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_95</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616770
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617430
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621336
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617190
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30623250
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_85</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616920
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618564
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616832
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_59</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617052
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618520
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_62</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617592
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_90</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30625366
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_64</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616770
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617056
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619218
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_49</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616868
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617082
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616936
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618484
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616696
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616748
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622486
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619952
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621108
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_54</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616770
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621864
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616854
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30623824
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30626524
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_88</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616696
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618680
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_79</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30623756
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616872
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617336
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_82</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616776
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30654974
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_78</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616836
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617030
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617512
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616770
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620052
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_01_01_226232_72</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621720
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616696
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616748
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622486
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621112
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619206
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616750
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618680
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617176
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617800
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619292
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616984
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620940
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620962
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617158
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616872
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617336
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617196
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617264
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618664
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617120
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617520
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617108
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617218
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622474
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616804
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616836
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617182
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618546
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618118
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622518
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617030
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617512
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617588
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620922
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618506
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617238
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618350
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617052
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618620
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618414
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617966
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618632
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618520
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616932
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621720
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621266
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620020
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619960
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30623756
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619942
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617636
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619162
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620898
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618464
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30665132
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622044
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617592
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618738
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618474
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30630790
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619610
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621336
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620176
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616776
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621404
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617126
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619146
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30654974
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617022
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616920
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618564
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618444
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616936
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620210
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618302
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30625112
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618484
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617190
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30623250
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617884
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616728
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30623060
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616846
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618630
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616810
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30626218
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616976
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621636
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619952
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621108
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616880
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618372
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619360
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620018
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616832
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619470
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618032
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30625366
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618320
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30623824
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30626524
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617380
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30622364
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620276
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619628
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617760
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619428
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618106
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618942
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620578
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617038
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617274
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616770
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617140
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620052
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617014
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621864
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617056
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619218
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617308
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30624008
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621434
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617430
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617240
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619350
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616868
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617188
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620372
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617082
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30646222
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616762
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616854
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617060
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618610
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619562
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619266
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617402
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30616962
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618486
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619838
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30619326
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30620278
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30621850
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618080
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618778
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617552
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617782
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618534
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30618724
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_01_01_226232.27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_01_01_226232.30617682
</commentlist>
</conversation>
