<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_12_06_1456251</id>
	<title>Defining Useful Coding Practices?</title>
	<author>Soulskill</author>
	<datestamp>1260114840000</datestamp>
	<htmltext>markmcb writes <i>"A NASA engineer recently wrote about his disappointment that despite having well-documented coding practices, <a href="http://www.omninerd.com/articles/Coding\_Practices">'clever' solutions still made the code he has to maintain hard to follow</a>.  This got me thinking about the overhead spent at my own company regarding our code.  We too have best practices that are documented, but most seem to focus on the basics, e.g., comments, modularity, etc.  While those things are good, they don't directly ensure that quality, maintainable code is written.  As the author points out, an elegant one-liner coupled with a comment from a few revisions ago makes for a good headache.  I'm curious what experience others have had with this, and if you've seen manageable practices that ultimately offer a lot of value to the next programmer down the line who will have to maintain the code."</i></htmltext>
<tokenext>markmcb writes " A NASA engineer recently wrote about his disappointment that despite having well-documented coding practices , 'clever ' solutions still made the code he has to maintain hard to follow .
This got me thinking about the overhead spent at my own company regarding our code .
We too have best practices that are documented , but most seem to focus on the basics , e.g. , comments , modularity , etc .
While those things are good , they do n't directly ensure that quality , maintainable code is written .
As the author points out , an elegant one-liner coupled with a comment from a few revisions ago makes for a good headache .
I 'm curious what experience others have had with this , and if you 've seen manageable practices that ultimately offer a lot of value to the next programmer down the line who will have to maintain the code .
"</tokentext>
<sentencetext>markmcb writes "A NASA engineer recently wrote about his disappointment that despite having well-documented coding practices, 'clever' solutions still made the code he has to maintain hard to follow.
This got me thinking about the overhead spent at my own company regarding our code.
We too have best practices that are documented, but most seem to focus on the basics, e.g., comments, modularity, etc.
While those things are good, they don't directly ensure that quality, maintainable code is written.
As the author points out, an elegant one-liner coupled with a comment from a few revisions ago makes for a good headache.
I'm curious what experience others have had with this, and if you've seen manageable practices that ultimately offer a lot of value to the next programmer down the line who will have to maintain the code.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343688</id>
	<title>The same logic isn't common in everyone</title>
	<author>techhead79</author>
	<datestamp>1260120600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>As we all know just about every coder has their own way of doing things. Each person has found the solution to common programming steps differently. This flow of logic is carried over to larger programs and new logic that must be considered to answer more complex coding problems. There is no one way to write a program and this means there are a thousand different ways each person could come up with the logic paths to answer the question. Clever cures boredom and does what every programmer should be doing...making their program more efficient....<br> <br>

What makes sense to one person is a combination of how they answered similar problems and other coder's answer to similar problems. There are many hacks in the industry that cause a lot of problems for code readability. They are not clever, they are the other extreme where they barely understand what is even going on. Any real coder though can see the difference between being clever and being a hack, it usually involves comments carried over from what program they gutted to get their's to work. I think it's important to separate those two types of problems.<br> <br>

Once you take out the hacks you should be able to see how any coder reached the logic they did. Rewrites because of logic doesn't just stand at the one coder required to maintain class xyz. Shit falls down hill. If the overall design is flawed, if the requirements are not clearly outlined, if someone high up keeps changing their mind..then the coder at the bottom of the hill doesn't stand a chance at writing long term good code. Anyone that's worked in a project knows there is this odd relationship that forms. You have the heavy coders, you have the logic gurus looking at the bigger picture and delegating, you have the do what you cans that are left the scraps after the heavy coders get their work, you have the project leaders which hopefully will be writing code too, you have the project owners that write no code, you have the upper management barking orders. There isn't just 1 person responsible for good code even if there is just 1 person writing it.</htmltext>
<tokenext>As we all know just about every coder has their own way of doing things .
Each person has found the solution to common programming steps differently .
This flow of logic is carried over to larger programs and new logic that must be considered to answer more complex coding problems .
There is no one way to write a program and this means there are a thousand different ways each person could come up with the logic paths to answer the question .
Clever cures boredom and does what every programmer should be doing...making their program more efficient... . What makes sense to one person is a combination of how they answered similar problems and other coder 's answer to similar problems .
There are many hacks in the industry that cause a lot of problems for code readability .
They are not clever , they are the other extreme where they barely understand what is even going on .
Any real coder though can see the difference between being clever and being a hack , it usually involves comments carried over from what program they gutted to get their 's to work .
I think it 's important to separate those two types of problems .
Once you take out the hacks you should be able to see how any coder reached the logic they did .
Rewrites because of logic does n't just stand at the one coder required to maintain class xyz .
Shit falls down hill .
If the overall design is flawed , if the requirements are not clearly outlined , if someone high up keeps changing their mind..then the coder at the bottom of the hill does n't stand a chance at writing long term good code .
Anyone that 's worked in a project knows there is this odd relationship that forms .
You have the heavy coders , you have the logic gurus looking at the bigger picture and delegating , you have the do what you cans that are left the scraps after the heavy coders get their work , you have the project leaders which hopefully will be writing code too , you have the project owners that write no code , you have the upper management barking orders .
There is n't just 1 person responsible for good code even if there is just 1 person writing it .</tokentext>
<sentencetext>As we all know just about every coder has their own way of doing things.
Each person has found the solution to common programming steps differently.
This flow of logic is carried over to larger programs and new logic that must be considered to answer more complex coding problems.
There is no one way to write a program and this means there are a thousand different ways each person could come up with the logic paths to answer the question.
Clever cures boredom and does what every programmer should be doing...making their program more efficient.... 

What makes sense to one person is a combination of how they answered similar problems and other coder's answer to similar problems.
There are many hacks in the industry that cause a lot of problems for code readability.
They are not clever, they are the other extreme where they barely understand what is even going on.
Any real coder though can see the difference between being clever and being a hack, it usually involves comments carried over from what program they gutted to get their's to work.
I think it's important to separate those two types of problems.
Once you take out the hacks you should be able to see how any coder reached the logic they did.
Rewrites because of logic doesn't just stand at the one coder required to maintain class xyz.
Shit falls down hill.
If the overall design is flawed, if the requirements are not clearly outlined, if someone high up keeps changing their mind..then the coder at the bottom of the hill doesn't stand a chance at writing long term good code.
Anyone that's worked in a project knows there is this odd relationship that forms.
You have the heavy coders, you have the logic gurus looking at the bigger picture and delegating, you have the do what you cans that are left the scraps after the heavy coders get their work, you have the project leaders which hopefully will be writing code too, you have the project owners that write no code, you have the upper management barking orders.
There isn't just 1 person responsible for good code even if there is just 1 person writing it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343764</id>
	<title>The only thing which counts for businesses</title>
	<author>kipsate</author>
	<datestamp>1260121140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>is releasing new functionality as quickly as possible. Timelines counts, not code quality.
<br> <br>
One of the classic arguments between manager and coder is about how much time should be invested in cleaner code, since, as most coders would argue, such investment earns itself back because new features can be implemented faster when having a nice and tidy code base.
<br> <br>
Managers of course often get their ways and coders reluctantly give in, mumbling about code becoming unmaintainable.
<br> <br>
Investing in code quality is indeed risky:
<br> <br>
 - Even despite poor code quality, the coders know their stuff and implement new functionality without any problems;<br>
 - After investing in code cleanups it may soon turn out that this particular functionality is no longer required and all this nice and tidy code has been developed for nothing;<br>
 - "Cleanups" may end up in overly complicated code which turns out to be even more difficult to maintain than the original code base.</htmltext>
<tokenext>is releasing new functionality as quickly as possible .
Timelines counts , not code quality .
One of the classic arguments between manager and coder is about how much time should be invested in cleaner code , since , as most coders would argue , such investment earns itself back because new features can be implemented faster when having a nice and tidy code base .
Managers of course often get their ways and coders reluctantly give in , mumbling about code becoming unmaintainable .
Investing in code quality is indeed risky : - Even despite poor code quality , the coders know their stuff and implement new functionality without any problems ; - After investing in code cleanups it may soon turn out that this particular functionality is no longer required and all this nice and tidy code has been developed for nothing ; - " Cleanups " may end up in overly complicated code which turns out to be even more difficult to maintain than the original code base .</tokentext>
<sentencetext>is releasing new functionality as quickly as possible.
Timelines counts, not code quality.
One of the classic arguments between manager and coder is about how much time should be invested in cleaner code, since, as most coders would argue, such investment earns itself back because new features can be implemented faster when having a nice and tidy code base.
Managers of course often get their ways and coders reluctantly give in, mumbling about code becoming unmaintainable.
Investing in code quality is indeed risky:
 
 - Even despite poor code quality, the coders know their stuff and implement new functionality without any problems;
 - After investing in code cleanups it may soon turn out that this particular functionality is no longer required and all this nice and tidy code has been developed for nothing;
 - "Cleanups" may end up in overly complicated code which turns out to be even more difficult to maintain than the original code base.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345338</id>
	<title>Re:Literate Programming</title>
	<author>noidentity</author>
	<datestamp>1260133020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>A program is simply a precise specification of exactly what we want done. The reason we have to give so many details is that there are that many degrees of freedom. Even if we write up a requirements document, it still leaves details out; it's not some deficiency of the programming language that we have to specify details.

<p>We always have flexibility in exactly what is done that will still meet our needs, for example I don't care whether the file is copied 512 bytes at a time or 32768 bytes at a time, or what the variable names in the source code are. Within this flexibility we can choose a way of doing things that makes the program easy for a human to make sense of as well.

</p><p>And then there are comments, not executable and thus not testable. They should represent things that can't be tested or don't need to be, like the reasons for doing something a particular way.</p></htmltext>
<tokenext>A program is simply a precise specification of exactly what we want done .
The reason we have to give so many details is that there are that many degrees of freedom .
Even if we write up a requirements document , it still leaves details out ; it 's not some deficiency of the programming language that we have to specify details .
We always have flexibility in exactly what is done that will still meet our needs , for example I do n't care whether the file is copied 512 bytes at a time or 32768 bytes at a time , or what the variable names in the source code are .
Within this flexibility we can choose a way of doing things that makes the program easy for a human to make sense of as well .
And then there are comments , not executable and thus not testable .
They should represent things that ca n't be tested or do n't need to be , like the reasons for doing something a particular way .</tokentext>
<sentencetext>A program is simply a precise specification of exactly what we want done.
The reason we have to give so many details is that there are that many degrees of freedom.
Even if we write up a requirements document, it still leaves details out; it's not some deficiency of the programming language that we have to specify details.
We always have flexibility in exactly what is done that will still meet our needs, for example I don't care whether the file is copied 512 bytes at a time or 32768 bytes at a time, or what the variable names in the source code are.
Within this flexibility we can choose a way of doing things that makes the program easy for a human to make sense of as well.
And then there are comments, not executable and thus not testable.
They should represent things that can't be tested or don't need to be, like the reasons for doing something a particular way.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346520</id>
	<title>Re:Literate Programming</title>
	<author>fabs64</author>
	<datestamp>1260098760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Your argument seems to be predicated on the idea that I can somehow sacrifice precision for readability and give the computer an ambiguous instruction. I can't. Computers remain deterministic no matter what my coding style.</p></htmltext>
<tokenext>Your argument seems to be predicated on the idea that I can somehow sacrifice precision for readability and give the computer an ambiguous instruction .
I ca n't .
Computers remain deterministic no matter what my coding style .</tokentext>
<sentencetext>Your argument seems to be predicated on the idea that I can somehow sacrifice precision for readability and give the computer an ambiguous instruction.
I can't.
Computers remain deterministic no matter what my coding style.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343778</id>
	<title>The solution to bad comments is good comments</title>
	<author>Anonymous</author>
	<datestamp>1260121200000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>There is no such thing as self-documenting code.  A block of code without comments, no matter how well-written, is an order of magnitude slower to work with than code with just a couple of sentences at the top explaining what is going on and why.  I find this "comments are always out-of-date anyway" argument baffling.  If that's the problem, then the solution is to make keeping comments up-to-date a key part of the requirements, not to omit them entirely.</p><p>If someone lacks the discipline or intelligence to update a simple sentence after making a change, then their 'self-documenting code' is not something I ever want to see.</p></htmltext>
<tokenext>There is no such thing as self-documenting code .
A block of code without comments , no matter how well-written , is an order of magnitude slower to work with than code with just a couple of sentences at the top explaining what is going on and why .
I find this " comments are always out-of-date anyway " argument baffling .
If that 's the problem , then the solution is to make keeping comments up-to-date a key part of the requirements , not to omit them entirely.If someone lacks the discipline or intelligence to update a simple sentence after making a change , then their 'self-documenting code ' is not something I ever want to see .</tokentext>
<sentencetext>There is no such thing as self-documenting code.
A block of code without comments, no matter how well-written, is an order of magnitude slower to work with than code with just a couple of sentences at the top explaining what is going on and why.
I find this "comments are always out-of-date anyway" argument baffling.
If that's the problem, then the solution is to make keeping comments up-to-date a key part of the requirements, not to omit them entirely.If someone lacks the discipline or intelligence to update a simple sentence after making a change, then their 'self-documenting code' is not something I ever want to see.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343708</id>
	<title>Re:"elegant code" overhead coefficient</title>
	<author>Anonymous</author>
	<datestamp>1260120720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>And I've wasted hours figuring out how object oriented "patterns" are supposed to work.  Spent extra time to get it "loaded" into my mind.  It's a huge waste of effort, institutionalized, because your typical developer can't handle straightforward abstractions like simple function definition.</p><p>I had one peer tell me to use a factory pattern instead of using "map".  Stupid.  It's a functor either way, and one of them is actually readable, keeps the algorithmic code together, and separate from the data code.  Even better, the functional arguments to map form a monad, so (most importantly) I can keep calling list functions on the resulting lists.  Big win for readability.  For exampmle:</p><p>sort $ map {runMethod . dispatch\_constructor} list\_of\_symbols</p><p>The factory pattern makes some assumptions about code.  The functional code <i>codifies</i> our assumptions.  It makes them clear.</p><p>Some OO patterns are so elegant they are just ontologically nasty.  Yes, it is clever to pass around an object that represent behaviors for other classes to use.  Great.  Is that how you thought of objects when you first started?  What kind of cognitive overhead is there for abusing the notion of an object, and coming up with a weird type system of patterns to combine?</p></htmltext>
<tokenext>And I 've wasted hours figuring out how object oriented " patterns " are supposed to work .
Spent extra time to get it " loaded " into my mind .
It 's a huge waste of effort , institutionalized , because your typical developer ca n't handle straightforward abstractions like simple function definition.I had one peer tell me to use a factory pattern instead of using " map " .
Stupid. It 's a functor either way , and one of them is actually readable , keeps the algorithmic code together , and separate from the data code .
Even better , the functional arguments to map form a monad , so ( most importantly ) I can keep calling list functions on the resulting lists .
Big win for readability .
For exampmle : sort $ map { runMethod .
dispatch \ _constructor } list \ _of \ _symbolsThe factory pattern makes some assumptions about code .
The functional code codifies our assumptions .
It makes them clear.Some OO patterns are so elegant they are just ontologically nasty .
Yes , it is clever to pass around an object that represent behaviors for other classes to use .
Great. Is that how you thought of objects when you first started ?
What kind of cognitive overhead is there for abusing the notion of an object , and coming up with a weird type system of patterns to combine ?</tokentext>
<sentencetext>And I've wasted hours figuring out how object oriented "patterns" are supposed to work.
Spent extra time to get it "loaded" into my mind.
It's a huge waste of effort, institutionalized, because your typical developer can't handle straightforward abstractions like simple function definition.I had one peer tell me to use a factory pattern instead of using "map".
Stupid.  It's a functor either way, and one of them is actually readable, keeps the algorithmic code together, and separate from the data code.
Even better, the functional arguments to map form a monad, so (most importantly) I can keep calling list functions on the resulting lists.
Big win for readability.
For exampmle:sort $ map {runMethod .
dispatch\_constructor} list\_of\_symbolsThe factory pattern makes some assumptions about code.
The functional code codifies our assumptions.
It makes them clear.Some OO patterns are so elegant they are just ontologically nasty.
Yes, it is clever to pass around an object that represent behaviors for other classes to use.
Great.  Is that how you thought of objects when you first started?
What kind of cognitive overhead is there for abusing the notion of an object, and coming up with a weird type system of patterns to combine?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343542</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346430</id>
	<title>Re:Canonical examples of chutzpah?</title>
	<author>maxume</author>
	<datestamp>1260098280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Slashcode actually does a pretty good job of inferring intent when using plaintext mode (so two line-end characters in a row get interpreted as a paragraph), but if you really want to use html, why not use it correctly and just put in a &lt;p&gt;?
</p><p>
Or am I missing sum bizarre subtlety in your post?
</p><p>(there is even some sort of tidy functionality that closes tags and things...)</p></htmltext>
<tokenext>Slashcode actually does a pretty good job of inferring intent when using plaintext mode ( so two line-end characters in a row get interpreted as a paragraph ) , but if you really want to use html , why not use it correctly and just put in a ?
Or am I missing sum bizarre subtlety in your post ?
( there is even some sort of tidy functionality that closes tags and things... )</tokentext>
<sentencetext>Slashcode actually does a pretty good job of inferring intent when using plaintext mode (so two line-end characters in a row get interpreted as a paragraph), but if you really want to use html, why not use it correctly and just put in a ?
Or am I missing sum bizarre subtlety in your post?
(there is even some sort of tidy functionality that closes tags and things...)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345654</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30351138</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>rakslice</author>
	<datestamp>1260187860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You realize we're talking about C here, right?</p></htmltext>
<tokenext>You realize we 're talking about C here , right ?</tokentext>
<sentencetext>You realize we're talking about C here, right?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344966</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346636</id>
	<title>Code maintenance is an intractable problem</title>
	<author>mstrebe</author>
	<datestamp>1260099420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Exceptional programmers write code. They can't--can not--be paid to maintain the code of other people. They leave. They find other opportunities where their prowess and ability to think in code is appreciated.</p><p>Mediocre programmers take any job they can get. They pore over the cryptic codex's of their thoughtful predecessors like acolytes transcribing the utterances of prophets. Their most important talent is that they stay.</p><p>Code maintenance, therefore, is a non-starter. Architects and Engineers build buildings, and plumbers maintain them. Plumbers can fix a leak, but it'll take a while and everything will have gotten wet. They certainly can't re-engineer a chilled water delivery system to meet new building code requirements or calculate the pipe required to handle superheated steam.</p><p>Extending the purpose or function of an application isn't "maintenance". It's re-design. It takes engineers, not plumbers.</p><p>There's no amount of dumbing down that stupid can't be baffled by, but harnessing your Arabians to oxcarts will guarantee that your software never ships in the first place.</p><p>I find it surprising that this isn't obvious to anyone who knows a decent programmer.</p></htmltext>
<tokenext>Exceptional programmers write code .
They ca n't--can not--be paid to maintain the code of other people .
They leave .
They find other opportunities where their prowess and ability to think in code is appreciated.Mediocre programmers take any job they can get .
They pore over the cryptic codex 's of their thoughtful predecessors like acolytes transcribing the utterances of prophets .
Their most important talent is that they stay.Code maintenance , therefore , is a non-starter .
Architects and Engineers build buildings , and plumbers maintain them .
Plumbers can fix a leak , but it 'll take a while and everything will have gotten wet .
They certainly ca n't re-engineer a chilled water delivery system to meet new building code requirements or calculate the pipe required to handle superheated steam.Extending the purpose or function of an application is n't " maintenance " .
It 's re-design .
It takes engineers , not plumbers.There 's no amount of dumbing down that stupid ca n't be baffled by , but harnessing your Arabians to oxcarts will guarantee that your software never ships in the first place.I find it surprising that this is n't obvious to anyone who knows a decent programmer .</tokentext>
<sentencetext>Exceptional programmers write code.
They can't--can not--be paid to maintain the code of other people.
They leave.
They find other opportunities where their prowess and ability to think in code is appreciated.Mediocre programmers take any job they can get.
They pore over the cryptic codex's of their thoughtful predecessors like acolytes transcribing the utterances of prophets.
Their most important talent is that they stay.Code maintenance, therefore, is a non-starter.
Architects and Engineers build buildings, and plumbers maintain them.
Plumbers can fix a leak, but it'll take a while and everything will have gotten wet.
They certainly can't re-engineer a chilled water delivery system to meet new building code requirements or calculate the pipe required to handle superheated steam.Extending the purpose or function of an application isn't "maintenance".
It's re-design.
It takes engineers, not plumbers.There's no amount of dumbing down that stupid can't be baffled by, but harnessing your Arabians to oxcarts will guarantee that your software never ships in the first place.I find it surprising that this isn't obvious to anyone who knows a decent programmer.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345348</id>
	<title>Re:Literate Programming</title>
	<author>nidarus</author>
	<datestamp>1260133080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>One must not compromise the precision of the orders it gives to the computer in order to achieve readability by something/someone else than the computer.</p></div><p>Every time you use a programming language, as opposed to assembly or straight machine code, you're doing just that.</p></div>
	</htmltext>
<tokenext>One must not compromise the precision of the orders it gives to the computer in order to achieve readability by something/someone else than the computer.Every time you use a programming language , as opposed to assembly or straight machine code , you 're doing just that .</tokentext>
<sentencetext>One must not compromise the precision of the orders it gives to the computer in order to achieve readability by something/someone else than the computer.Every time you use a programming language, as opposed to assembly or straight machine code, you're doing just that.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30385964</id>
	<title>Re:Too MUCH of this</title>
	<author>Anonymous</author>
	<datestamp>1260439260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I hope you realize that i = i++; is just bad code.  The ++ operator has a self-storage function to it. i++ means i = i+1;  You do not need the i = in front. It is just i++;</p></htmltext>
<tokenext>I hope you realize that i = i + + ; is just bad code .
The + + operator has a self-storage function to it .
i + + means i = i + 1 ; You do not need the i = in front .
It is just i + + ;</tokentext>
<sentencetext>I hope you realize that i = i++; is just bad code.
The ++ operator has a self-storage function to it.
i++ means i = i+1;  You do not need the i = in front.
It is just i++;</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343900</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30352696</id>
	<title>Re:Subs and functions</title>
	<author>Anonymous</author>
	<datestamp>1260199920000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>A person whose code I regularly inherit seems to hate functions. He just writes subs with no parameters and uses global variables to pass information to and from them. It's awesome...</p></div><p>It's called "RPG".</p></div>
	</htmltext>
<tokenext>A person whose code I regularly inherit seems to hate functions .
He just writes subs with no parameters and uses global variables to pass information to and from them .
It 's awesome...It 's called " RPG " .</tokentext>
<sentencetext>A person whose code I regularly inherit seems to hate functions.
He just writes subs with no parameters and uses global variables to pass information to and from them.
It's awesome...It's called "RPG".
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343546</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345358</id>
	<title>Where is the processing?</title>
	<author>Zero\_\_Kelvin</author>
	<datestamp>1260133140000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><tt>for(ss = s-&gt;ss; ss; ss = ss-&gt;ss);</tt> <br> <br>The semicolon at the end means the loop is only "processing" in the middle statement.  Testing to see if <tt>ss</tt> is NULL does not processing make.  Either he took liberties and left out the loop payload, or he still missed something and still doesn't understand it.  It is true that in an embedded system, merely reading an address can have side effects, for example reading a register can cause hardware to perform actions, etc., and maybe that is what is what is going on here, but I doubt that is the case here since the addresses would have to be pointers to other registers and registers themselves at the same time (though it is still conceivable.)<br> <br>I believe he meant to write:<tt>
for(ss = s-&gt;ss; ss; ss = ss-&gt;ss) { <i>[some kind of processing here]</i> };</tt>, but that is not what was written, which is ironic in an article complaining about unclear writing of any kind.<br> <br>I agree that the variable names aren't good for code written today, but C was written in the late 1960s when core (i.e. memory of the day) was expensive, and NASA has been around that long of course, so maybe at the time the code was written it <b> <i>was</i></b>  good code (and yes I know the size of the executable won't be bigger, but the size of the source will be, especially if s and ss are used throughout a large program, and source code lives in memory when being compiled too.) <br> <br>He certainly shouldn't have needed more than a few seconds to figure out that the loop traverses a linked list.</htmltext>
<tokenext>for ( ss = s- &gt; ss ; ss ; ss = ss- &gt; ss ) ; The semicolon at the end means the loop is only " processing " in the middle statement .
Testing to see if ss is NULL does not processing make .
Either he took liberties and left out the loop payload , or he still missed something and still does n't understand it .
It is true that in an embedded system , merely reading an address can have side effects , for example reading a register can cause hardware to perform actions , etc. , and maybe that is what is what is going on here , but I doubt that is the case here since the addresses would have to be pointers to other registers and registers themselves at the same time ( though it is still conceivable .
) I believe he meant to write : for ( ss = s- &gt; ss ; ss ; ss = ss- &gt; ss ) { [ some kind of processing here ] } ; , but that is not what was written , which is ironic in an article complaining about unclear writing of any kind .
I agree that the variable names are n't good for code written today , but C was written in the late 1960s when core ( i.e .
memory of the day ) was expensive , and NASA has been around that long of course , so maybe at the time the code was written it was good code ( and yes I know the size of the executable wo n't be bigger , but the size of the source will be , especially if s and ss are used throughout a large program , and source code lives in memory when being compiled too .
) He certainly should n't have needed more than a few seconds to figure out that the loop traverses a linked list .</tokentext>
<sentencetext>for(ss = s-&gt;ss; ss; ss = ss-&gt;ss);  The semicolon at the end means the loop is only "processing" in the middle statement.
Testing to see if ss is NULL does not processing make.
Either he took liberties and left out the loop payload, or he still missed something and still doesn't understand it.
It is true that in an embedded system, merely reading an address can have side effects, for example reading a register can cause hardware to perform actions, etc., and maybe that is what is what is going on here, but I doubt that is the case here since the addresses would have to be pointers to other registers and registers themselves at the same time (though it is still conceivable.
) I believe he meant to write:
for(ss = s-&gt;ss; ss; ss = ss-&gt;ss) { [some kind of processing here] };, but that is not what was written, which is ironic in an article complaining about unclear writing of any kind.
I agree that the variable names aren't good for code written today, but C was written in the late 1960s when core (i.e.
memory of the day) was expensive, and NASA has been around that long of course, so maybe at the time the code was written it  was  good code (and yes I know the size of the executable won't be bigger, but the size of the source will be, especially if s and ss are used throughout a large program, and source code lives in memory when being compiled too.
)  He certainly shouldn't have needed more than a few seconds to figure out that the loop traverses a linked list.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345084</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>phantomfive</author>
	<datestamp>1260131040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>When I first started using C, a lot of compilers only recognized the first 8 characters in an identifier name. Also, the CBM basic interpreter only recognized the first two characters (you could use more, but they would be ignored. I am sure I was not the only one who responded to this by only using 1 and 2 character length variables. Not saying it was a good idea, I'm just saying I did it). So a C program with only two character variable names doesn't seem unlikely to me.<br> <br>
Agreed on your second point. Some coding tasks are complex, and require complex code. If he gets confused by linked list traversal and alternate bracing styles.........may he never look at networking code.  It will kill him.</htmltext>
<tokenext>When I first started using C , a lot of compilers only recognized the first 8 characters in an identifier name .
Also , the CBM basic interpreter only recognized the first two characters ( you could use more , but they would be ignored .
I am sure I was not the only one who responded to this by only using 1 and 2 character length variables .
Not saying it was a good idea , I 'm just saying I did it ) .
So a C program with only two character variable names does n't seem unlikely to me .
Agreed on your second point .
Some coding tasks are complex , and require complex code .
If he gets confused by linked list traversal and alternate bracing styles.........may he never look at networking code .
It will kill him .</tokentext>
<sentencetext>When I first started using C, a lot of compilers only recognized the first 8 characters in an identifier name.
Also, the CBM basic interpreter only recognized the first two characters (you could use more, but they would be ignored.
I am sure I was not the only one who responded to this by only using 1 and 2 character length variables.
Not saying it was a good idea, I'm just saying I did it).
So a C program with only two character variable names doesn't seem unlikely to me.
Agreed on your second point.
Some coding tasks are complex, and require complex code.
If he gets confused by linked list traversal and alternate bracing styles.........may he never look at networking code.
It will kill him.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530</id>
	<title>Literate Programming</title>
	<author>Anonymous</author>
	<datestamp>1260118800000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>To my mind, the best coding standard is Don Knuth's Literate Programming: <a href="http://www.literateprogramming.com/" title="literateprogramming.com">http://www.literateprogramming.com/</a> [literateprogramming.com].  Quoting:</p><blockquote><div><p>I believe that the time is ripe for significantly better documentation of programs, and that we can best achieve this by considering programs to be works of literature. Hence, my title: "Literate Programming."</p><p>Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.</p><p>The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.</p></div>
</blockquote></div>
	</htmltext>
<tokenext>To my mind , the best coding standard is Don Knuth 's Literate Programming : http : //www.literateprogramming.com/ [ literateprogramming.com ] .
Quoting : I believe that the time is ripe for significantly better documentation of programs , and that we can best achieve this by considering programs to be works of literature .
Hence , my title : " Literate Programming .
" Let us change our traditional attitude to the construction of programs : Instead of imagining that our main task is to instruct a computer what to do , let us concentrate rather on explaining to human beings what we want a computer to do.The practitioner of literate programming can be regarded as an essayist , whose main concern is with exposition and excellence of style .
Such an author , with thesaurus in hand , chooses the names of variables carefully and explains what each variable means .
He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding , using a mixture of formal and informal methods that reinforce each other .</tokentext>
<sentencetext>To my mind, the best coding standard is Don Knuth's Literate Programming: http://www.literateprogramming.com/ [literateprogramming.com].
Quoting:I believe that the time is ripe for significantly better documentation of programs, and that we can best achieve this by considering programs to be works of literature.
Hence, my title: "Literate Programming.
"Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style.
Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means.
He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.

	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344638</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>Anonymous</author>
	<datestamp>1260127860000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>That is bad code, or at least, hideously idiomatic.</p><p>The variable names are apparently chosen for conciseness over legibility. The choice of 'ss' as both the loop variable and as an important field name appears deliberately confusing, especially when combined with its terseness. And the termination condition relies on the fact that a null pointer is treated as false in a boolean context - this is a non-obvious and largely arbitrary design choice in the language, and is arguably a type error.</p><p>I've been in this game long enough to recognise a linked list traversal when I see one, but I still had to read it twice to be sure. If it had read "for (currentNode = list-&gt;firstNode; currentNode != NULL; currentNode = currentNode-&gt;nextNode)" I'd have saved valuable milliseconds. If it had gone all OO and used some iterator object in a while loop, instead of that horrible for construct, even better.</p></htmltext>
<tokenext>That is bad code , or at least , hideously idiomatic.The variable names are apparently chosen for conciseness over legibility .
The choice of 'ss ' as both the loop variable and as an important field name appears deliberately confusing , especially when combined with its terseness .
And the termination condition relies on the fact that a null pointer is treated as false in a boolean context - this is a non-obvious and largely arbitrary design choice in the language , and is arguably a type error.I 've been in this game long enough to recognise a linked list traversal when I see one , but I still had to read it twice to be sure .
If it had read " for ( currentNode = list- &gt; firstNode ; currentNode ! = NULL ; currentNode = currentNode- &gt; nextNode ) " I 'd have saved valuable milliseconds .
If it had gone all OO and used some iterator object in a while loop , instead of that horrible for construct , even better .</tokentext>
<sentencetext>That is bad code, or at least, hideously idiomatic.The variable names are apparently chosen for conciseness over legibility.
The choice of 'ss' as both the loop variable and as an important field name appears deliberately confusing, especially when combined with its terseness.
And the termination condition relies on the fact that a null pointer is treated as false in a boolean context - this is a non-obvious and largely arbitrary design choice in the language, and is arguably a type error.I've been in this game long enough to recognise a linked list traversal when I see one, but I still had to read it twice to be sure.
If it had read "for (currentNode = list-&gt;firstNode; currentNode != NULL; currentNode = currentNode-&gt;nextNode)" I'd have saved valuable milliseconds.
If it had gone all OO and used some iterator object in a while loop, instead of that horrible for construct, even better.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343936</id>
	<title>Learn from the masters</title>
	<author>deblau</author>
	<datestamp>1260122640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><a href="http://www.faqs.org/docs/artu/ch01s06.html" title="faqs.org">http://www.faqs.org/docs/artu/ch01s06.html</a> [faqs.org]</htmltext>
<tokenext>http : //www.faqs.org/docs/artu/ch01s06.html [ faqs.org ]</tokentext>
<sentencetext>http://www.faqs.org/docs/artu/ch01s06.html [faqs.org]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344364</id>
	<title>document interfaces, not code, and learn from bugs</title>
	<author>jkajala</author>
	<datestamp>1260126120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>One of guidelines I have found useful is that document interfaces as much and detailed as possible, but if you feel you should write a comment in implementation think twice if the implementation is too complicated, or maybe there is some problem with the design. Does the function do straightforward well-defined task? If the function gets too long or complicated maybe there are some independent well-defined tasks that should be own functions instead of part in the implementation. Write so clean code that it doesn't shout need for any documentation.

One other useful guideline: Learn from bugs and improve code quality from the bugs. Always when encountering a bug, not only fix the bug but also ask "How could I prevented this in the first place?". That gives important hints about the quality issues in the code. Maybe you are not checking your assumptions/pre-conditions/post-conditions/variants enough. Maybe interface of that function was not well-defined. Maybe there was a test case missing. Maybe something else was wrong. Study the bug and make sure similar situation does not happen again.</htmltext>
<tokenext>One of guidelines I have found useful is that document interfaces as much and detailed as possible , but if you feel you should write a comment in implementation think twice if the implementation is too complicated , or maybe there is some problem with the design .
Does the function do straightforward well-defined task ?
If the function gets too long or complicated maybe there are some independent well-defined tasks that should be own functions instead of part in the implementation .
Write so clean code that it does n't shout need for any documentation .
One other useful guideline : Learn from bugs and improve code quality from the bugs .
Always when encountering a bug , not only fix the bug but also ask " How could I prevented this in the first place ? " .
That gives important hints about the quality issues in the code .
Maybe you are not checking your assumptions/pre-conditions/post-conditions/variants enough .
Maybe interface of that function was not well-defined .
Maybe there was a test case missing .
Maybe something else was wrong .
Study the bug and make sure similar situation does not happen again .</tokentext>
<sentencetext>One of guidelines I have found useful is that document interfaces as much and detailed as possible, but if you feel you should write a comment in implementation think twice if the implementation is too complicated, or maybe there is some problem with the design.
Does the function do straightforward well-defined task?
If the function gets too long or complicated maybe there are some independent well-defined tasks that should be own functions instead of part in the implementation.
Write so clean code that it doesn't shout need for any documentation.
One other useful guideline: Learn from bugs and improve code quality from the bugs.
Always when encountering a bug, not only fix the bug but also ask "How could I prevented this in the first place?".
That gives important hints about the quality issues in the code.
Maybe you are not checking your assumptions/pre-conditions/post-conditions/variants enough.
Maybe interface of that function was not well-defined.
Maybe there was a test case missing.
Maybe something else was wrong.
Study the bug and make sure similar situation does not happen again.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</id>
	<title>Re:Literate Programming</title>
	<author>Anonymous</author>
	<datestamp>1260121020000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p><div class="quote"><p>Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.</p></div><p>I'm sorry, but I can't help but disagree with this sentence. The purpose of creating a program really is to instruct the computer what to do. Not to explain other human beings what we want the computer to do.<br>Computers don't do what we want, they do what we tell them to do. Success in programming a computer comes from telling it what we want it to do.<br>One must not compromise the precision of the orders it gives to the computer in order to achieve readability by something/someone else than the computer. One should, however, try to make his code as readable and elegant as he possibly can without sacrificing precision in the message to the computer.<br>If we program without prioritizing the computer, we may end up writing something that may look, to us and anyone else that reads it, like what we want the computer to do, but the computer my not take it that well...<br>I do understand and advocate the need for excellence in coding practices. I even teach it. But as so, I am also the first to tell that we should allow the need to have others understand what we want to sacrifice the absolute necessity of having the computer understanding just as much.</p></div>
	</htmltext>
<tokenext>Let us change our traditional attitude to the construction of programs : Instead of imagining that our main task is to instruct a computer what to do , let us concentrate rather on explaining to human beings what we want a computer to do.I 'm sorry , but I ca n't help but disagree with this sentence .
The purpose of creating a program really is to instruct the computer what to do .
Not to explain other human beings what we want the computer to do.Computers do n't do what we want , they do what we tell them to do .
Success in programming a computer comes from telling it what we want it to do.One must not compromise the precision of the orders it gives to the computer in order to achieve readability by something/someone else than the computer .
One should , however , try to make his code as readable and elegant as he possibly can without sacrificing precision in the message to the computer.If we program without prioritizing the computer , we may end up writing something that may look , to us and anyone else that reads it , like what we want the computer to do , but the computer my not take it that well...I do understand and advocate the need for excellence in coding practices .
I even teach it .
But as so , I am also the first to tell that we should allow the need to have others understand what we want to sacrifice the absolute necessity of having the computer understanding just as much .</tokentext>
<sentencetext>Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.I'm sorry, but I can't help but disagree with this sentence.
The purpose of creating a program really is to instruct the computer what to do.
Not to explain other human beings what we want the computer to do.Computers don't do what we want, they do what we tell them to do.
Success in programming a computer comes from telling it what we want it to do.One must not compromise the precision of the orders it gives to the computer in order to achieve readability by something/someone else than the computer.
One should, however, try to make his code as readable and elegant as he possibly can without sacrificing precision in the message to the computer.If we program without prioritizing the computer, we may end up writing something that may look, to us and anyone else that reads it, like what we want the computer to do, but the computer my not take it that well...I do understand and advocate the need for excellence in coding practices.
I even teach it.
But as so, I am also the first to tell that we should allow the need to have others understand what we want to sacrifice the absolute necessity of having the computer understanding just as much.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345660</id>
	<title>Is this a clever one liner?</title>
	<author>iplayfast</author>
	<datestamp>1260092400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I like to use ternary conditions in my code where strings output based on a condional<br>for example</p><p>int n;<nobr> <wbr></nobr>//number of shoes<br>printf("we have \%d pair\%s of shoe\%s",n,n ? : "s" : "",? "es"  : "");</p><p>If you aren't used to it it is confusing, but if you are it saves a ton of code.</p><p>Is it considered a clever one liner?</p><p>How about<br>while(1)<br>{<nobr> <wbr></nobr>// do loop until return or break<br>}</p><p>My code is usually very terse, which helps me maintain it because dense code requires less reading to understand. (IMHO)</p></htmltext>
<tokenext>I like to use ternary conditions in my code where strings output based on a condionalfor exampleint n ; //number of shoesprintf ( " we have \ % d pair \ % s of shoe \ % s " ,n,n ?
: " s " : " " , ?
" es " : " " ) ; If you are n't used to it it is confusing , but if you are it saves a ton of code.Is it considered a clever one liner ? How aboutwhile ( 1 ) { // do loop until return or break } My code is usually very terse , which helps me maintain it because dense code requires less reading to understand .
( IMHO )</tokentext>
<sentencetext>I like to use ternary conditions in my code where strings output based on a condionalfor exampleint n; //number of shoesprintf("we have \%d pair\%s of shoe\%s",n,n ?
: "s" : "",?
"es"  : "");If you aren't used to it it is confusing, but if you are it saves a ton of code.Is it considered a clever one liner?How aboutwhile(1){ // do loop until return or break}My code is usually very terse, which helps me maintain it because dense code requires less reading to understand.
(IMHO)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344814</id>
	<title>Re:Literate Programming</title>
	<author>joaommp</author>
	<datestamp>1260129180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Perhaps you've forgotten:  Computers are here to serve human beings, not the other way 'round.</p></div><p>And yes, this is true. And that's exactly why what I said applies. Because if they're supposed to serve us, than we better know how to tell them what we want. They're not psychics to guess it for us.</p><p>If you're the keeper and you want your minions to bring you a coke, will you tell them to bring you a drink and expect them to know it's coke?</p></div>
	</htmltext>
<tokenext>Perhaps you 've forgotten : Computers are here to serve human beings , not the other way 'round.And yes , this is true .
And that 's exactly why what I said applies .
Because if they 're supposed to serve us , than we better know how to tell them what we want .
They 're not psychics to guess it for us.If you 're the keeper and you want your minions to bring you a coke , will you tell them to bring you a drink and expect them to know it 's coke ?</tokentext>
<sentencetext>Perhaps you've forgotten:  Computers are here to serve human beings, not the other way 'round.And yes, this is true.
And that's exactly why what I said applies.
Because if they're supposed to serve us, than we better know how to tell them what we want.
They're not psychics to guess it for us.If you're the keeper and you want your minions to bring you a coke, will you tell them to bring you a drink and expect them to know it's coke?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344424</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30353670</id>
	<title>Re:communication is key, not just documentation</title>
	<author>rwiggers</author>
	<datestamp>1260204600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>How would you talk with the coder when you're being hired for his position?<br>that's just one case of many when talking isn't possible. Documentation should be written, and well written.</p></htmltext>
<tokenext>How would you talk with the coder when you 're being hired for his position ? that 's just one case of many when talking is n't possible .
Documentation should be written , and well written .</tokentext>
<sentencetext>How would you talk with the coder when you're being hired for his position?that's just one case of many when talking isn't possible.
Documentation should be written, and well written.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343726</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838</id>
	<title>author seems somewhat confused and inexperienced</title>
	<author>Anonymous</author>
	<datestamp>1260121800000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>
The author of TFA seems somewhat confused and inexperienced.
</p><ol> <li>"Most of the variables in CRAP are one or two letters long. Originally, this was due to the memory constraints involved when programmers first designed and built the system." This is not particularly plausible. C is a compiled language, so using long variable names has no effect on the amount of memory used at run-time. It would also have been more or less a non-issue in terms of RAM used at compile-time. C only dates back to 1972, and didn't start to get popular until ca. 1980. By that time, using long variable names would have had a pretty negligible effect on RAM used by the compiler in proportion to total available RAM. And in any case, if compiles are taking too long, you just break up your files into smaller parts.</li>
<li> He uses this code "for(ss = s-&gt;ss; ss; ss = ss-&gt;ss);" as an example of bad code: "For those of you that are interested, the line traverses a linked-list of sources and sub-sources to process the values inside. But it took a good deal of research to figure that out, because there were no comments and the variable names, well, suck." Well, I read that and said to myself, "It's traversing a linked list." I think what's really going on here is that the author is probably a programmer who learned to program relatively recently with C++ and Java (he says in TFA that those are the languages he's used to), and he's used to doing things with big OOP libraries. The culture he's been inculcated in is one in which you never have to understand how a linked list is actually implemented, because you just use a library for it. To anyone who's actually implemented a linked list in a language that uses pointers, it is fairly obvious what this code does. It shouldn't take "a good deal of research" to figure it out.</li>
</ol></htmltext>
<tokenext>The author of TFA seems somewhat confused and inexperienced .
" Most of the variables in CRAP are one or two letters long .
Originally , this was due to the memory constraints involved when programmers first designed and built the system .
" This is not particularly plausible .
C is a compiled language , so using long variable names has no effect on the amount of memory used at run-time .
It would also have been more or less a non-issue in terms of RAM used at compile-time .
C only dates back to 1972 , and did n't start to get popular until ca .
1980. By that time , using long variable names would have had a pretty negligible effect on RAM used by the compiler in proportion to total available RAM .
And in any case , if compiles are taking too long , you just break up your files into smaller parts .
He uses this code " for ( ss = s- &gt; ss ; ss ; ss = ss- &gt; ss ) ; " as an example of bad code : " For those of you that are interested , the line traverses a linked-list of sources and sub-sources to process the values inside .
But it took a good deal of research to figure that out , because there were no comments and the variable names , well , suck .
" Well , I read that and said to myself , " It 's traversing a linked list .
" I think what 's really going on here is that the author is probably a programmer who learned to program relatively recently with C + + and Java ( he says in TFA that those are the languages he 's used to ) , and he 's used to doing things with big OOP libraries .
The culture he 's been inculcated in is one in which you never have to understand how a linked list is actually implemented , because you just use a library for it .
To anyone who 's actually implemented a linked list in a language that uses pointers , it is fairly obvious what this code does .
It should n't take " a good deal of research " to figure it out .</tokentext>
<sentencetext>
The author of TFA seems somewhat confused and inexperienced.
"Most of the variables in CRAP are one or two letters long.
Originally, this was due to the memory constraints involved when programmers first designed and built the system.
" This is not particularly plausible.
C is a compiled language, so using long variable names has no effect on the amount of memory used at run-time.
It would also have been more or less a non-issue in terms of RAM used at compile-time.
C only dates back to 1972, and didn't start to get popular until ca.
1980. By that time, using long variable names would have had a pretty negligible effect on RAM used by the compiler in proportion to total available RAM.
And in any case, if compiles are taking too long, you just break up your files into smaller parts.
He uses this code "for(ss = s-&gt;ss; ss; ss = ss-&gt;ss);" as an example of bad code: "For those of you that are interested, the line traverses a linked-list of sources and sub-sources to process the values inside.
But it took a good deal of research to figure that out, because there were no comments and the variable names, well, suck.
" Well, I read that and said to myself, "It's traversing a linked list.
" I think what's really going on here is that the author is probably a programmer who learned to program relatively recently with C++ and Java (he says in TFA that those are the languages he's used to), and he's used to doing things with big OOP libraries.
The culture he's been inculcated in is one in which you never have to understand how a linked list is actually implemented, because you just use a library for it.
To anyone who's actually implemented a linked list in a language that uses pointers, it is fairly obvious what this code does.
It shouldn't take "a good deal of research" to figure it out.
</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30361288</id>
	<title>Worst documentation ever!</title>
	<author>Anonymous</author>
	<datestamp>1260203700000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You know what is the most horribly documented code in the history of the world?  DNA</p></htmltext>
<tokenext>You know what is the most horribly documented code in the history of the world ?
DNA</tokentext>
<sentencetext>You know what is the most horribly documented code in the history of the world?
DNA</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345286</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>Kjella</author>
	<datestamp>1260132660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>He uses this code "for(ss = s-&gt;ss; ss; ss = ss-&gt;ss);" as an example of bad code: "For those of you that are interested, the line traverses a linked-list of sources and sub-sources to process the values inside. But it took a good deal of research to figure that out, because there were no comments and the variable names, well, suck." Well, I read that and said to myself, "It's traversing a linked list."</p></div><p>If you see the pattern yes, but the naming is just horrible. "for(ss = s-&gt;first; ss; ss = ss-&gt;next)" would be quite easily understandable. Plus it'd match the typical first/last next/prev way of naming usually done in a doubly linked list. I would not immediately understand that, particularly not if it wasn't obvious from the function that it would be looping through anything.</p><p>I think everyone should be forced to do what I did when I programmed on my TI-82 calculator, it had no autocompletion and variable names were painful to repeat so they became single letters. I could do quite advanced stuff as long as I kept working on it and had it fresh in memory. Tried looking at it later, it was a complete clusterfuck to dechipher.</p><p>This guy looks lof the same caliber, s-&gt;ss and ss-&gt;ss as member variables? I mean in a function you can use almost any lame naming and people should be able to figure it out because the whole purpose of the variable is right there in the function, but if it's not clear what the members are you have to dig through the whole class and find when, why and how it's being set and/or used.</p><p>I don't really mind pointers, but they have a way of adding a very confusing layer of indirection that often makes it unnecessarily complicated to understand what's doing on.</p></div>
	</htmltext>
<tokenext>He uses this code " for ( ss = s- &gt; ss ; ss ; ss = ss- &gt; ss ) ; " as an example of bad code : " For those of you that are interested , the line traverses a linked-list of sources and sub-sources to process the values inside .
But it took a good deal of research to figure that out , because there were no comments and the variable names , well , suck .
" Well , I read that and said to myself , " It 's traversing a linked list .
" If you see the pattern yes , but the naming is just horrible .
" for ( ss = s- &gt; first ; ss ; ss = ss- &gt; next ) " would be quite easily understandable .
Plus it 'd match the typical first/last next/prev way of naming usually done in a doubly linked list .
I would not immediately understand that , particularly not if it was n't obvious from the function that it would be looping through anything.I think everyone should be forced to do what I did when I programmed on my TI-82 calculator , it had no autocompletion and variable names were painful to repeat so they became single letters .
I could do quite advanced stuff as long as I kept working on it and had it fresh in memory .
Tried looking at it later , it was a complete clusterfuck to dechipher.This guy looks lof the same caliber , s- &gt; ss and ss- &gt; ss as member variables ?
I mean in a function you can use almost any lame naming and people should be able to figure it out because the whole purpose of the variable is right there in the function , but if it 's not clear what the members are you have to dig through the whole class and find when , why and how it 's being set and/or used.I do n't really mind pointers , but they have a way of adding a very confusing layer of indirection that often makes it unnecessarily complicated to understand what 's doing on .</tokentext>
<sentencetext>He uses this code "for(ss = s-&gt;ss; ss; ss = ss-&gt;ss);" as an example of bad code: "For those of you that are interested, the line traverses a linked-list of sources and sub-sources to process the values inside.
But it took a good deal of research to figure that out, because there were no comments and the variable names, well, suck.
" Well, I read that and said to myself, "It's traversing a linked list.
"If you see the pattern yes, but the naming is just horrible.
"for(ss = s-&gt;first; ss; ss = ss-&gt;next)" would be quite easily understandable.
Plus it'd match the typical first/last next/prev way of naming usually done in a doubly linked list.
I would not immediately understand that, particularly not if it wasn't obvious from the function that it would be looping through anything.I think everyone should be forced to do what I did when I programmed on my TI-82 calculator, it had no autocompletion and variable names were painful to repeat so they became single letters.
I could do quite advanced stuff as long as I kept working on it and had it fresh in memory.
Tried looking at it later, it was a complete clusterfuck to dechipher.This guy looks lof the same caliber, s-&gt;ss and ss-&gt;ss as member variables?
I mean in a function you can use almost any lame naming and people should be able to figure it out because the whole purpose of the variable is right there in the function, but if it's not clear what the members are you have to dig through the whole class and find when, why and how it's being set and/or used.I don't really mind pointers, but they have a way of adding a very confusing layer of indirection that often makes it unnecessarily complicated to understand what's doing on.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30349076</id>
	<title>Buy the books</title>
	<author>Anonymous</author>
	<datestamp>1260119160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>There are many books on the subject.</p></htmltext>
<tokenext>There are many books on the subject .</tokentext>
<sentencetext>There are many books on the subject.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345704</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>Anonymous</author>
	<datestamp>1260092700000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>So you don't put up with "shit" like using widespread idioms and relying on standard language features? Sounds like a lovely place to work.</p></htmltext>
<tokenext>So you do n't put up with " shit " like using widespread idioms and relying on standard language features ?
Sounds like a lovely place to work .</tokentext>
<sentencetext>So you don't put up with "shit" like using widespread idioms and relying on standard language features?
Sounds like a lovely place to work.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344966</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30353612</id>
	<title>Re:Subs and functions</title>
	<author>rwiggers</author>
	<datestamp>1260204300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That's some assembly programmer writing something in another language. I see it all day long...<br>Usually that's an EE who never had a lesson on programming and learned it on the field 40 years ago.</p></htmltext>
<tokenext>That 's some assembly programmer writing something in another language .
I see it all day long...Usually that 's an EE who never had a lesson on programming and learned it on the field 40 years ago .</tokentext>
<sentencetext>That's some assembly programmer writing something in another language.
I see it all day long...Usually that's an EE who never had a lesson on programming and learned it on the field 40 years ago.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346802</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30349014</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>ratboy666</author>
	<datestamp>1260118440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"hideously idomatic"</p><p>Actually, the construct is rather pleasant. I now know that if s is a pointer, ss is a traversing pointer, at least in a singly linked list context. Use of ss outside of a "for" or "while", and initialization from anything but an "s" should raise alarms.</p><p>So, I can infer what pp would mean, if I came across it.</p><p>All this from a SINGLE STATEMENT. Wow, to C coder, this IS reasonable code! Not so much to someone new at the game, though.</p><p>As to NULL being zero... that is simply a precondition of the language itself. This is C code, for gods sake! It's not Java. Idioms. Deal. I wonder what happens when these programmers see level 88 Cobol declarations, or FORTRAN equivalence statements, assigned goto, or arithmetic ifs, or even a recursive formulation in C! My, I am getting giddy thinking about the reaction.</p><p>On the other hand, this lack of experience is good for me. I just made some money modifying some COBOL CICS code. Because I can.</p><p>Now,</p><p>"for (currentNode = list-&gt;firstNode; currentNode != NULL; currentNode = currentNode-&gt;nextNode)"</p><p>does NOT mean</p><p>for (ss = s-&gt;ss; ss; ss = ss-&gt;ss)</p><p>At least, not until you add</p><p>#define firstNode nextNode</p><p>into your program. Which WOULD raise a WTF!? moment for a lot of programmers. Also, The Fine Article also recommends using STL. In C code. Instead of int ***values; Really. Now, I am not sure what context you would find int *** in. In 30 years of C code, I have yet run across this. But, just how do you retrofit STL into C code that old?</p><p>And now on to the "incomprehensible"</p><p>s-&gt;ss-&gt;dc.d-&gt;v + i</p><p>Well, you can't have an ss without an s (see the first part of my comment), thus s-&gt;ss</p><p>Within that, we have a dc, which is (most likely) a union. To save memory. Probably a "context", but I'd actually need a few more lines...</p><p>Choose d, which is a pointer, v (likely "value") because we are adding a local integer.</p><p>Really, the author IS just inexperienced. Problem is, he has a blog and seems to believe in preaching. He takes a joke at face value -- and doesn't think of the real reason...</p><p>I condemn him to coding on an 80x24 terminal, in C 89 (or K&amp;R C), or FORTRAN IV for two years... After which he should revisit this article.</p></htmltext>
<tokenext>" hideously idomatic " Actually , the construct is rather pleasant .
I now know that if s is a pointer , ss is a traversing pointer , at least in a singly linked list context .
Use of ss outside of a " for " or " while " , and initialization from anything but an " s " should raise alarms.So , I can infer what pp would mean , if I came across it.All this from a SINGLE STATEMENT .
Wow , to C coder , this IS reasonable code !
Not so much to someone new at the game , though.As to NULL being zero... that is simply a precondition of the language itself .
This is C code , for gods sake !
It 's not Java .
Idioms. Deal .
I wonder what happens when these programmers see level 88 Cobol declarations , or FORTRAN equivalence statements , assigned goto , or arithmetic ifs , or even a recursive formulation in C !
My , I am getting giddy thinking about the reaction.On the other hand , this lack of experience is good for me .
I just made some money modifying some COBOL CICS code .
Because I can.Now , " for ( currentNode = list- &gt; firstNode ; currentNode ! = NULL ; currentNode = currentNode- &gt; nextNode ) " does NOT meanfor ( ss = s- &gt; ss ; ss ; ss = ss- &gt; ss ) At least , not until you add # define firstNode nextNodeinto your program .
Which WOULD raise a WTF ! ?
moment for a lot of programmers .
Also , The Fine Article also recommends using STL .
In C code .
Instead of int * * * values ; Really .
Now , I am not sure what context you would find int * * * in .
In 30 years of C code , I have yet run across this .
But , just how do you retrofit STL into C code that old ? And now on to the " incomprehensible " s- &gt; ss- &gt; dc.d- &gt; v + iWell , you ca n't have an ss without an s ( see the first part of my comment ) , thus s- &gt; ssWithin that , we have a dc , which is ( most likely ) a union .
To save memory .
Probably a " context " , but I 'd actually need a few more lines...Choose d , which is a pointer , v ( likely " value " ) because we are adding a local integer.Really , the author IS just inexperienced .
Problem is , he has a blog and seems to believe in preaching .
He takes a joke at face value -- and does n't think of the real reason...I condemn him to coding on an 80x24 terminal , in C 89 ( or K&amp;R C ) , or FORTRAN IV for two years... After which he should revisit this article .</tokentext>
<sentencetext>"hideously idomatic"Actually, the construct is rather pleasant.
I now know that if s is a pointer, ss is a traversing pointer, at least in a singly linked list context.
Use of ss outside of a "for" or "while", and initialization from anything but an "s" should raise alarms.So, I can infer what pp would mean, if I came across it.All this from a SINGLE STATEMENT.
Wow, to C coder, this IS reasonable code!
Not so much to someone new at the game, though.As to NULL being zero... that is simply a precondition of the language itself.
This is C code, for gods sake!
It's not Java.
Idioms. Deal.
I wonder what happens when these programmers see level 88 Cobol declarations, or FORTRAN equivalence statements, assigned goto, or arithmetic ifs, or even a recursive formulation in C!
My, I am getting giddy thinking about the reaction.On the other hand, this lack of experience is good for me.
I just made some money modifying some COBOL CICS code.
Because I can.Now,"for (currentNode = list-&gt;firstNode; currentNode != NULL; currentNode = currentNode-&gt;nextNode)"does NOT meanfor (ss = s-&gt;ss; ss; ss = ss-&gt;ss)At least, not until you add#define firstNode nextNodeinto your program.
Which WOULD raise a WTF!?
moment for a lot of programmers.
Also, The Fine Article also recommends using STL.
In C code.
Instead of int ***values; Really.
Now, I am not sure what context you would find int *** in.
In 30 years of C code, I have yet run across this.
But, just how do you retrofit STL into C code that old?And now on to the "incomprehensible"s-&gt;ss-&gt;dc.d-&gt;v + iWell, you can't have an ss without an s (see the first part of my comment), thus s-&gt;ssWithin that, we have a dc, which is (most likely) a union.
To save memory.
Probably a "context", but I'd actually need a few more lines...Choose d, which is a pointer, v (likely "value") because we are adding a local integer.Really, the author IS just inexperienced.
Problem is, he has a blog and seems to believe in preaching.
He takes a joke at face value -- and doesn't think of the real reason...I condemn him to coding on an 80x24 terminal, in C 89 (or K&amp;R C), or FORTRAN IV for two years... After which he should revisit this article.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344638</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345294</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>Anonymous</author>
	<datestamp>1260132660000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><blockquote><div><p>He uses this code "for(ss = s-&gt;ss; ss; ss = ss-&gt;ss);" as an example of bad code</p></div>
</blockquote><p>I love how his example uses the most confusing variable names possible. Just using proper names should make it clear to almost anyone:</p><blockquote><div><p> <tt>for ( Item* p = foo-&gt;items; p != NULL; p = p-&gt;next )</tt></p></div> </blockquote></div>
	</htmltext>
<tokenext>He uses this code " for ( ss = s- &gt; ss ; ss ; ss = ss- &gt; ss ) ; " as an example of bad code I love how his example uses the most confusing variable names possible .
Just using proper names should make it clear to almost anyone : for ( Item * p = foo- &gt; items ; p ! = NULL ; p = p- &gt; next )</tokentext>
<sentencetext>He uses this code "for(ss = s-&gt;ss; ss; ss = ss-&gt;ss);" as an example of bad code
I love how his example uses the most confusing variable names possible.
Just using proper names should make it clear to almost anyone: for ( Item* p = foo-&gt;items; p != NULL; p = p-&gt;next ) 
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346684</id>
	<title>Re:Literate Programming</title>
	<author>Anonymous</author>
	<datestamp>1260099720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>&gt; If we program without prioritizing the computer, we may end up writing something that may look, to us and anyone else that reads it, like what we want the computer to do, but the computer my not take it that well...</p><p>Skynet...</p></htmltext>
<tokenext>&gt; If we program without prioritizing the computer , we may end up writing something that may look , to us and anyone else that reads it , like what we want the computer to do , but the computer my not take it that well...Skynet.. .</tokentext>
<sentencetext>&gt; If we program without prioritizing the computer, we may end up writing something that may look, to us and anyone else that reads it, like what we want the computer to do, but the computer my not take it that well...Skynet...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30363844</id>
	<title>Simple compilers may be to blame</title>
	<author>amn108</author>
	<datestamp>1260278820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Clever solutions is a tool in the hands of a programmer who uses a compiler that cannot do the clever job itself. This is currently, most of all compilers/translators out there and more importantly, most of the "widely-used" (an oxymoron!) ones. In other words, if your compiler is stupid, it is your job to produce the optimization by altering readable code into code that performs efficiently but looks too funny. Maybe languages like Haskell or ML will liberate us from this. It is a culture, a culture that lacks education.</p><p>Always rely on the compiler. It is your translator, and as with any good translator, you can relax speaking your native language (i.e. human) and trust it to do more an adequate job.</p></htmltext>
<tokenext>Clever solutions is a tool in the hands of a programmer who uses a compiler that can not do the clever job itself .
This is currently , most of all compilers/translators out there and more importantly , most of the " widely-used " ( an oxymoron !
) ones .
In other words , if your compiler is stupid , it is your job to produce the optimization by altering readable code into code that performs efficiently but looks too funny .
Maybe languages like Haskell or ML will liberate us from this .
It is a culture , a culture that lacks education.Always rely on the compiler .
It is your translator , and as with any good translator , you can relax speaking your native language ( i.e .
human ) and trust it to do more an adequate job .</tokentext>
<sentencetext>Clever solutions is a tool in the hands of a programmer who uses a compiler that cannot do the clever job itself.
This is currently, most of all compilers/translators out there and more importantly, most of the "widely-used" (an oxymoron!
) ones.
In other words, if your compiler is stupid, it is your job to produce the optimization by altering readable code into code that performs efficiently but looks too funny.
Maybe languages like Haskell or ML will liberate us from this.
It is a culture, a culture that lacks education.Always rely on the compiler.
It is your translator, and as with any good translator, you can relax speaking your native language (i.e.
human) and trust it to do more an adequate job.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344570</id>
	<title>Programming is people!</title>
	<author>Anonymous</author>
	<datestamp>1260127440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>And as such...you are gonna get the "clever" no matter what practices you write down.</p></htmltext>
<tokenext>And as such...you are gon na get the " clever " no matter what practices you write down .</tokentext>
<sentencetext>And as such...you are gonna get the "clever" no matter what practices you write down.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343674</id>
	<title>Code Reviews (Gerrit)</title>
	<author>jtolds</author>
	<datestamp>1260120360000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Traditional everyone set aside time and review checked in code is hard to do, difficult, and time consuming.</p><p>On the other hand, automated code review tools are life changing. There's a bunch of tools out there, but the one I think is far and away the best is Google's Gerrit tool (http://code.google.com/p/gerrit/), which is what Google uses publicly for Android.</p><p>I cannot understate how helpful Gerrit has been in this regard. So many things that are trouble down the road are easily caught by even just one other pair of eyes. Everyone who has used Gerrit at my compnay has fallen in love with automated code reviews. It's refreshing, leads to better code, etc. I seriously could gush about Gerrit for pages.</p></htmltext>
<tokenext>Traditional everyone set aside time and review checked in code is hard to do , difficult , and time consuming.On the other hand , automated code review tools are life changing .
There 's a bunch of tools out there , but the one I think is far and away the best is Google 's Gerrit tool ( http : //code.google.com/p/gerrit/ ) , which is what Google uses publicly for Android.I can not understate how helpful Gerrit has been in this regard .
So many things that are trouble down the road are easily caught by even just one other pair of eyes .
Everyone who has used Gerrit at my compnay has fallen in love with automated code reviews .
It 's refreshing , leads to better code , etc .
I seriously could gush about Gerrit for pages .</tokentext>
<sentencetext>Traditional everyone set aside time and review checked in code is hard to do, difficult, and time consuming.On the other hand, automated code review tools are life changing.
There's a bunch of tools out there, but the one I think is far and away the best is Google's Gerrit tool (http://code.google.com/p/gerrit/), which is what Google uses publicly for Android.I cannot understate how helpful Gerrit has been in this regard.
So many things that are trouble down the road are easily caught by even just one other pair of eyes.
Everyone who has used Gerrit at my compnay has fallen in love with automated code reviews.
It's refreshing, leads to better code, etc.
I seriously could gush about Gerrit for pages.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345464</id>
	<title>In my experience...</title>
	<author>Lord Bitman</author>
	<datestamp>1260090600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If naming (variable, function, class, module, whatever) isn't part of your coding standard, you're going to have problems.<br>And pretty much everything else is just an optional "nice to have" (usually to do with spacing).</p><p>I am the asshole with the 40-character variable names. Yes, I need to split statements over multiple lines lines sometimes, yes I have more lines of code and it takes me longer to type them, but I think it's very worth it to be able to pick something up months or years later and instantly be able to tell what the hell everything means.</p><p>As for spacing, I would absolutely love to format all code very strictly, and reject any commits which don't match an automated formatter exactly (for XML, this is possible, of course), but I've yet to see one which doesn't have really horrible edge-cases involving comments.</p></htmltext>
<tokenext>If naming ( variable , function , class , module , whatever ) is n't part of your coding standard , you 're going to have problems.And pretty much everything else is just an optional " nice to have " ( usually to do with spacing ) .I am the asshole with the 40-character variable names .
Yes , I need to split statements over multiple lines lines sometimes , yes I have more lines of code and it takes me longer to type them , but I think it 's very worth it to be able to pick something up months or years later and instantly be able to tell what the hell everything means.As for spacing , I would absolutely love to format all code very strictly , and reject any commits which do n't match an automated formatter exactly ( for XML , this is possible , of course ) , but I 've yet to see one which does n't have really horrible edge-cases involving comments .</tokentext>
<sentencetext>If naming (variable, function, class, module, whatever) isn't part of your coding standard, you're going to have problems.And pretty much everything else is just an optional "nice to have" (usually to do with spacing).I am the asshole with the 40-character variable names.
Yes, I need to split statements over multiple lines lines sometimes, yes I have more lines of code and it takes me longer to type them, but I think it's very worth it to be able to pick something up months or years later and instantly be able to tell what the hell everything means.As for spacing, I would absolutely love to format all code very strictly, and reject any commits which don't match an automated formatter exactly (for XML, this is possible, of course), but I've yet to see one which doesn't have really horrible edge-cases involving comments.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30373546</id>
	<title>Anonymous Coward</title>
	<author>Anonymous</author>
	<datestamp>1260286860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>http://www.jlab.org/~saw/linux/lug\_19091999.mgp<br>What is this?</p></htmltext>
<tokenext>http : //www.jlab.org/ ~ saw/linux/lug \ _19091999.mgpWhat is this ?</tokentext>
<sentencetext>http://www.jlab.org/~saw/linux/lug\_19091999.mgpWhat is this?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344686</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>Anonymous</author>
	<datestamp>1260128220000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Idiom, what the OP lacks is the common idiom in the language. Like the traversing a linked list as you have pointed out.</p><p>However, the code can improved by better naming of variables. The sin of the original code is to have the loop name be the same as a field in the struct, e.g. I think the following is more readable.</p><p>for (it=s-&gt;next; it; thisThing=it-&gt;next);</p></htmltext>
<tokenext>Idiom , what the OP lacks is the common idiom in the language .
Like the traversing a linked list as you have pointed out.However , the code can improved by better naming of variables .
The sin of the original code is to have the loop name be the same as a field in the struct , e.g .
I think the following is more readable.for ( it = s- &gt; next ; it ; thisThing = it- &gt; next ) ;</tokentext>
<sentencetext>Idiom, what the OP lacks is the common idiom in the language.
Like the traversing a linked list as you have pointed out.However, the code can improved by better naming of variables.
The sin of the original code is to have the loop name be the same as a field in the struct, e.g.
I think the following is more readable.for (it=s-&gt;next; it; thisThing=it-&gt;next);</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345310</id>
	<title>write insanely obvious code</title>
	<author>Anonymous</author>
	<datestamp>1260132720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If you build obvious enough code, you only need a few comments, such as "this business thing that does so-and-so starts here/ends here".  All the comments in the world don't make a "clever" solution any less douche-y.</p></htmltext>
<tokenext>If you build obvious enough code , you only need a few comments , such as " this business thing that does so-and-so starts here/ends here " .
All the comments in the world do n't make a " clever " solution any less douche-y .</tokentext>
<sentencetext>If you build obvious enough code, you only need a few comments, such as "this business thing that does so-and-so starts here/ends here".
All the comments in the world don't make a "clever" solution any less douche-y.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344178</id>
	<title>elegant != clever</title>
	<author>dsoltesz</author>
	<datestamp>1260124560000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>Elegant and clever are not the same thing.</p><p>Elegant describes the algorithm or solution as using resources efficiently, having no unnecessary steps in getting to the solution, and easily readable to another programmer familiar with the subject at hand (as AB3A mentioned inre to DSP).</p><p>Yes, if we use Webster's definition, there is a certain amount of "cleverness" in beautiful, elegant code. However, when we say "clever" we usually mean cutesy-clever, like mashing several traditional lines of code into a one-liner. That's fine for a geeky contest of "who can write this using the fewest number of characters," but (as most of us agree) does not have a place in professional code. One-liners and similar stunts might be clever, but are rarely elegant, and cause headaches for later maintainers of the code.</p></htmltext>
<tokenext>Elegant and clever are not the same thing.Elegant describes the algorithm or solution as using resources efficiently , having no unnecessary steps in getting to the solution , and easily readable to another programmer familiar with the subject at hand ( as AB3A mentioned inre to DSP ) .Yes , if we use Webster 's definition , there is a certain amount of " cleverness " in beautiful , elegant code .
However , when we say " clever " we usually mean cutesy-clever , like mashing several traditional lines of code into a one-liner .
That 's fine for a geeky contest of " who can write this using the fewest number of characters , " but ( as most of us agree ) does not have a place in professional code .
One-liners and similar stunts might be clever , but are rarely elegant , and cause headaches for later maintainers of the code .</tokentext>
<sentencetext>Elegant and clever are not the same thing.Elegant describes the algorithm or solution as using resources efficiently, having no unnecessary steps in getting to the solution, and easily readable to another programmer familiar with the subject at hand (as AB3A mentioned inre to DSP).Yes, if we use Webster's definition, there is a certain amount of "cleverness" in beautiful, elegant code.
However, when we say "clever" we usually mean cutesy-clever, like mashing several traditional lines of code into a one-liner.
That's fine for a geeky contest of "who can write this using the fewest number of characters," but (as most of us agree) does not have a place in professional code.
One-liners and similar stunts might be clever, but are rarely elegant, and cause headaches for later maintainers of the code.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345564</id>
	<title>Seatbelts are useless too!</title>
	<author>Zero\_\_Kelvin</author>
	<datestamp>1260091680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>"A college professor at Texas A&amp;M, Dr. Salih Yurtas told us that he believed comments were useless. His argument was that people rarely pay enough attention to code comments and that since developers often add them at the last minute after the program is finished, they are often incomplete."</p></div></blockquote><p>Right, and seatbelts are useless because people often don't use them, or they fail to buckle them properly.</p></div>
	</htmltext>
<tokenext>" A college professor at Texas A&amp;M , Dr. Salih Yurtas told us that he believed comments were useless .
His argument was that people rarely pay enough attention to code comments and that since developers often add them at the last minute after the program is finished , they are often incomplete .
" Right , and seatbelts are useless because people often do n't use them , or they fail to buckle them properly .</tokentext>
<sentencetext>"A college professor at Texas A&amp;M, Dr. Salih Yurtas told us that he believed comments were useless.
His argument was that people rarely pay enough attention to code comments and that since developers often add them at the last minute after the program is finished, they are often incomplete.
"Right, and seatbelts are useless because people often don't use them, or they fail to buckle them properly.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344718</id>
	<title>The Author probably shouldn't be programming in C</title>
	<author>m6ack</author>
	<datestamp>1260128520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The first example that the author sites as an example of poor programming is "idiomatic" C for traversing a linked list.  Also, if the author can't deal with pointers, he should not only avoid C, but also C++ and stick to Java or his beloved PHP and JavaScript.  Siting that he found a standards document so flugly as GNU "helpful," doesn't help his argument.

</p><p>First, learn C as C.  Don't be scared, it's just like this "whole nother language" that's different from JavaScript.  It can be used quite safely. If it couldn't, your beloved operating system of choice, that is likely written in C, just wouldn't work at all.

</p><p>Second, draw your learning of the language not from standards documents, but by immersion in books like "The Practice of Programming." You will then find out that code like "for(ss = s-&gt;ss; ss; ss = ss-&gt;ss);" can be used without fear of misunderstanding because it is "idiomatic."  People that know C will fully understand what it is doing.  Writing a comment here is pointless and will degrade the readability of the code.

</p><p>Third, add one further standards document to the list:

</p><p>        <a href="http://lxr.linux.no/#linux+v2.6.32/Documentation/CodingStyle" title="linux.no" rel="nofollow">http://lxr.linux.no/#linux+v2.6.32/Documentation/CodingStyle</a> [linux.no]

</p><p>And learn that Coding standards are only as effective as those that use them.</p></htmltext>
<tokenext>The first example that the author sites as an example of poor programming is " idiomatic " C for traversing a linked list .
Also , if the author ca n't deal with pointers , he should not only avoid C , but also C + + and stick to Java or his beloved PHP and JavaScript .
Siting that he found a standards document so flugly as GNU " helpful , " does n't help his argument .
First , learn C as C. Do n't be scared , it 's just like this " whole nother language " that 's different from JavaScript .
It can be used quite safely .
If it could n't , your beloved operating system of choice , that is likely written in C , just would n't work at all .
Second , draw your learning of the language not from standards documents , but by immersion in books like " The Practice of Programming .
" You will then find out that code like " for ( ss = s- &gt; ss ; ss ; ss = ss- &gt; ss ) ; " can be used without fear of misunderstanding because it is " idiomatic .
" People that know C will fully understand what it is doing .
Writing a comment here is pointless and will degrade the readability of the code .
Third , add one further standards document to the list : http : //lxr.linux.no/ # linux + v2.6.32/Documentation/CodingStyle [ linux.no ] And learn that Coding standards are only as effective as those that use them .</tokentext>
<sentencetext>The first example that the author sites as an example of poor programming is "idiomatic" C for traversing a linked list.
Also, if the author can't deal with pointers, he should not only avoid C, but also C++ and stick to Java or his beloved PHP and JavaScript.
Siting that he found a standards document so flugly as GNU "helpful," doesn't help his argument.
First, learn C as C.  Don't be scared, it's just like this "whole nother language" that's different from JavaScript.
It can be used quite safely.
If it couldn't, your beloved operating system of choice, that is likely written in C, just wouldn't work at all.
Second, draw your learning of the language not from standards documents, but by immersion in books like "The Practice of Programming.
" You will then find out that code like "for(ss = s-&gt;ss; ss; ss = ss-&gt;ss);" can be used without fear of misunderstanding because it is "idiomatic.
"  People that know C will fully understand what it is doing.
Writing a comment here is pointless and will degrade the readability of the code.
Third, add one further standards document to the list:

        http://lxr.linux.no/#linux+v2.6.32/Documentation/CodingStyle [linux.no]

And learn that Coding standards are only as effective as those that use them.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345244</id>
	<title>Re:Literate Programming</title>
	<author>Anonymous</author>
	<datestamp>1260132420000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>"The purpose of creating a program really is to instruct the computer what to do. Not to explain other human beings what we want the computer to do."</p><p>Fail. Programs aren't written to amuse computers. They are written to serve people. If you cannot clearly explain to people what you are doing, you almost certainly won't do it right. One of the people you need to be explaining it to is yourself. This is the essence of Literate Programming. Write the comments, so you'll clearly relate what the functionality is. Write the code so that the implementation matches the described function.</p><p>Too often I hear the excuse that code shouldn't be commented because comments swiftly become obsolete. I don't accept that. If there isn't enough time in the budget to allow for a COMPLETE maintenance of the comments and then the code, then the software is likely to rot as it builds up a legacy of instructions whose full impact are not well understood.</p></htmltext>
<tokenext>" The purpose of creating a program really is to instruct the computer what to do .
Not to explain other human beings what we want the computer to do. " Fail .
Programs are n't written to amuse computers .
They are written to serve people .
If you can not clearly explain to people what you are doing , you almost certainly wo n't do it right .
One of the people you need to be explaining it to is yourself .
This is the essence of Literate Programming .
Write the comments , so you 'll clearly relate what the functionality is .
Write the code so that the implementation matches the described function.Too often I hear the excuse that code should n't be commented because comments swiftly become obsolete .
I do n't accept that .
If there is n't enough time in the budget to allow for a COMPLETE maintenance of the comments and then the code , then the software is likely to rot as it builds up a legacy of instructions whose full impact are not well understood .</tokentext>
<sentencetext>"The purpose of creating a program really is to instruct the computer what to do.
Not to explain other human beings what we want the computer to do."Fail.
Programs aren't written to amuse computers.
They are written to serve people.
If you cannot clearly explain to people what you are doing, you almost certainly won't do it right.
One of the people you need to be explaining it to is yourself.
This is the essence of Literate Programming.
Write the comments, so you'll clearly relate what the functionality is.
Write the code so that the implementation matches the described function.Too often I hear the excuse that code shouldn't be commented because comments swiftly become obsolete.
I don't accept that.
If there isn't enough time in the budget to allow for a COMPLETE maintenance of the comments and then the code, then the software is likely to rot as it builds up a legacy of instructions whose full impact are not well understood.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30348124</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>Anonymous</author>
	<datestamp>1260110040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Which suggests that you're not a C programmer. Fair enough, but you were warned:<br>"The first sign of danger was the entire code base is written in C,"</p><p>What this section of the article really lacks is a description of the struct(ure)s that s and ss point to. Maybe this is a simple linked list, and 'next' would make sense. Maybe it's a tree of some sort. Maybe ss had a contextual meaning that the author obliterated in his attempt to make a point.</p><p>A cynic might point out that this is a self-confessed 'web development' author, but that would just degrade this post to his level.</p></htmltext>
<tokenext>Which suggests that you 're not a C programmer .
Fair enough , but you were warned : " The first sign of danger was the entire code base is written in C , " What this section of the article really lacks is a description of the struct ( ure ) s that s and ss point to .
Maybe this is a simple linked list , and 'next ' would make sense .
Maybe it 's a tree of some sort .
Maybe ss had a contextual meaning that the author obliterated in his attempt to make a point.A cynic might point out that this is a self-confessed 'web development ' author , but that would just degrade this post to his level .</tokentext>
<sentencetext>Which suggests that you're not a C programmer.
Fair enough, but you were warned:"The first sign of danger was the entire code base is written in C,"What this section of the article really lacks is a description of the struct(ure)s that s and ss point to.
Maybe this is a simple linked list, and 'next' would make sense.
Maybe it's a tree of some sort.
Maybe ss had a contextual meaning that the author obliterated in his attempt to make a point.A cynic might point out that this is a self-confessed 'web development' author, but that would just degrade this post to his level.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344638</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343770</id>
	<title>Re:Subs and functions</title>
	<author>Anonymous</author>
	<datestamp>1260121200000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>Functions have their place, Subroutines have their place.  Global variables have their place.  Static variables, Heap variables, and stack variables have their place. Even a Go To has it's place (in rare cases).</p><p>The point is to use these tools in such a way that someone else can figure out what you're doing.</p><p>On the other hand, as Albert Einstein is reputed to have said, things should be simplified as much as possible, but no farther.  If the code is obtuse, sometimes it is because the programmer doesn't understand the background of what it is supposed to do. In other words, if you understand Digital Signal Processing, someone's code may look quite elegant.  If you don't understand it, it looks obtuse.</p><p>We'd all like to think that good programming is simply a matter of writing reasonably concise and well documented code.  But it isn't.  One needs an education on the subject being programmed. If you don't know the subject well enough, no amount of documentation is going to help you.</p></htmltext>
<tokenext>Functions have their place , Subroutines have their place .
Global variables have their place .
Static variables , Heap variables , and stack variables have their place .
Even a Go To has it 's place ( in rare cases ) .The point is to use these tools in such a way that someone else can figure out what you 're doing.On the other hand , as Albert Einstein is reputed to have said , things should be simplified as much as possible , but no farther .
If the code is obtuse , sometimes it is because the programmer does n't understand the background of what it is supposed to do .
In other words , if you understand Digital Signal Processing , someone 's code may look quite elegant .
If you do n't understand it , it looks obtuse.We 'd all like to think that good programming is simply a matter of writing reasonably concise and well documented code .
But it is n't .
One needs an education on the subject being programmed .
If you do n't know the subject well enough , no amount of documentation is going to help you .</tokentext>
<sentencetext>Functions have their place, Subroutines have their place.
Global variables have their place.
Static variables, Heap variables, and stack variables have their place.
Even a Go To has it's place (in rare cases).The point is to use these tools in such a way that someone else can figure out what you're doing.On the other hand, as Albert Einstein is reputed to have said, things should be simplified as much as possible, but no farther.
If the code is obtuse, sometimes it is because the programmer doesn't understand the background of what it is supposed to do.
In other words, if you understand Digital Signal Processing, someone's code may look quite elegant.
If you don't understand it, it looks obtuse.We'd all like to think that good programming is simply a matter of writing reasonably concise and well documented code.
But it isn't.
One needs an education on the subject being programmed.
If you don't know the subject well enough, no amount of documentation is going to help you.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343546</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345666</id>
	<title>Be careful what you wish for...</title>
	<author>gillbates</author>
	<datestamp>1260092400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>
You just might get it.
</p><p>
I have seen the opposite problem crop up: an institution so focused on creating code according to standards that they actually make the situation worse:
</p><ul> <li>First, management belongs to a project management book-of-the-month club.  Every project has rigid documentation and coding standards, but unfortunately, they are all different.  Even if there were no comments in the code, it could be dated by the design pattern and/or coding style used.  The result?  A myriad of different, inconsistent coding styles, all the product of management directives.</li>
<li>The coding standards are laughable and outdated: I've seen requirements to use Hungarian notation, requiring macros for structure access (because, apparently, my\_struct.my\_field is just too confusing...), ridiculous namespace standards (why use a namespace if you're going to prefix the name anyway?), etc...</li>
<li>Mandatory comment blocks of monstrous size that make it impossible to see the forest through the trees.  Yes, I understand documenting what is being done, or why, but there is no reason why a comment block should contain pseudocode describing the logic used.  The code is already there!</li>
<li>Asinine physical design requirements, such as limiting files to only one function, making it rather difficult to view a group of functions as a logical module.</li>
<li>The required use of design anti-patterns, such as the Facade pattern, or the Endless-Wrapper pattern, where every OS call must be slowed down by an additional layer of indirection.  Or, more frequently, the Class-Explosion anti-pattern, where even a strncmp() must be abstracted into its own class object.</li>
<li>The required use of symbolic constants instead of "Magic Numbers".  The use of symbolic constants is normally a Good Thing(TM), except in cases where they make the code harder to read.  Consider the following code: "ready = register &amp; LOW\_BITS;"  So, which bits are set after the assignment?  Oh, that's right, you can't tell without tracking down the header file with LOW\_BITS in it.  Granted, you can do this.  But if you work with embedded software, it gets rather tedious after a few dozen times.  "ready = register &amp; 0x03;" is much clearer.  Symbolic constants make debugging a real chore, because you can't verify the correctness of a statement merely by reading that statement; you must track down all of the headers.  Worse, I've seen them nested more than 3 levels deep, split across multiple header files.</li>
</ul><p>
So, be careful what you ask for, you might just get it.  Generally speaking, it's easier to convince a sloppy programmer to write better code than it is to justify a deviation from already-established, albeit improper, coding standards.
</p></htmltext>
<tokenext>You just might get it .
I have seen the opposite problem crop up : an institution so focused on creating code according to standards that they actually make the situation worse : First , management belongs to a project management book-of-the-month club .
Every project has rigid documentation and coding standards , but unfortunately , they are all different .
Even if there were no comments in the code , it could be dated by the design pattern and/or coding style used .
The result ?
A myriad of different , inconsistent coding styles , all the product of management directives .
The coding standards are laughable and outdated : I 've seen requirements to use Hungarian notation , requiring macros for structure access ( because , apparently , my \ _struct.my \ _field is just too confusing... ) , ridiculous namespace standards ( why use a namespace if you 're going to prefix the name anyway ?
) , etc.. . Mandatory comment blocks of monstrous size that make it impossible to see the forest through the trees .
Yes , I understand documenting what is being done , or why , but there is no reason why a comment block should contain pseudocode describing the logic used .
The code is already there !
Asinine physical design requirements , such as limiting files to only one function , making it rather difficult to view a group of functions as a logical module .
The required use of design anti-patterns , such as the Facade pattern , or the Endless-Wrapper pattern , where every OS call must be slowed down by an additional layer of indirection .
Or , more frequently , the Class-Explosion anti-pattern , where even a strncmp ( ) must be abstracted into its own class object .
The required use of symbolic constants instead of " Magic Numbers " .
The use of symbolic constants is normally a Good Thing ( TM ) , except in cases where they make the code harder to read .
Consider the following code : " ready = register &amp; LOW \ _BITS ; " So , which bits are set after the assignment ?
Oh , that 's right , you ca n't tell without tracking down the header file with LOW \ _BITS in it .
Granted , you can do this .
But if you work with embedded software , it gets rather tedious after a few dozen times .
" ready = register &amp; 0x03 ; " is much clearer .
Symbolic constants make debugging a real chore , because you ca n't verify the correctness of a statement merely by reading that statement ; you must track down all of the headers .
Worse , I 've seen them nested more than 3 levels deep , split across multiple header files .
So , be careful what you ask for , you might just get it .
Generally speaking , it 's easier to convince a sloppy programmer to write better code than it is to justify a deviation from already-established , albeit improper , coding standards .</tokentext>
<sentencetext>
You just might get it.
I have seen the opposite problem crop up: an institution so focused on creating code according to standards that they actually make the situation worse:
 First, management belongs to a project management book-of-the-month club.
Every project has rigid documentation and coding standards, but unfortunately, they are all different.
Even if there were no comments in the code, it could be dated by the design pattern and/or coding style used.
The result?
A myriad of different, inconsistent coding styles, all the product of management directives.
The coding standards are laughable and outdated: I've seen requirements to use Hungarian notation, requiring macros for structure access (because, apparently, my\_struct.my\_field is just too confusing...), ridiculous namespace standards (why use a namespace if you're going to prefix the name anyway?
), etc...
Mandatory comment blocks of monstrous size that make it impossible to see the forest through the trees.
Yes, I understand documenting what is being done, or why, but there is no reason why a comment block should contain pseudocode describing the logic used.
The code is already there!
Asinine physical design requirements, such as limiting files to only one function, making it rather difficult to view a group of functions as a logical module.
The required use of design anti-patterns, such as the Facade pattern, or the Endless-Wrapper pattern, where every OS call must be slowed down by an additional layer of indirection.
Or, more frequently, the Class-Explosion anti-pattern, where even a strncmp() must be abstracted into its own class object.
The required use of symbolic constants instead of "Magic Numbers".
The use of symbolic constants is normally a Good Thing(TM), except in cases where they make the code harder to read.
Consider the following code: "ready = register &amp; LOW\_BITS;"  So, which bits are set after the assignment?
Oh, that's right, you can't tell without tracking down the header file with LOW\_BITS in it.
Granted, you can do this.
But if you work with embedded software, it gets rather tedious after a few dozen times.
"ready = register &amp; 0x03;" is much clearer.
Symbolic constants make debugging a real chore, because you can't verify the correctness of a statement merely by reading that statement; you must track down all of the headers.
Worse, I've seen them nested more than 3 levels deep, split across multiple header files.
So, be careful what you ask for, you might just get it.
Generally speaking, it's easier to convince a sloppy programmer to write better code than it is to justify a deviation from already-established, albeit improper, coding standards.
</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30348144</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>Anonymous</author>
	<datestamp>1260110160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>As a sophomore CS student, that code took me 10 seconds to figure out as a linked list traversal.</p><p>I'm with the comment above: TFA author seems ignorant of pointers.</p></htmltext>
<tokenext>As a sophomore CS student , that code took me 10 seconds to figure out as a linked list traversal.I 'm with the comment above : TFA author seems ignorant of pointers .</tokentext>
<sentencetext>As a sophomore CS student, that code took me 10 seconds to figure out as a linked list traversal.I'm with the comment above: TFA author seems ignorant of pointers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344638</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346802</id>
	<title>Re:Subs and functions</title>
	<author>A Friendly Troll</author>
	<datestamp>1260100680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Functions have their place, Subroutines have their place. Global variables have their place. Static variables, Heap variables, and stack variables have their place. Even a Go To has it's place (in rare cases).</p><p>The point is to use these tools in such a way that someone else can figure out what you're doing.</p></div><p>Yes, that is true.</p><p>But in my case, for example, a variable named "i" (obviously for "integer") is used in a million places. The only way to figure out how something works is to run everything through a debugger, step through, and use pencil and paper to map the flow of the variables from one sub to another. Sometimes one sub will "accept" "i" and "return" "i", sometimes it will place the result in "ii". Sometimes the code will throw you a red herring because it will "return" the result but it won't be used anywhere else in the process; well, of course, the tenth sub in the chain might overwrite it so that the eleventh may use it, and god help you if you've missed the tenth sub and thought "why the fuck is the eleventh sub doing this when 'i' was 5 just a moment ago?!".</p><p>The code is usually beyond fixing. It takes more time to figure it out and refactor than to properly rewrite everything from scratch after asking the end user what a certain part of the application should be doing.</p><p>Coding practices are nice and all, but they can't get around idiots. To put it differently, a lack of unified and useful coding practices is merely a minor inconvenience, whereas a programming moron is a clusterfuck.</p></div>
	</htmltext>
<tokenext>Functions have their place , Subroutines have their place .
Global variables have their place .
Static variables , Heap variables , and stack variables have their place .
Even a Go To has it 's place ( in rare cases ) .The point is to use these tools in such a way that someone else can figure out what you 're doing.Yes , that is true.But in my case , for example , a variable named " i " ( obviously for " integer " ) is used in a million places .
The only way to figure out how something works is to run everything through a debugger , step through , and use pencil and paper to map the flow of the variables from one sub to another .
Sometimes one sub will " accept " " i " and " return " " i " , sometimes it will place the result in " ii " .
Sometimes the code will throw you a red herring because it will " return " the result but it wo n't be used anywhere else in the process ; well , of course , the tenth sub in the chain might overwrite it so that the eleventh may use it , and god help you if you 've missed the tenth sub and thought " why the fuck is the eleventh sub doing this when 'i ' was 5 just a moment ago ? !
" .The code is usually beyond fixing .
It takes more time to figure it out and refactor than to properly rewrite everything from scratch after asking the end user what a certain part of the application should be doing.Coding practices are nice and all , but they ca n't get around idiots .
To put it differently , a lack of unified and useful coding practices is merely a minor inconvenience , whereas a programming moron is a clusterfuck .</tokentext>
<sentencetext>Functions have their place, Subroutines have their place.
Global variables have their place.
Static variables, Heap variables, and stack variables have their place.
Even a Go To has it's place (in rare cases).The point is to use these tools in such a way that someone else can figure out what you're doing.Yes, that is true.But in my case, for example, a variable named "i" (obviously for "integer") is used in a million places.
The only way to figure out how something works is to run everything through a debugger, step through, and use pencil and paper to map the flow of the variables from one sub to another.
Sometimes one sub will "accept" "i" and "return" "i", sometimes it will place the result in "ii".
Sometimes the code will throw you a red herring because it will "return" the result but it won't be used anywhere else in the process; well, of course, the tenth sub in the chain might overwrite it so that the eleventh may use it, and god help you if you've missed the tenth sub and thought "why the fuck is the eleventh sub doing this when 'i' was 5 just a moment ago?!
".The code is usually beyond fixing.
It takes more time to figure it out and refactor than to properly rewrite everything from scratch after asking the end user what a certain part of the application should be doing.Coding practices are nice and all, but they can't get around idiots.
To put it differently, a lack of unified and useful coding practices is merely a minor inconvenience, whereas a programming moron is a clusterfuck.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343770</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343622</id>
	<title>What is clear to one ...</title>
	<author>Anonymous</author>
	<datestamp>1260119940000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>I work in an environment where there are 4 programmers, of varying skill. What is "clear" to one is not necessarily clear to another, even if it is straight-forward coding. For example, I might program a loop to iterate through an array of data, extracting the important information, while another might explicitly write out each iteration, because he is less familiar with arrays. His code is quite clear - but inflexible, and subject to errors if he makes a required change to 19 of 20 copies of the calculations. Mine is quite clear, but subject to some obscuration if there's something special that has to be done in 3 of the 20 iterations.</p><p>In the case of TFA, if the author were this other programmer, he might consider my code to be "too clever".</p><p>Much was made of the use of "obscure" variables. Yes, that's one I dislike a lot, too... but I haven't made too much progress on that score in 25 years, with regard to others. When you're working on code that requires a lot of manipulation of a variable, typing a long, descriptive name 65 times is a bit of a PITA, and subject to its own bugs, when you misspell it a few times!</p></htmltext>
<tokenext>I work in an environment where there are 4 programmers , of varying skill .
What is " clear " to one is not necessarily clear to another , even if it is straight-forward coding .
For example , I might program a loop to iterate through an array of data , extracting the important information , while another might explicitly write out each iteration , because he is less familiar with arrays .
His code is quite clear - but inflexible , and subject to errors if he makes a required change to 19 of 20 copies of the calculations .
Mine is quite clear , but subject to some obscuration if there 's something special that has to be done in 3 of the 20 iterations.In the case of TFA , if the author were this other programmer , he might consider my code to be " too clever " .Much was made of the use of " obscure " variables .
Yes , that 's one I dislike a lot , too... but I have n't made too much progress on that score in 25 years , with regard to others .
When you 're working on code that requires a lot of manipulation of a variable , typing a long , descriptive name 65 times is a bit of a PITA , and subject to its own bugs , when you misspell it a few times !</tokentext>
<sentencetext>I work in an environment where there are 4 programmers, of varying skill.
What is "clear" to one is not necessarily clear to another, even if it is straight-forward coding.
For example, I might program a loop to iterate through an array of data, extracting the important information, while another might explicitly write out each iteration, because he is less familiar with arrays.
His code is quite clear - but inflexible, and subject to errors if he makes a required change to 19 of 20 copies of the calculations.
Mine is quite clear, but subject to some obscuration if there's something special that has to be done in 3 of the 20 iterations.In the case of TFA, if the author were this other programmer, he might consider my code to be "too clever".Much was made of the use of "obscure" variables.
Yes, that's one I dislike a lot, too... but I haven't made too much progress on that score in 25 years, with regard to others.
When you're working on code that requires a lot of manipulation of a variable, typing a long, descriptive name 65 times is a bit of a PITA, and subject to its own bugs, when you misspell it a few times!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345378</id>
	<title>Re:Literate Programming</title>
	<author>Anonymous</author>
	<datestamp>1260090000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I'm sorry, but I can't help but disagree with this sentence. The purpose of creating a program really is to instruct the computer what to do. Not to explain other human beings what we want the computer to do.</p></div><p>I hope I never have to read your code.</p></div>
	</htmltext>
<tokenext>I 'm sorry , but I ca n't help but disagree with this sentence .
The purpose of creating a program really is to instruct the computer what to do .
Not to explain other human beings what we want the computer to do.I hope I never have to read your code .</tokentext>
<sentencetext>I'm sorry, but I can't help but disagree with this sentence.
The purpose of creating a program really is to instruct the computer what to do.
Not to explain other human beings what we want the computer to do.I hope I never have to read your code.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343946</id>
	<title>Test Driven Development</title>
	<author>ixl</author>
	<datestamp>1260122700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>TDD, TDD, and more TDD. If it's too clever to maintain, than it's not testable. When done properly, test driven development functions very well as a guard against that sort of thing.

The converse is also true, by the way. If something is very clever, but written in a testable way, than it's likely to be maintainable and easy to read. Even if it's not easy to read, the tests allow it to be refactored into an easy to read form without breaking anything.</htmltext>
<tokenext>TDD , TDD , and more TDD .
If it 's too clever to maintain , than it 's not testable .
When done properly , test driven development functions very well as a guard against that sort of thing .
The converse is also true , by the way .
If something is very clever , but written in a testable way , than it 's likely to be maintainable and easy to read .
Even if it 's not easy to read , the tests allow it to be refactored into an easy to read form without breaking anything .</tokentext>
<sentencetext>TDD, TDD, and more TDD.
If it's too clever to maintain, than it's not testable.
When done properly, test driven development functions very well as a guard against that sort of thing.
The converse is also true, by the way.
If something is very clever, but written in a testable way, than it's likely to be maintainable and easy to read.
Even if it's not easy to read, the tests allow it to be refactored into an easy to read form without breaking anything.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30360564</id>
	<title>Re:Too MUCH of this</title>
	<author>Anonymous</author>
	<datestamp>1260197880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>That code does not increment i.</p><p>I'd like to credit you with an attempt at humor, but I highly doubt it.</p></htmltext>
<tokenext>That code does not increment i.I 'd like to credit you with an attempt at humor , but I highly doubt it .</tokentext>
<sentencetext>That code does not increment i.I'd like to credit you with an attempt at humor, but I highly doubt it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343900</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343746</id>
	<title>Practices..</title>
	<author>JoeZilla</author>
	<datestamp>1260121080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>When will people finally realize that defining and documenting practices alone doesn't make good code? You need good programmers that care and that monitor each others and (more junior) programmers' code quality. Encourage feedback between the programmers, etc.</p></htmltext>
<tokenext>When will people finally realize that defining and documenting practices alone does n't make good code ?
You need good programmers that care and that monitor each others and ( more junior ) programmers ' code quality .
Encourage feedback between the programmers , etc .</tokentext>
<sentencetext>When will people finally realize that defining and documenting practices alone doesn't make good code?
You need good programmers that care and that monitor each others and (more junior) programmers' code quality.
Encourage feedback between the programmers, etc.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344800</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>Anonymous</author>
	<datestamp>1260129120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>It took me 20 seconds to understand the code and it's over 9 year since I've programmed in C/C++. The "problem" is not the clever code but the new "clever" programmers.</p></htmltext>
<tokenext>It took me 20 seconds to understand the code and it 's over 9 year since I 've programmed in C/C + + .
The " problem " is not the clever code but the new " clever " programmers .</tokentext>
<sentencetext>It took me 20 seconds to understand the code and it's over 9 year since I've programmed in C/C++.
The "problem" is not the clever code but the new "clever" programmers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30355890</id>
	<title>Re:Literate Programming</title>
	<author>Anonymous</author>
	<datestamp>1260214200000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>High level languages are a convenience for humans, not computers. So write your code as though humans mattered.</p></htmltext>
<tokenext>High level languages are a convenience for humans , not computers .
So write your code as though humans mattered .</tokentext>
<sentencetext>High level languages are a convenience for humans, not computers.
So write your code as though humans mattered.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343666</id>
	<title>Lowest Common Denominator</title>
	<author>Anonymous</author>
	<datestamp>1260120300000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>0</modscore>
	<htmltext><p>Why should I write my code so that the lowest-common-denominator dull thud who took CSci just for the money can come along five years later and maintain it?  I agree that good coding practices produce readable code.  But too often this whole topic leads into the idea that all code should be McCode, meaning blah standards-conforming blocks, often not even approaching the best possible solution to a problem.</p><p>Sorry.  Not a priority.  And no, I don't care that you won't hire me.  You want an assembly line slinger.  And will pay accordingly.</p></htmltext>
<tokenext>Why should I write my code so that the lowest-common-denominator dull thud who took CSci just for the money can come along five years later and maintain it ?
I agree that good coding practices produce readable code .
But too often this whole topic leads into the idea that all code should be McCode , meaning blah standards-conforming blocks , often not even approaching the best possible solution to a problem.Sorry .
Not a priority .
And no , I do n't care that you wo n't hire me .
You want an assembly line slinger .
And will pay accordingly .</tokentext>
<sentencetext>Why should I write my code so that the lowest-common-denominator dull thud who took CSci just for the money can come along five years later and maintain it?
I agree that good coding practices produce readable code.
But too often this whole topic leads into the idea that all code should be McCode, meaning blah standards-conforming blocks, often not even approaching the best possible solution to a problem.Sorry.
Not a priority.
And no, I don't care that you won't hire me.
You want an assembly line slinger.
And will pay accordingly.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345546</id>
	<title>Code editors</title>
	<author>arjan\_t</author>
	<datestamp>1260091440000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>
We deal with this by using something that can be described as <i>code editors</i>.
</p><p>
These are people that edit raw code committed by other programmers and refactor it in order to comply with a set of standards. Editing may entail just changing a few variable names, but it can also be almost a complete rewrite of the code. Of course, if code rewrites become the rule rather than the exception, something is wrong and some serious talks with the original programmer will be necessary.
</p><p>
As long as the code editors are knowledgeable people and agree among themselves about the specific style, best practices and architecture to be used, this can greatly improve the quality and consistency of the code.
</p></htmltext>
<tokenext>We deal with this by using something that can be described as code editors .
These are people that edit raw code committed by other programmers and refactor it in order to comply with a set of standards .
Editing may entail just changing a few variable names , but it can also be almost a complete rewrite of the code .
Of course , if code rewrites become the rule rather than the exception , something is wrong and some serious talks with the original programmer will be necessary .
As long as the code editors are knowledgeable people and agree among themselves about the specific style , best practices and architecture to be used , this can greatly improve the quality and consistency of the code .</tokentext>
<sentencetext>
We deal with this by using something that can be described as code editors.
These are people that edit raw code committed by other programmers and refactor it in order to comply with a set of standards.
Editing may entail just changing a few variable names, but it can also be almost a complete rewrite of the code.
Of course, if code rewrites become the rule rather than the exception, something is wrong and some serious talks with the original programmer will be necessary.
As long as the code editors are knowledgeable people and agree among themselves about the specific style, best practices and architecture to be used, this can greatly improve the quality and consistency of the code.
</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346064</id>
	<title>Not that hard.</title>
	<author>paxcoder</author>
	<datestamp>1260096060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The code mentioned on the linked page:<br>for(ss = s-&gt;ss; ss; ss = ss-&gt;ss)<br>I'm sorry, but that's obviously moving through a linked list untill the end (NULL == false) pointer.</p></htmltext>
<tokenext>The code mentioned on the linked page : for ( ss = s- &gt; ss ; ss ; ss = ss- &gt; ss ) I 'm sorry , but that 's obviously moving through a linked list untill the end ( NULL = = false ) pointer .</tokentext>
<sentencetext>The code mentioned on the linked page:for(ss = s-&gt;ss; ss; ss = ss-&gt;ss)I'm sorry, but that's obviously moving through a linked list untill the end (NULL == false) pointer.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343834</id>
	<title>Coding style</title>
	<author>tomhath</author>
	<datestamp>1260121740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Coding style is a no brainer for most languages: Use the default that your IDE provides. Or lacking that, whatever the "prittyprinter" program produces. If someone violates the style convention, the IDE or pretty printer will clean it up.

Design reviews, code reviews, and updated documentation are unquestionably good ideas but they have to be budgeted in at the start. A project manager who's afraid of missing a delivery will treat them as slack in the schedule and let them go even faster than they will squeeze the testing schedule (but that's another story).</htmltext>
<tokenext>Coding style is a no brainer for most languages : Use the default that your IDE provides .
Or lacking that , whatever the " prittyprinter " program produces .
If someone violates the style convention , the IDE or pretty printer will clean it up .
Design reviews , code reviews , and updated documentation are unquestionably good ideas but they have to be budgeted in at the start .
A project manager who 's afraid of missing a delivery will treat them as slack in the schedule and let them go even faster than they will squeeze the testing schedule ( but that 's another story ) .</tokentext>
<sentencetext>Coding style is a no brainer for most languages: Use the default that your IDE provides.
Or lacking that, whatever the "prittyprinter" program produces.
If someone violates the style convention, the IDE or pretty printer will clean it up.
Design reviews, code reviews, and updated documentation are unquestionably good ideas but they have to be budgeted in at the start.
A project manager who's afraid of missing a delivery will treat them as slack in the schedule and let them go even faster than they will squeeze the testing schedule (but that's another story).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344424</id>
	<title>Re:Literate Programming</title>
	<author>CAOgdin</author>
	<datestamp>1260126480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Perhaps you've forgotten:  Computers are here to serve human beings, not the other way 'round. <br> <br>

There is a fundamental lack of engineering principles in programming, which leads to a lot of lousy programs.  When I apply good engineering practice to software design, it always turns out better in the end, especially when you realize that you're not writing "A" program, but the first of a series of ever-changing (hopefully "ever-improving"( programs, which we identify as "versions."  Even tiny scripts of mine have gone through many iterations as I discover conditions under which they don't perform, or I discover a new capability that has become important, now that users (and I) have gained experience with the original.<br> <br>

Until programmers realize they must have a DISCIPLINED approach, we'll contine to implement software that is evolved through the finding of bugs, instead of focusing on getting it right the first time.</htmltext>
<tokenext>Perhaps you 've forgotten : Computers are here to serve human beings , not the other way 'round .
There is a fundamental lack of engineering principles in programming , which leads to a lot of lousy programs .
When I apply good engineering practice to software design , it always turns out better in the end , especially when you realize that you 're not writing " A " program , but the first of a series of ever-changing ( hopefully " ever-improving " ( programs , which we identify as " versions .
" Even tiny scripts of mine have gone through many iterations as I discover conditions under which they do n't perform , or I discover a new capability that has become important , now that users ( and I ) have gained experience with the original .
Until programmers realize they must have a DISCIPLINED approach , we 'll contine to implement software that is evolved through the finding of bugs , instead of focusing on getting it right the first time .</tokentext>
<sentencetext>Perhaps you've forgotten:  Computers are here to serve human beings, not the other way 'round.
There is a fundamental lack of engineering principles in programming, which leads to a lot of lousy programs.
When I apply good engineering practice to software design, it always turns out better in the end, especially when you realize that you're not writing "A" program, but the first of a series of ever-changing (hopefully "ever-improving"( programs, which we identify as "versions.
"  Even tiny scripts of mine have gone through many iterations as I discover conditions under which they don't perform, or I discover a new capability that has become important, now that users (and I) have gained experience with the original.
Until programmers realize they must have a DISCIPLINED approach, we'll contine to implement software that is evolved through the finding of bugs, instead of focusing on getting it right the first time.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344830</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>hey</author>
	<datestamp>1260129300000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>You make some good points but</p><p>for(ss = s-&gt;ss; ss; ss = ss-&gt;ss)</p><p>could be better written</p><p>for(p = s-&gt;next; p; p = p-&gt;next)</p></htmltext>
<tokenext>You make some good points butfor ( ss = s- &gt; ss ; ss ; ss = ss- &gt; ss ) could be better writtenfor ( p = s- &gt; next ; p ; p = p- &gt; next )</tokentext>
<sentencetext>You make some good points butfor(ss = s-&gt;ss; ss; ss = ss-&gt;ss)could be better writtenfor(p = s-&gt;next; p; p = p-&gt;next)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344050</id>
	<title>Treat comment bugs like code bugs</title>
	<author>presidenteloco</author>
	<datestamp>1260123600000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>They are just as serious. Updating/"maintaining" a piece of code and not updating the comment<br>should be made into close to a firing offense, after the suitable number of admonitions.</p><p>The biggest weakness I find with code I review is that the programmers seem to be either<br>inarticulate, lazy, smug, or exhibiting Aspergers syndrome (lack of empathy), in that they forget to<br>include the most important comment for any method or class;</p><p>The "What the h*ll is this?" comment that explains the gist of the method/class and why and<br>in what contexts one should care about it.</p><p>Also frequently missing is the considerate: "Mind the low headroom" comment.</p></htmltext>
<tokenext>They are just as serious .
Updating/ " maintaining " a piece of code and not updating the commentshould be made into close to a firing offense , after the suitable number of admonitions.The biggest weakness I find with code I review is that the programmers seem to be eitherinarticulate , lazy , smug , or exhibiting Aspergers syndrome ( lack of empathy ) , in that they forget toinclude the most important comment for any method or class ; The " What the h * ll is this ?
" comment that explains the gist of the method/class and why andin what contexts one should care about it.Also frequently missing is the considerate : " Mind the low headroom " comment .</tokentext>
<sentencetext>They are just as serious.
Updating/"maintaining" a piece of code and not updating the commentshould be made into close to a firing offense, after the suitable number of admonitions.The biggest weakness I find with code I review is that the programmers seem to be eitherinarticulate, lazy, smug, or exhibiting Aspergers syndrome (lack of empathy), in that they forget toinclude the most important comment for any method or class;The "What the h*ll is this?
" comment that explains the gist of the method/class and why andin what contexts one should care about it.Also frequently missing is the considerate: "Mind the low headroom" comment.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30351972</id>
	<title>Re:Literate Programming</title>
	<author>YeeHaW\_Jelte</author>
	<datestamp>1260196620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"If we program without prioritizing the computer, we may end up writing something that may look, to us and anyone else that reads it, like what we want the computer to do, but the computer my not take it that well..."</p><p>Computers are excellent in seperating comments from code. Pray tell me how using extensive commenting to inform other programmers of your intentions might confuse the computer<nobr> <wbr></nobr>...</p></htmltext>
<tokenext>" If we program without prioritizing the computer , we may end up writing something that may look , to us and anyone else that reads it , like what we want the computer to do , but the computer my not take it that well... " Computers are excellent in seperating comments from code .
Pray tell me how using extensive commenting to inform other programmers of your intentions might confuse the computer .. .</tokentext>
<sentencetext>"If we program without prioritizing the computer, we may end up writing something that may look, to us and anyone else that reads it, like what we want the computer to do, but the computer my not take it that well..."Computers are excellent in seperating comments from code.
Pray tell me how using extensive commenting to inform other programmers of your intentions might confuse the computer ...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344256</id>
	<title>Old comments are good</title>
	<author>Anonymous</author>
	<datestamp>1260125280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I worked on some code where there was a comment from a few revisions before. I believe people who comment their code usually create better code then the people who don't comment or who don't update comments. The code and the comment were out of sync and now there was a problem. After reading the old comments I realized that whoever updated the code didn't understand the general design the original author had intended. I changed the code to correspond to the comment and the bug was fixed. The old comment saved me a headache. I comment regardless of "official" practices because I know months or years from now I might be the person trying to fix some code I wrote. With the turnover in software and software teams these days people don't believe they'll have to fix their own code and hence think they'll be able to keep everything in their mind until the next job. Maybe it's to save time but the same practice of typing less would be better practiced by taking your hands off the keyboard for a second and thinking about writing maintainable code. If people are going to cut and paste then change a few things to make it quite clear what they should cut and paste. If you are doing some boilerplate stuff that you know people try to turn into some generic thing change the variable names in all the versions of your boilerplate stuff. They won't notice the code is very similar and they'll actually take a second to understand the basic boilerplate design instead of cutting and pasting it. Push the sophisticated stuff in a super class and put the simpler stuff in subclasses. People who create a subclass at a drop of a hat won't be creating a mess that is hard to fix. Enforce conventions by putting in code that does. Put in a comment that says the code will explode without it. People who understand will laugh at the comment and the ones who don't know better won't dare take the code out. Make it easy to do the right thing and make it hard to do the wrong thing. Sounds like a nasty bunch of tricks but I've gotten numerous comments about how easy my code is to maintain. Too many and if I wasn't fighting managers to help "fix someone's code" I probably wouldn't be writing new code.</p></htmltext>
<tokenext>I worked on some code where there was a comment from a few revisions before .
I believe people who comment their code usually create better code then the people who do n't comment or who do n't update comments .
The code and the comment were out of sync and now there was a problem .
After reading the old comments I realized that whoever updated the code did n't understand the general design the original author had intended .
I changed the code to correspond to the comment and the bug was fixed .
The old comment saved me a headache .
I comment regardless of " official " practices because I know months or years from now I might be the person trying to fix some code I wrote .
With the turnover in software and software teams these days people do n't believe they 'll have to fix their own code and hence think they 'll be able to keep everything in their mind until the next job .
Maybe it 's to save time but the same practice of typing less would be better practiced by taking your hands off the keyboard for a second and thinking about writing maintainable code .
If people are going to cut and paste then change a few things to make it quite clear what they should cut and paste .
If you are doing some boilerplate stuff that you know people try to turn into some generic thing change the variable names in all the versions of your boilerplate stuff .
They wo n't notice the code is very similar and they 'll actually take a second to understand the basic boilerplate design instead of cutting and pasting it .
Push the sophisticated stuff in a super class and put the simpler stuff in subclasses .
People who create a subclass at a drop of a hat wo n't be creating a mess that is hard to fix .
Enforce conventions by putting in code that does .
Put in a comment that says the code will explode without it .
People who understand will laugh at the comment and the ones who do n't know better wo n't dare take the code out .
Make it easy to do the right thing and make it hard to do the wrong thing .
Sounds like a nasty bunch of tricks but I 've gotten numerous comments about how easy my code is to maintain .
Too many and if I was n't fighting managers to help " fix someone 's code " I probably would n't be writing new code .</tokentext>
<sentencetext>I worked on some code where there was a comment from a few revisions before.
I believe people who comment their code usually create better code then the people who don't comment or who don't update comments.
The code and the comment were out of sync and now there was a problem.
After reading the old comments I realized that whoever updated the code didn't understand the general design the original author had intended.
I changed the code to correspond to the comment and the bug was fixed.
The old comment saved me a headache.
I comment regardless of "official" practices because I know months or years from now I might be the person trying to fix some code I wrote.
With the turnover in software and software teams these days people don't believe they'll have to fix their own code and hence think they'll be able to keep everything in their mind until the next job.
Maybe it's to save time but the same practice of typing less would be better practiced by taking your hands off the keyboard for a second and thinking about writing maintainable code.
If people are going to cut and paste then change a few things to make it quite clear what they should cut and paste.
If you are doing some boilerplate stuff that you know people try to turn into some generic thing change the variable names in all the versions of your boilerplate stuff.
They won't notice the code is very similar and they'll actually take a second to understand the basic boilerplate design instead of cutting and pasting it.
Push the sophisticated stuff in a super class and put the simpler stuff in subclasses.
People who create a subclass at a drop of a hat won't be creating a mess that is hard to fix.
Enforce conventions by putting in code that does.
Put in a comment that says the code will explode without it.
People who understand will laugh at the comment and the ones who don't know better won't dare take the code out.
Make it easy to do the right thing and make it hard to do the wrong thing.
Sounds like a nasty bunch of tricks but I've gotten numerous comments about how easy my code is to maintain.
Too many and if I wasn't fighting managers to help "fix someone's code" I probably wouldn't be writing new code.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345644</id>
	<title>Re:Literate Programming</title>
	<author>Anonymous</author>
	<datestamp>1260092280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>I'm sorry, but I can't help but disagree with this sentence. The purpose of creating a program really is to instruct the computer what to do. Not to explain other human beings what we want the computer to do.</p></div><p>80\% of the cost of software is maintenance.</p><p><div class="quote"><p>Computers don't do what we want, they do what we tell them to do. Success in programming a computer comes from telling it what we want it to do.</p></div><p>True... if you never have to maintain your code and you are the only person working on it.</p><p><div class="quote"><p>One must not compromise the precision of the orders it gives to the computer in order to achieve readability by something/someone else than the computer.</p></div><p>Totally disagree with you.  ALL code is precise.  The computer doesn't care if it is clever or clear, people do.  So Clear is always better.</p><p><div class="quote"><p>If we program without prioritizing the computer, we may end up writing something that may look, to us and anyone else that reads it, like what we want the computer to do, but the computer my not take it that well...</p></div><p>See above.  The computer doesnt care if the directions are clever or clear.  It just does what you tell it.</p></div>
	</htmltext>
<tokenext>I 'm sorry , but I ca n't help but disagree with this sentence .
The purpose of creating a program really is to instruct the computer what to do .
Not to explain other human beings what we want the computer to do.80 \ % of the cost of software is maintenance.Computers do n't do what we want , they do what we tell them to do .
Success in programming a computer comes from telling it what we want it to do.True... if you never have to maintain your code and you are the only person working on it.One must not compromise the precision of the orders it gives to the computer in order to achieve readability by something/someone else than the computer.Totally disagree with you .
ALL code is precise .
The computer does n't care if it is clever or clear , people do .
So Clear is always better.If we program without prioritizing the computer , we may end up writing something that may look , to us and anyone else that reads it , like what we want the computer to do , but the computer my not take it that well...See above .
The computer doesnt care if the directions are clever or clear .
It just does what you tell it .</tokentext>
<sentencetext>I'm sorry, but I can't help but disagree with this sentence.
The purpose of creating a program really is to instruct the computer what to do.
Not to explain other human beings what we want the computer to do.80\% of the cost of software is maintenance.Computers don't do what we want, they do what we tell them to do.
Success in programming a computer comes from telling it what we want it to do.True... if you never have to maintain your code and you are the only person working on it.One must not compromise the precision of the orders it gives to the computer in order to achieve readability by something/someone else than the computer.Totally disagree with you.
ALL code is precise.
The computer doesn't care if it is clever or clear, people do.
So Clear is always better.If we program without prioritizing the computer, we may end up writing something that may look, to us and anyone else that reads it, like what we want the computer to do, but the computer my not take it that well...See above.
The computer doesnt care if the directions are clever or clear.
It just does what you tell it.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345062</id>
	<title>it doesn't actually traverse a linked list...</title>
	<author>Anonymous</author>
	<datestamp>1260130920000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>... in any \_useful\_ fashion.  Notice that semicolon at the end of the line after the closing bracket?</p><p>D'oh!</p></htmltext>
<tokenext>... in any \ _useful \ _ fashion .
Notice that semicolon at the end of the line after the closing bracket ? D'oh !</tokentext>
<sentencetext>... in any \_useful\_ fashion.
Notice that semicolon at the end of the line after the closing bracket?D'oh!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345418</id>
	<title>Re:Teams</title>
	<author>thethibs</author>
	<datestamp>1260090240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>You really should make up your mind. Are they 'hotshots' or incompetent. You can't have it both ways.</htmltext>
<tokenext>You really should make up your mind .
Are they 'hotshots ' or incompetent .
You ca n't have it both ways .</tokentext>
<sentencetext>You really should make up your mind.
Are they 'hotshots' or incompetent.
You can't have it both ways.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343918</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344074</id>
	<title>Re:Literate Programming</title>
	<author>ClosedSource</author>
	<datestamp>1260123780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"I'd go as far as saying readability is more important than correctness;"</p><p>This reminds me of the joke in the "My Fair Lady": "The French don't care what they do actually<br>
&nbsp; &nbsp; &nbsp; As long as they pronounce it properly"</p></htmltext>
<tokenext>" I 'd go as far as saying readability is more important than correctness ; " This reminds me of the joke in the " My Fair Lady " : " The French do n't care what they do actually       As long as they pronounce it properly "</tokentext>
<sentencetext>"I'd go as far as saying readability is more important than correctness;"This reminds me of the joke in the "My Fair Lady": "The French don't care what they do actually
      As long as they pronounce it properly"</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343634</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30350594</id>
	<title>Re:Literate Programming</title>
	<author>Anonymous</author>
	<datestamp>1260180420000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I'd suggest that you've minimal experience as a professional programmer.</p><p>I've worked for too many years on both business applications and large-scale operating systems, and I can tell you that any moron can write bad, complex write code that more or less does what it's supposed to - that's NOT hard (although finding out why it doesn't QUITE do what it's supposed to - because it rarely does - can be fiendishly hard). Writing code that's easy to understand and change when the business or functional needs change, though - and writing it in a way that leads the next guy into a style of change that means it's STILL easy to change after it's been tweaked 6 or 7 times - now THAT's a skill worthy of its pay.</p></htmltext>
<tokenext>I 'd suggest that you 've minimal experience as a professional programmer.I 've worked for too many years on both business applications and large-scale operating systems , and I can tell you that any moron can write bad , complex write code that more or less does what it 's supposed to - that 's NOT hard ( although finding out why it does n't QUITE do what it 's supposed to - because it rarely does - can be fiendishly hard ) .
Writing code that 's easy to understand and change when the business or functional needs change , though - and writing it in a way that leads the next guy into a style of change that means it 's STILL easy to change after it 's been tweaked 6 or 7 times - now THAT 's a skill worthy of its pay .</tokentext>
<sentencetext>I'd suggest that you've minimal experience as a professional programmer.I've worked for too many years on both business applications and large-scale operating systems, and I can tell you that any moron can write bad, complex write code that more or less does what it's supposed to - that's NOT hard (although finding out why it doesn't QUITE do what it's supposed to - because it rarely does - can be fiendishly hard).
Writing code that's easy to understand and change when the business or functional needs change, though - and writing it in a way that leads the next guy into a style of change that means it's STILL easy to change after it's been tweaked 6 or 7 times - now THAT's a skill worthy of its pay.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30349034</id>
	<title>Re:What is clear to one ...</title>
	<author>Anonymous</author>
	<datestamp>1260118740000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Dam programers and all his clever languages I cannot understand! "i++"?! WTF...<br>"Increment(i);", is much better, but wait! what about "increment i;"? Or better yet: "Increment the variable named i", but it may be best: "increment the number stored in memory under the name i", or "remember that number I just gave to you? yes, that one that was like 3 or so. That's it. Now, can you please make it 4?, thanks."<br>Much better, isn't it?</p></htmltext>
<tokenext>Dam programers and all his clever languages I can not understand !
" i + + " ? ! WTF... " Increment ( i ) ; " , is much better , but wait !
what about " increment i ; " ?
Or better yet : " Increment the variable named i " , but it may be best : " increment the number stored in memory under the name i " , or " remember that number I just gave to you ?
yes , that one that was like 3 or so .
That 's it .
Now , can you please make it 4 ? , thanks .
" Much better , is n't it ?</tokentext>
<sentencetext>Dam programers and all his clever languages I cannot understand!
"i++"?! WTF..."Increment(i);", is much better, but wait!
what about "increment i;"?
Or better yet: "Increment the variable named i", but it may be best: "increment the number stored in memory under the name i", or "remember that number I just gave to you?
yes, that one that was like 3 or so.
That's it.
Now, can you please make it 4?, thanks.
"Much better, isn't it?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343622</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343546</id>
	<title>Subs and functions</title>
	<author>A Friendly Troll</author>
	<datestamp>1260119040000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>A person whose code I regularly inherit seems to hate functions. He just writes subs with no parameters and uses global variables to pass information to and from them. It's awesome...</p></htmltext>
<tokenext>A person whose code I regularly inherit seems to hate functions .
He just writes subs with no parameters and uses global variables to pass information to and from them .
It 's awesome.. .</tokentext>
<sentencetext>A person whose code I regularly inherit seems to hate functions.
He just writes subs with no parameters and uses global variables to pass information to and from them.
It's awesome...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30348326</id>
	<title>Re:elegant != clever</title>
	<author>Anonymous</author>
	<datestamp>1260111660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I don't think my definition of elegant is the same as yours, but apparently using a dictionary to argue the point is won't be a workable solution.</p></htmltext>
<tokenext>I do n't think my definition of elegant is the same as yours , but apparently using a dictionary to argue the point is wo n't be a workable solution .</tokentext>
<sentencetext>I don't think my definition of elegant is the same as yours, but apparently using a dictionary to argue the point is won't be a workable solution.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344178</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343938</id>
	<title>Code Review is only part of the solution.</title>
	<author>TimCostantino</author>
	<datestamp>1260122640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Changing someones development practices is a kin to changing any other behavior, I.E. hard to do.
<br> <br>
I've found that code reviews offer a good barometer of where everyone is on the behavior chart but it is not enough to make a significant change to the behavior.
<br> <br>
<b>Here are few items that I find essential:</b> <br>
<b>1) Maintainability Must be a priority:</b> The architect\tech lead on the project must make this a priority.  Simple code must be reinforced at all stages of development. This means new development must wait for previous development to be refactored into simpler code.
<br> <br>
<b>2) Shared understanding:</b> The team MUST recognize the importance of this requirement.  If they don't then the constant reinforcement will seem more like nagging, nit-picking than anything else.  Have the entire team read "Clean Code" send out the Daily WTF articles.  Jokingly pass out the bad code offsets.
<br> <br>
<b>3) One on One Coaching:</b> Often complicated code is written simply because the simpler solution was not obvious.  To help overcome this, team members should help each other with refactoring efforts.  As an example:  Interfaces and factories are often seen as "To complex to be simple" by junior developers.  Consequently, it is the responsibility of the entire team to help teach why these "more complicated" solutions are actually much simpler and cleaner than the alternative.
<br> <br>
<b>4) Constant Communication:</b>  As with all creative work, whether you've accomplished the goal is very subjective.  This means the team must have constant discussion, and sometimes debates, on what is maintainable.  If you are the tech lead, be sure to show examples of your own code that is sub-par, and then discuss how it can be improved.  If you don't have samples of sub-par code, you need to start writing more code.  I can't emphasize enough that the tech lead must use their own bad code as examples, this helps create an open environment where people feel free to make mistakes and ultimately learn how to write better code.
<br> <br>
Well that's my two cents as I sit here getting ready for Football to start.  (c:</htmltext>
<tokenext>Changing someones development practices is a kin to changing any other behavior , I.E .
hard to do .
I 've found that code reviews offer a good barometer of where everyone is on the behavior chart but it is not enough to make a significant change to the behavior .
Here are few items that I find essential : 1 ) Maintainability Must be a priority : The architect \ tech lead on the project must make this a priority .
Simple code must be reinforced at all stages of development .
This means new development must wait for previous development to be refactored into simpler code .
2 ) Shared understanding : The team MUST recognize the importance of this requirement .
If they do n't then the constant reinforcement will seem more like nagging , nit-picking than anything else .
Have the entire team read " Clean Code " send out the Daily WTF articles .
Jokingly pass out the bad code offsets .
3 ) One on One Coaching : Often complicated code is written simply because the simpler solution was not obvious .
To help overcome this , team members should help each other with refactoring efforts .
As an example : Interfaces and factories are often seen as " To complex to be simple " by junior developers .
Consequently , it is the responsibility of the entire team to help teach why these " more complicated " solutions are actually much simpler and cleaner than the alternative .
4 ) Constant Communication : As with all creative work , whether you 've accomplished the goal is very subjective .
This means the team must have constant discussion , and sometimes debates , on what is maintainable .
If you are the tech lead , be sure to show examples of your own code that is sub-par , and then discuss how it can be improved .
If you do n't have samples of sub-par code , you need to start writing more code .
I ca n't emphasize enough that the tech lead must use their own bad code as examples , this helps create an open environment where people feel free to make mistakes and ultimately learn how to write better code .
Well that 's my two cents as I sit here getting ready for Football to start .
( c :</tokentext>
<sentencetext>Changing someones development practices is a kin to changing any other behavior, I.E.
hard to do.
I've found that code reviews offer a good barometer of where everyone is on the behavior chart but it is not enough to make a significant change to the behavior.
Here are few items that I find essential: 
1) Maintainability Must be a priority: The architect\tech lead on the project must make this a priority.
Simple code must be reinforced at all stages of development.
This means new development must wait for previous development to be refactored into simpler code.
2) Shared understanding: The team MUST recognize the importance of this requirement.
If they don't then the constant reinforcement will seem more like nagging, nit-picking than anything else.
Have the entire team read "Clean Code" send out the Daily WTF articles.
Jokingly pass out the bad code offsets.
3) One on One Coaching: Often complicated code is written simply because the simpler solution was not obvious.
To help overcome this, team members should help each other with refactoring efforts.
As an example:  Interfaces and factories are often seen as "To complex to be simple" by junior developers.
Consequently, it is the responsibility of the entire team to help teach why these "more complicated" solutions are actually much simpler and cleaner than the alternative.
4) Constant Communication:  As with all creative work, whether you've accomplished the goal is very subjective.
This means the team must have constant discussion, and sometimes debates, on what is maintainable.
If you are the tech lead, be sure to show examples of your own code that is sub-par, and then discuss how it can be improved.
If you don't have samples of sub-par code, you need to start writing more code.
I can't emphasize enough that the tech lead must use their own bad code as examples, this helps create an open environment where people feel free to make mistakes and ultimately learn how to write better code.
Well that's my two cents as I sit here getting ready for Football to start.
(c:</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345254</id>
	<title>Modernized Literate Progr with Outlining</title>
	<author>unixtechie</author>
	<datestamp>1260132480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My idea, in answer to your question, would be modernized Literate Programming combined with outlining.</p><p>Traditional-style lit.prog. is done in flat files, and one has to keep the structure in one's memory.</p><p>Combination of lit.prog with outlining or folding  will relieve short-term memory, eliminate switching between "housekeeping" and navigating and programming, and will scale literate programs.</p><p>Secondly, traditional lit prog erects an unsurmountable PSYCHOLOGICAL BLOCK before a programmer demanding that he produced a "polished essay" of a program.</p><p>Lit Prog must be used as PROGRAMMING FROM SPECIFICATIONS IN HUMAN language, as programming in pseudocode which becomes precise new meta-operators, and be free from the demand of nice exposition.</p><p>Rather,  if practised as a tool to help keep notes, ideas, lists, references alongside your code snippets, it becomes an accelerator, rather than a drag on your feet.</p><p>And thirdly, lit prog must be - on 90\% of uses, which are by practicing programmers rather than paper-producing academics - rid of its dependence on TeX or LaTeX.<br>The most ubiquitous markup today is HTML.</p><p>I wrote a script which implements these ideas, and called it Molly for "MO-dule for LI-terate programming":<br><a href="http://github.com/unixtechie/Literate-Molly" title="github.com" rel="nofollow">http://github.com/unixtechie/Literate-Molly</a> [github.com]</p></htmltext>
<tokenext>My idea , in answer to your question , would be modernized Literate Programming combined with outlining.Traditional-style lit.prog .
is done in flat files , and one has to keep the structure in one 's memory.Combination of lit.prog with outlining or folding will relieve short-term memory , eliminate switching between " housekeeping " and navigating and programming , and will scale literate programs.Secondly , traditional lit prog erects an unsurmountable PSYCHOLOGICAL BLOCK before a programmer demanding that he produced a " polished essay " of a program.Lit Prog must be used as PROGRAMMING FROM SPECIFICATIONS IN HUMAN language , as programming in pseudocode which becomes precise new meta-operators , and be free from the demand of nice exposition.Rather , if practised as a tool to help keep notes , ideas , lists , references alongside your code snippets , it becomes an accelerator , rather than a drag on your feet.And thirdly , lit prog must be - on 90 \ % of uses , which are by practicing programmers rather than paper-producing academics - rid of its dependence on TeX or LaTeX.The most ubiquitous markup today is HTML.I wrote a script which implements these ideas , and called it Molly for " MO-dule for LI-terate programming " : http : //github.com/unixtechie/Literate-Molly [ github.com ]</tokentext>
<sentencetext>My idea, in answer to your question, would be modernized Literate Programming combined with outlining.Traditional-style lit.prog.
is done in flat files, and one has to keep the structure in one's memory.Combination of lit.prog with outlining or folding  will relieve short-term memory, eliminate switching between "housekeeping" and navigating and programming, and will scale literate programs.Secondly, traditional lit prog erects an unsurmountable PSYCHOLOGICAL BLOCK before a programmer demanding that he produced a "polished essay" of a program.Lit Prog must be used as PROGRAMMING FROM SPECIFICATIONS IN HUMAN language, as programming in pseudocode which becomes precise new meta-operators, and be free from the demand of nice exposition.Rather,  if practised as a tool to help keep notes, ideas, lists, references alongside your code snippets, it becomes an accelerator, rather than a drag on your feet.And thirdly, lit prog must be - on 90\% of uses, which are by practicing programmers rather than paper-producing academics - rid of its dependence on TeX or LaTeX.The most ubiquitous markup today is HTML.I wrote a script which implements these ideas, and called it Molly for "MO-dule for LI-terate programming":http://github.com/unixtechie/Literate-Molly [github.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30347344</id>
	<title>The "Next Poor Slob" is quite possibly... you.</title>
	<author>Anonymous</author>
	<datestamp>1260104640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>My customer is the next poor slob who has to work on the source code</i></p><p>Likely you.<nobr> <wbr></nobr>:)</p><p>In most work situations, chances are better than not that once you create or touch something, responsibility for its maintenance is going to stick to you as long as it can.</p><p>And right now I'm looking at some hobby code I wrote a year and a half ago. I was probably less careful than I should have been when I wrote it, because I knew the only reader/user in the near future was likely to be me. But "me" over a year later is quite possibly just about as clueless about what undocumented single-letter variables are and how a dozen functions fit together as a completely new initiate might be.</p></htmltext>
<tokenext>My customer is the next poor slob who has to work on the source codeLikely you .
: ) In most work situations , chances are better than not that once you create or touch something , responsibility for its maintenance is going to stick to you as long as it can.And right now I 'm looking at some hobby code I wrote a year and a half ago .
I was probably less careful than I should have been when I wrote it , because I knew the only reader/user in the near future was likely to be me .
But " me " over a year later is quite possibly just about as clueless about what undocumented single-letter variables are and how a dozen functions fit together as a completely new initiate might be .</tokentext>
<sentencetext>My customer is the next poor slob who has to work on the source codeLikely you.
:)In most work situations, chances are better than not that once you create or touch something, responsibility for its maintenance is going to stick to you as long as it can.And right now I'm looking at some hobby code I wrote a year and a half ago.
I was probably less careful than I should have been when I wrote it, because I knew the only reader/user in the near future was likely to be me.
But "me" over a year later is quite possibly just about as clueless about what undocumented single-letter variables are and how a dozen functions fit together as a completely new initiate might be.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344252</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346218</id>
	<title>This is why we use Python</title>
	<author>Sarusa</author>
	<datestamp>1260096840000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Well - one of the reasons we use Python. I'm sure some people will consider this a troll, but it's true. Some languages encourage readability, some don't. You can write horrible, awful, unreadable Python and you can write elegant, readable, maintainable Perl (Calcium was the best I've seen in a real product), but neither is encouraged and you know what you tend to get out of your programmers.</p><p>This means our code takes a bit longer to write up front than just banging it out in Ruby, but has the advantage that when we come back to it six months later it's still obvious what's going on (even if someone else wrote it) and it's easy to maintain.</p><p>Ruby's great (and a close match for Python in niche and functionality, which is why I'm using it specifically), but our Ruby guys can't do that because they love to make things as concise as possible - it allows them to show how clever they are. Perl-style magic variables and punctuation everywhere. They sometimes rewrite functionality from scratch because it's easier than deciphering their (own!) old stuff, which at least unit tests help with. On the other side, Python's indentation generally limits how much you can cram into one line without gross misuse of lambdas, which frees you from the need to even try it.</p><p>Perhaps this is self selection - maybe boring people like me who learned to value maintenance considerations (thanks to hard experience) gravitate towards easy maintenance languages, which exacerbates the effect. But I think still think your choice of language will strongly inform how maintainable your code will be; you can mandate code policies for any language, but how often (and for how long) are those actually enforced in practice?</p></htmltext>
<tokenext>Well - one of the reasons we use Python .
I 'm sure some people will consider this a troll , but it 's true .
Some languages encourage readability , some do n't .
You can write horrible , awful , unreadable Python and you can write elegant , readable , maintainable Perl ( Calcium was the best I 've seen in a real product ) , but neither is encouraged and you know what you tend to get out of your programmers.This means our code takes a bit longer to write up front than just banging it out in Ruby , but has the advantage that when we come back to it six months later it 's still obvious what 's going on ( even if someone else wrote it ) and it 's easy to maintain.Ruby 's great ( and a close match for Python in niche and functionality , which is why I 'm using it specifically ) , but our Ruby guys ca n't do that because they love to make things as concise as possible - it allows them to show how clever they are .
Perl-style magic variables and punctuation everywhere .
They sometimes rewrite functionality from scratch because it 's easier than deciphering their ( own !
) old stuff , which at least unit tests help with .
On the other side , Python 's indentation generally limits how much you can cram into one line without gross misuse of lambdas , which frees you from the need to even try it.Perhaps this is self selection - maybe boring people like me who learned to value maintenance considerations ( thanks to hard experience ) gravitate towards easy maintenance languages , which exacerbates the effect .
But I think still think your choice of language will strongly inform how maintainable your code will be ; you can mandate code policies for any language , but how often ( and for how long ) are those actually enforced in practice ?</tokentext>
<sentencetext>Well - one of the reasons we use Python.
I'm sure some people will consider this a troll, but it's true.
Some languages encourage readability, some don't.
You can write horrible, awful, unreadable Python and you can write elegant, readable, maintainable Perl (Calcium was the best I've seen in a real product), but neither is encouraged and you know what you tend to get out of your programmers.This means our code takes a bit longer to write up front than just banging it out in Ruby, but has the advantage that when we come back to it six months later it's still obvious what's going on (even if someone else wrote it) and it's easy to maintain.Ruby's great (and a close match for Python in niche and functionality, which is why I'm using it specifically), but our Ruby guys can't do that because they love to make things as concise as possible - it allows them to show how clever they are.
Perl-style magic variables and punctuation everywhere.
They sometimes rewrite functionality from scratch because it's easier than deciphering their (own!
) old stuff, which at least unit tests help with.
On the other side, Python's indentation generally limits how much you can cram into one line without gross misuse of lambdas, which frees you from the need to even try it.Perhaps this is self selection - maybe boring people like me who learned to value maintenance considerations (thanks to hard experience) gravitate towards easy maintenance languages, which exacerbates the effect.
But I think still think your choice of language will strongly inform how maintainable your code will be; you can mandate code policies for any language, but how often (and for how long) are those actually enforced in practice?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345240</id>
	<title>he is a joke</title>
	<author>Anonymous</author>
	<datestamp>1260132420000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>He makes some good points about naming symbols, but: the guy does not recognize a for loop scanning a linked list (and even think it is a "clever" trick) and does not know that he can automatically indent his code under vim.<br>He is a total joke. He should look for an other job.</p></htmltext>
<tokenext>He makes some good points about naming symbols , but : the guy does not recognize a for loop scanning a linked list ( and even think it is a " clever " trick ) and does not know that he can automatically indent his code under vim.He is a total joke .
He should look for an other job .</tokentext>
<sentencetext>He makes some good points about naming symbols, but: the guy does not recognize a for loop scanning a linked list (and even think it is a "clever" trick) and does not know that he can automatically indent his code under vim.He is a total joke.
He should look for an other job.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343816</id>
	<title>I may have to give up</title>
	<author>some-old-geek</author>
	<datestamp>1260121500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>First, I suggest a perusal of Capers Jones' book <i>Software Assessments, Benchmarks, and Best Practices</i>, from which we learn that most of the cost of internally developed systems (the sort TFA is talking about) is in maintenance.  So there should be no argument that making the code maintainable is of some high priority.</p><p>[f/x: get off my lawn] Sadly, there are many programmers who don't understand that maintenance is not the act of rewriting the system in a language they would like on their resume.  That might be <i>adaptive</i> maintenance, but the lion's share of maintenance actually involves fixing that which is broken (this would be <i>corrective, perfective,</i> and <i>preventive</i> maintenance).</p><p>Sadly (again) we already know the answer to the OP's question.  You need an enforcement mechanism.  The cheap and easy way to implement that is via code reviews.  <strong>And we know that isn't going to happen.</strong></p><p>Why?  Because too many people who get to make decisions don't want to believe that first item from Jones' book.  Making an innovative change to a UI is sexy, makes it obvious that some work has been done.  Bullet-proofing user input edits is mundane, and smacks of cubicality.</p><p>You are unlikely to get a commitment from management to let you do things "the right way."  If you did, you would have no way of knowing that it won't be rescinded when the boss' kid gets a job programming in the cubicle next to you.</p><p>The only way I know of to make this work is peer pressure.  And that is unreliable.  Thus maintenance will always have at least some aspect of the "fix what the clever kid did" to it.</p></htmltext>
<tokenext>First , I suggest a perusal of Capers Jones ' book Software Assessments , Benchmarks , and Best Practices , from which we learn that most of the cost of internally developed systems ( the sort TFA is talking about ) is in maintenance .
So there should be no argument that making the code maintainable is of some high priority .
[ f/x : get off my lawn ] Sadly , there are many programmers who do n't understand that maintenance is not the act of rewriting the system in a language they would like on their resume .
That might be adaptive maintenance , but the lion 's share of maintenance actually involves fixing that which is broken ( this would be corrective , perfective , and preventive maintenance ) .Sadly ( again ) we already know the answer to the OP 's question .
You need an enforcement mechanism .
The cheap and easy way to implement that is via code reviews .
And we know that is n't going to happen.Why ?
Because too many people who get to make decisions do n't want to believe that first item from Jones ' book .
Making an innovative change to a UI is sexy , makes it obvious that some work has been done .
Bullet-proofing user input edits is mundane , and smacks of cubicality.You are unlikely to get a commitment from management to let you do things " the right way .
" If you did , you would have no way of knowing that it wo n't be rescinded when the boss ' kid gets a job programming in the cubicle next to you.The only way I know of to make this work is peer pressure .
And that is unreliable .
Thus maintenance will always have at least some aspect of the " fix what the clever kid did " to it .</tokentext>
<sentencetext>First, I suggest a perusal of Capers Jones' book Software Assessments, Benchmarks, and Best Practices, from which we learn that most of the cost of internally developed systems (the sort TFA is talking about) is in maintenance.
So there should be no argument that making the code maintainable is of some high priority.
[f/x: get off my lawn] Sadly, there are many programmers who don't understand that maintenance is not the act of rewriting the system in a language they would like on their resume.
That might be adaptive maintenance, but the lion's share of maintenance actually involves fixing that which is broken (this would be corrective, perfective, and preventive maintenance).Sadly (again) we already know the answer to the OP's question.
You need an enforcement mechanism.
The cheap and easy way to implement that is via code reviews.
And we know that isn't going to happen.Why?
Because too many people who get to make decisions don't want to believe that first item from Jones' book.
Making an innovative change to a UI is sexy, makes it obvious that some work has been done.
Bullet-proofing user input edits is mundane, and smacks of cubicality.You are unlikely to get a commitment from management to let you do things "the right way.
"  If you did, you would have no way of knowing that it won't be rescinded when the boss' kid gets a job programming in the cubicle next to you.The only way I know of to make this work is peer pressure.
And that is unreliable.
Thus maintenance will always have at least some aspect of the "fix what the clever kid did" to it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30376224</id>
	<title>Whats clever to some is ordinary to others</title>
	<author>Anonymous</author>
	<datestamp>1259590560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>often people who complain about hard to follow code are simply poor performers.  I've had people complain about this and then go ask 4 others what the code did and they all answered after looking at the code for 60 seconds.  So obviously it was not the code....</p><p>What happens when you get one of these types and you actually listen to them.  You end up with code that spans 4 pages instead of 1 page.  Then take that same code to other people and time them on how long it takes them to understand it.  Time will double.</p><p>So really if people start complaining about tricky code, then you have to take a long hard look at them.  I personally can't think of ANY code I found to be tricky unless it was in a contest for that purpose.  I have spent much more time examining code that should have taken seconds to look at rather than the minutes it did because it was part of a overall design philosophy involving a layered approach etc.</p></htmltext>
<tokenext>often people who complain about hard to follow code are simply poor performers .
I 've had people complain about this and then go ask 4 others what the code did and they all answered after looking at the code for 60 seconds .
So obviously it was not the code....What happens when you get one of these types and you actually listen to them .
You end up with code that spans 4 pages instead of 1 page .
Then take that same code to other people and time them on how long it takes them to understand it .
Time will double.So really if people start complaining about tricky code , then you have to take a long hard look at them .
I personally ca n't think of ANY code I found to be tricky unless it was in a contest for that purpose .
I have spent much more time examining code that should have taken seconds to look at rather than the minutes it did because it was part of a overall design philosophy involving a layered approach etc .</tokentext>
<sentencetext>often people who complain about hard to follow code are simply poor performers.
I've had people complain about this and then go ask 4 others what the code did and they all answered after looking at the code for 60 seconds.
So obviously it was not the code....What happens when you get one of these types and you actually listen to them.
You end up with code that spans 4 pages instead of 1 page.
Then take that same code to other people and time them on how long it takes them to understand it.
Time will double.So really if people start complaining about tricky code, then you have to take a long hard look at them.
I personally can't think of ANY code I found to be tricky unless it was in a contest for that purpose.
I have spent much more time examining code that should have taken seconds to look at rather than the minutes it did because it was part of a overall design philosophy involving a layered approach etc.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346882</id>
	<title>Re:Literate Programming</title>
	<author>jeremyp</author>
	<datestamp>1260101340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I'm sorry, but I can't help but disagree with this sentence.</p></div><p>I think you miss the point.  Nobody is arguing that the job of the programmer is not to tell the computer what to do.  Knuth is claiming that by using the literate programming paradigm, your team (i.e. you, the other programmers and maintainers) will ultimately make a better job of telling the computer what to do.</p><p><div class="quote"><p>One must not compromise the precision of the orders it gives to the computer in order to achieve readability by something/someone else than the computer. One should, however, try to make his code as readable and elegant as he possibly can without sacrificing precision in the message to the computer.</p></div><p>But we do.  Simply by using a high level language, we sacrifice some of the precision of what we tell the computer.  By using a high level language, you expose yourself to ambiguities in the language definition and bugs in the compiler/interpreter.  You do it because the loss of precision is massively outweighed by the ease (for a human) of writing code in a high level language.</p></div>
	</htmltext>
<tokenext>I 'm sorry , but I ca n't help but disagree with this sentence.I think you miss the point .
Nobody is arguing that the job of the programmer is not to tell the computer what to do .
Knuth is claiming that by using the literate programming paradigm , your team ( i.e .
you , the other programmers and maintainers ) will ultimately make a better job of telling the computer what to do.One must not compromise the precision of the orders it gives to the computer in order to achieve readability by something/someone else than the computer .
One should , however , try to make his code as readable and elegant as he possibly can without sacrificing precision in the message to the computer.But we do .
Simply by using a high level language , we sacrifice some of the precision of what we tell the computer .
By using a high level language , you expose yourself to ambiguities in the language definition and bugs in the compiler/interpreter .
You do it because the loss of precision is massively outweighed by the ease ( for a human ) of writing code in a high level language .</tokentext>
<sentencetext>I'm sorry, but I can't help but disagree with this sentence.I think you miss the point.
Nobody is arguing that the job of the programmer is not to tell the computer what to do.
Knuth is claiming that by using the literate programming paradigm, your team (i.e.
you, the other programmers and maintainers) will ultimately make a better job of telling the computer what to do.One must not compromise the precision of the orders it gives to the computer in order to achieve readability by something/someone else than the computer.
One should, however, try to make his code as readable and elegant as he possibly can without sacrificing precision in the message to the computer.But we do.
Simply by using a high level language, we sacrifice some of the precision of what we tell the computer.
By using a high level language, you expose yourself to ambiguities in the language definition and bugs in the compiler/interpreter.
You do it because the loss of precision is massively outweighed by the ease (for a human) of writing code in a high level language.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30350644</id>
	<title>Re:Subs and functions</title>
	<author>Anonymous</author>
	<datestamp>1260180900000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>That may reflect his history. Code for a few years on one main language then switch to another, and I can guarantee that a decade later you'll still have distinctive habits from the first language. (I started writing mostly in PL/I; I now write mainly in COBOL. It took me a gob-smacking number of years to stop faking up bit flags and start using level 88 conditional variables instead.)</p></htmltext>
<tokenext>That may reflect his history .
Code for a few years on one main language then switch to another , and I can guarantee that a decade later you 'll still have distinctive habits from the first language .
( I started writing mostly in PL/I ; I now write mainly in COBOL .
It took me a gob-smacking number of years to stop faking up bit flags and start using level 88 conditional variables instead .
)</tokentext>
<sentencetext>That may reflect his history.
Code for a few years on one main language then switch to another, and I can guarantee that a decade later you'll still have distinctive habits from the first language.
(I started writing mostly in PL/I; I now write mainly in COBOL.
It took me a gob-smacking number of years to stop faking up bit flags and start using level 88 conditional variables instead.
)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343546</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346528</id>
	<title>Re:Literate Programming</title>
	<author>turing\_m</author>
	<datestamp>1260098820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>My customer is the next poor slob who has to work on the source code. Software maintenance is a fact of life. Someday, somebody is going to need to read and understand what is in your code.</p></div></blockquote><p>
And that "next poor slob" probably won't even be someone else, it will be yourself.</p></div>
	</htmltext>
<tokenext>My customer is the next poor slob who has to work on the source code .
Software maintenance is a fact of life .
Someday , somebody is going to need to read and understand what is in your code .
And that " next poor slob " probably wo n't even be someone else , it will be yourself .</tokentext>
<sentencetext>My customer is the next poor slob who has to work on the source code.
Software maintenance is a fact of life.
Someday, somebody is going to need to read and understand what is in your code.
And that "next poor slob" probably won't even be someone else, it will be yourself.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344252</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343826</id>
	<title>Re:What is clear to one ...</title>
	<author>Jeremi</author>
	<datestamp>1260121620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>When you're working on code that requires a lot of manipulation of a variable, typing a long, descriptive name 65 times is a bit of a PITA, and subject to its own bugs, when you misspell it a few times!</i></p><p>Only in a language that doesn't require you to explicitly declare variables.  In a reasonable language, any typos in your long variable name will result in compile-time errors and will therefore be caught and fixed the next time you compile the program.</p><p>In fact, the only time when a typo in a variable name should compile is if there is another variable declared with the typo name.  The chances of that happening are much smaller when you're using long variable names than short ones.</p></htmltext>
<tokenext>When you 're working on code that requires a lot of manipulation of a variable , typing a long , descriptive name 65 times is a bit of a PITA , and subject to its own bugs , when you misspell it a few times ! Only in a language that does n't require you to explicitly declare variables .
In a reasonable language , any typos in your long variable name will result in compile-time errors and will therefore be caught and fixed the next time you compile the program.In fact , the only time when a typo in a variable name should compile is if there is another variable declared with the typo name .
The chances of that happening are much smaller when you 're using long variable names than short ones .</tokentext>
<sentencetext>When you're working on code that requires a lot of manipulation of a variable, typing a long, descriptive name 65 times is a bit of a PITA, and subject to its own bugs, when you misspell it a few times!Only in a language that doesn't require you to explicitly declare variables.
In a reasonable language, any typos in your long variable name will result in compile-time errors and will therefore be caught and fixed the next time you compile the program.In fact, the only time when a typo in a variable name should compile is if there is another variable declared with the typo name.
The chances of that happening are much smaller when you're using long variable names than short ones.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343622</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344882</id>
	<title>Re:Teams</title>
	<author>Anonymous</author>
	<datestamp>1260129600000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>From your description, whats clear to me is than neither the hotshot neither the so-so are professional programmers. Professional programmers (I prefer the term developer or software engineer, because I think that writing programs is more than write code against a specification) are very hard to find.</p></htmltext>
<tokenext>From your description , whats clear to me is than neither the hotshot neither the so-so are professional programmers .
Professional programmers ( I prefer the term developer or software engineer , because I think that writing programs is more than write code against a specification ) are very hard to find .</tokentext>
<sentencetext>From your description, whats clear to me is than neither the hotshot neither the so-so are professional programmers.
Professional programmers (I prefer the term developer or software engineer, because I think that writing programs is more than write code against a specification) are very hard to find.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343918</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345202</id>
	<title>Art vs. Construction</title>
	<author>OpinionatedDude</author>
	<datestamp>1260132060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The proponents of the two sides of this "argument" seem to me to be artists and constructionists.  In software, art is what happens at a hacker conference or at a startup BEFORE the investors start poking around.  Construction (including architecture and source control and coding standards and design patterns et. al.) is what happens at a medium to large company that takes huge amounts of skilled workers to build something that can then be charged for in copious amounts and which will then make investors rich.

In short, hacking vs. coding.  Both have a place in the world.  Neither should be influenced by the other.  The big problem with software is that the former usually morphs into the later rather than being a completely separate effort which should include none of the original source material and none of the original players.

And finally, a good hacker is NEVER a good coder, and a bad coder is often NOT a gifted hacker, but someone who shouldn't be doing either type of work.</htmltext>
<tokenext>The proponents of the two sides of this " argument " seem to me to be artists and constructionists .
In software , art is what happens at a hacker conference or at a startup BEFORE the investors start poking around .
Construction ( including architecture and source control and coding standards and design patterns et .
al. ) is what happens at a medium to large company that takes huge amounts of skilled workers to build something that can then be charged for in copious amounts and which will then make investors rich .
In short , hacking vs. coding. Both have a place in the world .
Neither should be influenced by the other .
The big problem with software is that the former usually morphs into the later rather than being a completely separate effort which should include none of the original source material and none of the original players .
And finally , a good hacker is NEVER a good coder , and a bad coder is often NOT a gifted hacker , but someone who should n't be doing either type of work .</tokentext>
<sentencetext>The proponents of the two sides of this "argument" seem to me to be artists and constructionists.
In software, art is what happens at a hacker conference or at a startup BEFORE the investors start poking around.
Construction (including architecture and source control and coding standards and design patterns et.
al.) is what happens at a medium to large company that takes huge amounts of skilled workers to build something that can then be charged for in copious amounts and which will then make investors rich.
In short, hacking vs. coding.  Both have a place in the world.
Neither should be influenced by the other.
The big problem with software is that the former usually morphs into the later rather than being a completely separate effort which should include none of the original source material and none of the original players.
And finally, a good hacker is NEVER a good coder, and a bad coder is often NOT a gifted hacker, but someone who shouldn't be doing either type of work.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30347824</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>Anonymous</author>
	<datestamp>1260107760000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>What happens, then, when a single structure needs to be contained in multiple lists?</p><p>You might try to dismiss that as not a good idea, but I'm thinking in particular about some structures in the Linux kernel where this is the case...</p></htmltext>
<tokenext>What happens , then , when a single structure needs to be contained in multiple lists ? You might try to dismiss that as not a good idea , but I 'm thinking in particular about some structures in the Linux kernel where this is the case.. .</tokentext>
<sentencetext>What happens, then, when a single structure needs to be contained in multiple lists?You might try to dismiss that as not a good idea, but I'm thinking in particular about some structures in the Linux kernel where this is the case...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344830</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30347534</id>
	<title>Re:In my experience...</title>
	<author>InfiniteLoopCounter</author>
	<datestamp>1260106020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>A real problem with long variable names and strict formatting (spacing, line width, etc.) can come about when moderately difficult mathematical formulas have to be coded (and lots of them sometimes). I wouldn't want to read variable names longer than x,y,z, v (or maybe vel), etc. and function names longer than sin, cos, etc. in an actual formula. Nor would I want a single line of code split over 10 lines or for that line to be completely unaligned mathematically.</p><p>Sorry if I am falling into the same trap as many others here, as well as the the author of the article, and generalizing too much.</p></htmltext>
<tokenext>A real problem with long variable names and strict formatting ( spacing , line width , etc .
) can come about when moderately difficult mathematical formulas have to be coded ( and lots of them sometimes ) .
I would n't want to read variable names longer than x,y,z , v ( or maybe vel ) , etc .
and function names longer than sin , cos , etc .
in an actual formula .
Nor would I want a single line of code split over 10 lines or for that line to be completely unaligned mathematically.Sorry if I am falling into the same trap as many others here , as well as the the author of the article , and generalizing too much .</tokentext>
<sentencetext>A real problem with long variable names and strict formatting (spacing, line width, etc.
) can come about when moderately difficult mathematical formulas have to be coded (and lots of them sometimes).
I wouldn't want to read variable names longer than x,y,z, v (or maybe vel), etc.
and function names longer than sin, cos, etc.
in an actual formula.
Nor would I want a single line of code split over 10 lines or for that line to be completely unaligned mathematically.Sorry if I am falling into the same trap as many others here, as well as the the author of the article, and generalizing too much.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345464</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30347110</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>Anonymous</author>
	<datestamp>1260102960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Better yet.</p><p>for(p = s-&gt;next; p != 0; p = p-&gt;next)</p><p>Sure it's more verbose, but it's also more readable especially to a novice, since it's closer to the usual prototype of a for loop. (i =0; i  xxx; i++)</p></htmltext>
<tokenext>Better yet.for ( p = s- &gt; next ; p ! = 0 ; p = p- &gt; next ) Sure it 's more verbose , but it 's also more readable especially to a novice , since it 's closer to the usual prototype of a for loop .
( i = 0 ; i xxx ; i + + )</tokentext>
<sentencetext>Better yet.for(p = s-&gt;next; p != 0; p = p-&gt;next)Sure it's more verbose, but it's also more readable especially to a novice, since it's closer to the usual prototype of a for loop.
(i =0; i  xxx; i++)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344830</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345796</id>
	<title>So why do we use HLLs?</title>
	<author>Capt.Albatross</author>
	<datestamp>1260093540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>A computer uses machine code, so why should we use higher-level languages? The reason is so they can be better understood by humans -- firstly and most importantly, by the author herself. Correct code can be written more quickly, and errors more readily detected, when using languages that approximate to natural (human) language, and Knuth is simply proposing that we go further in that direction.</htmltext>
<tokenext>A computer uses machine code , so why should we use higher-level languages ?
The reason is so they can be better understood by humans -- firstly and most importantly , by the author herself .
Correct code can be written more quickly , and errors more readily detected , when using languages that approximate to natural ( human ) language , and Knuth is simply proposing that we go further in that direction .</tokentext>
<sentencetext>A computer uses machine code, so why should we use higher-level languages?
The reason is so they can be better understood by humans -- firstly and most importantly, by the author herself.
Correct code can be written more quickly, and errors more readily detected, when using languages that approximate to natural (human) language, and Knuth is simply proposing that we go further in that direction.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344338</id>
	<title>Re:Literate Programming</title>
	<author>Anonymous</author>
	<datestamp>1260125940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Have you ever read a mathematics paper?  Typically, there will be big blocks of text (with symbols interspersed), and then formulae or equations in floating blocks.  The idea is that you explain and define your terms in the blocks of text, and define your functions and relationships in the "blocks" of "math".  (Mathematical papers are a bit more involved than this.  You can have mathematical "blocks" in your text, as long as any sentence that contains a symbol is a proposition, and the symbol isn't a free variable, in context.  Literate programming systems don't typically do this kind of "inline" definition")</p><p>As it happens, every programming language is a constructive proof system, and vice-versa.  Every computer program <i>is</i> a constructive mathematical proof.  If you structure your program in a "literate" way, this connection becomes much more apparent.  You will automatically have to structure your code as if it was an argument.  This makes it significantly easier to validate the code.  (It is also helpful to have some higher order constructs, like easy to use functors)</p><p>You can <i>truly</i> have mathematical rigor in your code.  You just have to approach your code writing as proof writing.  Typically, this isn't worth the effort for most problems.  I only do it for the "tricky" algebraic (algorithmic?) libraries in my code.  Not for my data or control libraries.  Where the algorithms are domain specific and potentially non-obvious.  My data libraries (the libraries that contain instances of my data types) don't really need any comments.  Every instance is going to be in a normal form, in virtue of my coding conventions (well, this also happens to be enforced by my current language of choice, but I always did that automatically anyway).  The control libraries are obvious enough if you use sensible names.</p><p>It's hard to tell what an OO programmer might think of all this.  The "factory" pattern is a "simple" implementation of a functor for OO.  How many classes do you have to write?  Want to see how to construct a functor in Haskell?  <tt>collection `fmap` f</tt>, where f is a function of the appropriate type.  (The backticks turn a function into an infix operator)</p><p>So what is the point of all this?  Well, the algebraic libraries are where all the effort <i>should</i> go.  Precisely because they are the tricky ones.  But it is better to keep all of that complexity together, than strewn throughout a codebase.  Another point is that this architecture and methodology enforces normal forms for every value.  In particular, this means that even enormous refactoring can be done mechanically.  You should expect that any change to a data type will change the "shape" of its values.  This is inescapable, even in OO.  But you can't easily write regular expressions to parse an OO language and apply trivial syntactical transformations.  You can do that in a language where every value can look almost like a CSV list.</p></htmltext>
<tokenext>Have you ever read a mathematics paper ?
Typically , there will be big blocks of text ( with symbols interspersed ) , and then formulae or equations in floating blocks .
The idea is that you explain and define your terms in the blocks of text , and define your functions and relationships in the " blocks " of " math " .
( Mathematical papers are a bit more involved than this .
You can have mathematical " blocks " in your text , as long as any sentence that contains a symbol is a proposition , and the symbol is n't a free variable , in context .
Literate programming systems do n't typically do this kind of " inline " definition " ) As it happens , every programming language is a constructive proof system , and vice-versa .
Every computer program is a constructive mathematical proof .
If you structure your program in a " literate " way , this connection becomes much more apparent .
You will automatically have to structure your code as if it was an argument .
This makes it significantly easier to validate the code .
( It is also helpful to have some higher order constructs , like easy to use functors ) You can truly have mathematical rigor in your code .
You just have to approach your code writing as proof writing .
Typically , this is n't worth the effort for most problems .
I only do it for the " tricky " algebraic ( algorithmic ?
) libraries in my code .
Not for my data or control libraries .
Where the algorithms are domain specific and potentially non-obvious .
My data libraries ( the libraries that contain instances of my data types ) do n't really need any comments .
Every instance is going to be in a normal form , in virtue of my coding conventions ( well , this also happens to be enforced by my current language of choice , but I always did that automatically anyway ) .
The control libraries are obvious enough if you use sensible names.It 's hard to tell what an OO programmer might think of all this .
The " factory " pattern is a " simple " implementation of a functor for OO .
How many classes do you have to write ?
Want to see how to construct a functor in Haskell ?
collection ` fmap ` f , where f is a function of the appropriate type .
( The backticks turn a function into an infix operator ) So what is the point of all this ?
Well , the algebraic libraries are where all the effort should go .
Precisely because they are the tricky ones .
But it is better to keep all of that complexity together , than strewn throughout a codebase .
Another point is that this architecture and methodology enforces normal forms for every value .
In particular , this means that even enormous refactoring can be done mechanically .
You should expect that any change to a data type will change the " shape " of its values .
This is inescapable , even in OO .
But you ca n't easily write regular expressions to parse an OO language and apply trivial syntactical transformations .
You can do that in a language where every value can look almost like a CSV list .</tokentext>
<sentencetext>Have you ever read a mathematics paper?
Typically, there will be big blocks of text (with symbols interspersed), and then formulae or equations in floating blocks.
The idea is that you explain and define your terms in the blocks of text, and define your functions and relationships in the "blocks" of "math".
(Mathematical papers are a bit more involved than this.
You can have mathematical "blocks" in your text, as long as any sentence that contains a symbol is a proposition, and the symbol isn't a free variable, in context.
Literate programming systems don't typically do this kind of "inline" definition")As it happens, every programming language is a constructive proof system, and vice-versa.
Every computer program is a constructive mathematical proof.
If you structure your program in a "literate" way, this connection becomes much more apparent.
You will automatically have to structure your code as if it was an argument.
This makes it significantly easier to validate the code.
(It is also helpful to have some higher order constructs, like easy to use functors)You can truly have mathematical rigor in your code.
You just have to approach your code writing as proof writing.
Typically, this isn't worth the effort for most problems.
I only do it for the "tricky" algebraic (algorithmic?
) libraries in my code.
Not for my data or control libraries.
Where the algorithms are domain specific and potentially non-obvious.
My data libraries (the libraries that contain instances of my data types) don't really need any comments.
Every instance is going to be in a normal form, in virtue of my coding conventions (well, this also happens to be enforced by my current language of choice, but I always did that automatically anyway).
The control libraries are obvious enough if you use sensible names.It's hard to tell what an OO programmer might think of all this.
The "factory" pattern is a "simple" implementation of a functor for OO.
How many classes do you have to write?
Want to see how to construct a functor in Haskell?
collection `fmap` f, where f is a function of the appropriate type.
(The backticks turn a function into an infix operator)So what is the point of all this?
Well, the algebraic libraries are where all the effort should go.
Precisely because they are the tricky ones.
But it is better to keep all of that complexity together, than strewn throughout a codebase.
Another point is that this architecture and methodology enforces normal forms for every value.
In particular, this means that even enormous refactoring can be done mechanically.
You should expect that any change to a data type will change the "shape" of its values.
This is inescapable, even in OO.
But you can't easily write regular expressions to parse an OO language and apply trivial syntactical transformations.
You can do that in a language where every value can look almost like a CSV list.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30348698</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>Jaime2</author>
	<datestamp>1260115200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Actually, I think the reason he thought it was hard to read was the loop termination condition.  "ss" is vague and it is not trivial to arrive at the conclusion that this loop runs until ss is a null reference (for a non-C programmer).  Had the loop termination been written as "ss == NULL", then it would have been easy to read.  In my experience, C programmers tend to value terseness over readability.  The ultimate example of this paradigm is Perl, which we all know can be a nightmare to maintain.<br>
<br>
In my opinion, if that for loop were only a few lines long, the naming would be acceptable.  If the loop were 100 lines long, I'd ask for a more descriptive variable name.  I use "for(i=0; i&lt;something; i++)" all the time, if it is a very small loop and the usage is obvious.<br>
<br>
As for... <p><div class="quote"><p>The culture he's been inculcated in is one in which you never have to understand how a linked list is actually implemented, because you just use a library for it.</p></div><p>... I prefer to think that in OOP systems, we hide the implementation of the loop not to pretect our fragile brains, but to not bind the code that uses the list to a specific list implementation.  I like being able to switch between ArrayList, HashTable, SortedList, List&lt;Stuff&gt;, and Dictionary without breaking my iteration code.</p></div>
	</htmltext>
<tokenext>Actually , I think the reason he thought it was hard to read was the loop termination condition .
" ss " is vague and it is not trivial to arrive at the conclusion that this loop runs until ss is a null reference ( for a non-C programmer ) .
Had the loop termination been written as " ss = = NULL " , then it would have been easy to read .
In my experience , C programmers tend to value terseness over readability .
The ultimate example of this paradigm is Perl , which we all know can be a nightmare to maintain .
In my opinion , if that for loop were only a few lines long , the naming would be acceptable .
If the loop were 100 lines long , I 'd ask for a more descriptive variable name .
I use " for ( i = 0 ; i As for... The culture he 's been inculcated in is one in which you never have to understand how a linked list is actually implemented , because you just use a library for it.... I prefer to think that in OOP systems , we hide the implementation of the loop not to pretect our fragile brains , but to not bind the code that uses the list to a specific list implementation .
I like being able to switch between ArrayList , HashTable , SortedList , List , and Dictionary without breaking my iteration code .</tokentext>
<sentencetext>Actually, I think the reason he thought it was hard to read was the loop termination condition.
"ss" is vague and it is not trivial to arrive at the conclusion that this loop runs until ss is a null reference (for a non-C programmer).
Had the loop termination been written as "ss == NULL", then it would have been easy to read.
In my experience, C programmers tend to value terseness over readability.
The ultimate example of this paradigm is Perl, which we all know can be a nightmare to maintain.
In my opinion, if that for loop were only a few lines long, the naming would be acceptable.
If the loop were 100 lines long, I'd ask for a more descriptive variable name.
I use "for(i=0; i

As for... The culture he's been inculcated in is one in which you never have to understand how a linked list is actually implemented, because you just use a library for it.... I prefer to think that in OOP systems, we hide the implementation of the loop not to pretect our fragile brains, but to not bind the code that uses the list to a specific list implementation.
I like being able to switch between ArrayList, HashTable, SortedList, List, and Dictionary without breaking my iteration code.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345296</id>
	<title>It's just discipline</title>
	<author>thethibs</author>
	<datestamp>1260132660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You've answered your own question: <i>an elegant one-liner coupled with a comment from a few revisions ago makes for a good headache</i>.</p><p>Clever code and maintainable code are not antagonistic. Clever code that's well commented is as maintainable as the more pedestrian type. There are two problems. </p><p>The first is that the second version is often an awful hack by a programmer, not the one who wrote the original code, who doesn't fully understand what the code is doing. There is no law, not even a best practice, that says all code, even well-commented code, must be comprehensible to someone with a two-digit IQ.</p><p>The second problem is getting said programmer to comment what he did. I suspect in many cases he doesn't know, except that the immediate symptoms have gone away. I call this a goat's blood and chicken feathers patch. Unintended consequences will be someone else's problem.</p><p>Maintainability is only one of many important quality attributes. I've written more 'clever' bits of code than I care to count, usually because the alternative would result in failing some other measure--response time, size, reliability, you name it. In every one of those cases the comments provided a technical manual for the subject code. </p><p>There's one case I won't forget where 14 lines of assembler was supported with 40 lines of comment, not including the comments on each line. I was invoking little-used and poorly documented features of the cpu chip and using them in an interesting way, and an explanation was appropriate.  This code still runs fine on a modern PC. (If anyone is interested in a really fast x86 triple precision integer division that handles the signs of the quotient and remainder according to the Forth standard, I've got one.)</p><p>Clever code isn't the problem; poor documentation by poor programmers is the problem.</p></htmltext>
<tokenext>You 've answered your own question : an elegant one-liner coupled with a comment from a few revisions ago makes for a good headache.Clever code and maintainable code are not antagonistic .
Clever code that 's well commented is as maintainable as the more pedestrian type .
There are two problems .
The first is that the second version is often an awful hack by a programmer , not the one who wrote the original code , who does n't fully understand what the code is doing .
There is no law , not even a best practice , that says all code , even well-commented code , must be comprehensible to someone with a two-digit IQ.The second problem is getting said programmer to comment what he did .
I suspect in many cases he does n't know , except that the immediate symptoms have gone away .
I call this a goat 's blood and chicken feathers patch .
Unintended consequences will be someone else 's problem.Maintainability is only one of many important quality attributes .
I 've written more 'clever ' bits of code than I care to count , usually because the alternative would result in failing some other measure--response time , size , reliability , you name it .
In every one of those cases the comments provided a technical manual for the subject code .
There 's one case I wo n't forget where 14 lines of assembler was supported with 40 lines of comment , not including the comments on each line .
I was invoking little-used and poorly documented features of the cpu chip and using them in an interesting way , and an explanation was appropriate .
This code still runs fine on a modern PC .
( If anyone is interested in a really fast x86 triple precision integer division that handles the signs of the quotient and remainder according to the Forth standard , I 've got one .
) Clever code is n't the problem ; poor documentation by poor programmers is the problem .</tokentext>
<sentencetext>You've answered your own question: an elegant one-liner coupled with a comment from a few revisions ago makes for a good headache.Clever code and maintainable code are not antagonistic.
Clever code that's well commented is as maintainable as the more pedestrian type.
There are two problems.
The first is that the second version is often an awful hack by a programmer, not the one who wrote the original code, who doesn't fully understand what the code is doing.
There is no law, not even a best practice, that says all code, even well-commented code, must be comprehensible to someone with a two-digit IQ.The second problem is getting said programmer to comment what he did.
I suspect in many cases he doesn't know, except that the immediate symptoms have gone away.
I call this a goat's blood and chicken feathers patch.
Unintended consequences will be someone else's problem.Maintainability is only one of many important quality attributes.
I've written more 'clever' bits of code than I care to count, usually because the alternative would result in failing some other measure--response time, size, reliability, you name it.
In every one of those cases the comments provided a technical manual for the subject code.
There's one case I won't forget where 14 lines of assembler was supported with 40 lines of comment, not including the comments on each line.
I was invoking little-used and poorly documented features of the cpu chip and using them in an interesting way, and an explanation was appropriate.
This code still runs fine on a modern PC.
(If anyone is interested in a really fast x86 triple precision integer division that handles the signs of the quotient and remainder according to the Forth standard, I've got one.
)Clever code isn't the problem; poor documentation by poor programmers is the problem.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345398</id>
	<title>Did somebody mention FOSS?</title>
	<author>Zero\_\_Kelvin</author>
	<datestamp>1260090120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>"To my mind, the MAIN criteria for arriving at a maintainable codebase is OWNERSHIP, OPENNESS, and COLLABORATION."</p></div></blockquote><p>I agree with you. Open Source <b> <i>is</i></b>  a better paradigm<nobr> <wbr></nobr>;-)</p></div>
	</htmltext>
<tokenext>" To my mind , the MAIN criteria for arriving at a maintainable codebase is OWNERSHIP , OPENNESS , and COLLABORATION .
" I agree with you .
Open Source is a better paradigm ; - )</tokentext>
<sentencetext>"To my mind, the MAIN criteria for arriving at a maintainable codebase is OWNERSHIP, OPENNESS, and COLLABORATION.
"I agree with you.
Open Source  is  a better paradigm ;-)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343918</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343742</id>
	<title>I've ignored this non-problem for years</title>
	<author>OrangeTide</author>
	<datestamp>1260121020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>At the last few places I've worked we found that just ignoring this problem long enough lets it just go away. People who have style and coding practices that are bad, end up changing them eventually or leaving. And people with good practices tend to have success with their software, even if the styles end up being different from one another.</p><p>If you can't wait for the problem to sort itself out, then try hiring a bunch of good people that have worked together before.</p></htmltext>
<tokenext>At the last few places I 've worked we found that just ignoring this problem long enough lets it just go away .
People who have style and coding practices that are bad , end up changing them eventually or leaving .
And people with good practices tend to have success with their software , even if the styles end up being different from one another.If you ca n't wait for the problem to sort itself out , then try hiring a bunch of good people that have worked together before .</tokentext>
<sentencetext>At the last few places I've worked we found that just ignoring this problem long enough lets it just go away.
People who have style and coding practices that are bad, end up changing them eventually or leaving.
And people with good practices tend to have success with their software, even if the styles end up being different from one another.If you can't wait for the problem to sort itself out, then try hiring a bunch of good people that have worked together before.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343952</id>
	<title>Perl Critic</title>
	<author>Herkum01</author>
	<datestamp>1260122700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Perl has probably got one of the best coding analytic suites in Perl::Critic.  It addresses numerous areas dealing with Best Practices and addresses certain types of bugs. It is also highly configurable and easy to write your own rules as well.</p><p>The hardest part was actually getting people to use it.  The fact is, there are a lot of people who have a ego and rather inflexible about changing their habits.  The other side of the business will not care unless it can be shown it is a common practice or directly impacts money.  So it is a tough battle to fight and most people are just not willing to get involved with it.</p></htmltext>
<tokenext>Perl has probably got one of the best coding analytic suites in Perl : : Critic .
It addresses numerous areas dealing with Best Practices and addresses certain types of bugs .
It is also highly configurable and easy to write your own rules as well.The hardest part was actually getting people to use it .
The fact is , there are a lot of people who have a ego and rather inflexible about changing their habits .
The other side of the business will not care unless it can be shown it is a common practice or directly impacts money .
So it is a tough battle to fight and most people are just not willing to get involved with it .</tokentext>
<sentencetext>Perl has probably got one of the best coding analytic suites in Perl::Critic.
It addresses numerous areas dealing with Best Practices and addresses certain types of bugs.
It is also highly configurable and easy to write your own rules as well.The hardest part was actually getting people to use it.
The fact is, there are a lot of people who have a ego and rather inflexible about changing their habits.
The other side of the business will not care unless it can be shown it is a common practice or directly impacts money.
So it is a tough battle to fight and most people are just not willing to get involved with it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344142</id>
	<title>I've never had an enjoyable experience with this..</title>
	<author>Anonymous</author>
	<datestamp>1260124320000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>One company I worked at, when we sat down to discuss basic coding standards at the start of the project one of the developers whined and whined and wouldn't give up on one very stupid point. He was in his 60s and he claimed that he had used 2 spaces instead of 4 his whole life because it fit better on dot matrix printer paper. We pointed out that 2 spaces looks less readable and 4 looked fine on todays printers and fonts. He wouldn't give up and it was prolonging the start of the project indefinitely to the point where management said fine just use 2 then. So, we were all stuck using 2 spaces, which led to a giant war during development. We were all using Eclipse, so anytime he would write a piece of code with 2 spaces, the rest of us would would click Format document and cause all his 2 spaces to turn to 4 automatically and then re-commit. Which would make him cry, while the rest of us laughed. Essentially, majority won, but thank god for auto-format otherwise we wouldn't have been able to stay sane at that job.</p><p>Therefore, it is my opinion, that coding standards are crap. And, the only coding standard you need is to abide by whatever auto-formatting that Eclipse or your preferred IDE provides. As far as working out concepts like modularity and that sort of thing, simply refer to refactoring rules in design patterns and you'll do great. Enough said, now get coding and stop wasting time discussing nonsense.</p></htmltext>
<tokenext>One company I worked at , when we sat down to discuss basic coding standards at the start of the project one of the developers whined and whined and would n't give up on one very stupid point .
He was in his 60s and he claimed that he had used 2 spaces instead of 4 his whole life because it fit better on dot matrix printer paper .
We pointed out that 2 spaces looks less readable and 4 looked fine on todays printers and fonts .
He would n't give up and it was prolonging the start of the project indefinitely to the point where management said fine just use 2 then .
So , we were all stuck using 2 spaces , which led to a giant war during development .
We were all using Eclipse , so anytime he would write a piece of code with 2 spaces , the rest of us would would click Format document and cause all his 2 spaces to turn to 4 automatically and then re-commit .
Which would make him cry , while the rest of us laughed .
Essentially , majority won , but thank god for auto-format otherwise we would n't have been able to stay sane at that job.Therefore , it is my opinion , that coding standards are crap .
And , the only coding standard you need is to abide by whatever auto-formatting that Eclipse or your preferred IDE provides .
As far as working out concepts like modularity and that sort of thing , simply refer to refactoring rules in design patterns and you 'll do great .
Enough said , now get coding and stop wasting time discussing nonsense .</tokentext>
<sentencetext>One company I worked at, when we sat down to discuss basic coding standards at the start of the project one of the developers whined and whined and wouldn't give up on one very stupid point.
He was in his 60s and he claimed that he had used 2 spaces instead of 4 his whole life because it fit better on dot matrix printer paper.
We pointed out that 2 spaces looks less readable and 4 looked fine on todays printers and fonts.
He wouldn't give up and it was prolonging the start of the project indefinitely to the point where management said fine just use 2 then.
So, we were all stuck using 2 spaces, which led to a giant war during development.
We were all using Eclipse, so anytime he would write a piece of code with 2 spaces, the rest of us would would click Format document and cause all his 2 spaces to turn to 4 automatically and then re-commit.
Which would make him cry, while the rest of us laughed.
Essentially, majority won, but thank god for auto-format otherwise we wouldn't have been able to stay sane at that job.Therefore, it is my opinion, that coding standards are crap.
And, the only coding standard you need is to abide by whatever auto-formatting that Eclipse or your preferred IDE provides.
As far as working out concepts like modularity and that sort of thing, simply refer to refactoring rules in design patterns and you'll do great.
Enough said, now get coding and stop wasting time discussing nonsense.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344310</id>
	<title>Re:Lowest Common Denominator</title>
	<author>corbettw</author>
	<datestamp>1260125700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Don't worry, CmdrTaco. I may not hire you, but I'll keep visiting your site.</p></htmltext>
<tokenext>Do n't worry , CmdrTaco .
I may not hire you , but I 'll keep visiting your site .</tokentext>
<sentencetext>Don't worry, CmdrTaco.
I may not hire you, but I'll keep visiting your site.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343666</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343766</id>
	<title>Rule of thumb</title>
	<author>Anonymous</author>
	<datestamp>1260121140000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."</p></htmltext>
<tokenext>" Debugging is twice as hard as writing the code in the first place .
Therefore , if you write the code as cleverly as possible , you are , by definition , not smart enough to debug it .
"</tokentext>
<sentencetext>"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
"</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345222</id>
	<title>Re:What is clear to one ...</title>
	<author>Anonymous</author>
	<datestamp>1260132240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You can resolve this pretty easily with a code cross reference.</p></htmltext>
<tokenext>You can resolve this pretty easily with a code cross reference .</tokentext>
<sentencetext>You can resolve this pretty easily with a code cross reference.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343622</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345052</id>
	<title>b4 u were born, sonny...</title>
	<author>airdrummer</author>
	<datestamp>1260130860000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>i worked on fortranIV code that had been migrated from fortranII that had been migrated from whatever language was used on an ibm drum-memory machine;-) there were variables named for drum memory locations, 4col...i wasn't about to change those;-)</p><p>and those codes were written by the resident gas properties genius, who was still on the job;-) it was then i realized that the clarity of code is inversely proportional to the brilliance of the coder;-)</p></htmltext>
<tokenext>i worked on fortranIV code that had been migrated from fortranII that had been migrated from whatever language was used on an ibm drum-memory machine ; - ) there were variables named for drum memory locations , 4col...i was n't about to change those ; - ) and those codes were written by the resident gas properties genius , who was still on the job ; - ) it was then i realized that the clarity of code is inversely proportional to the brilliance of the coder ; - )</tokentext>
<sentencetext>i worked on fortranIV code that had been migrated from fortranII that had been migrated from whatever language was used on an ibm drum-memory machine;-) there were variables named for drum memory locations, 4col...i wasn't about to change those;-)and those codes were written by the resident gas properties genius, who was still on the job;-) it was then i realized that the clarity of code is inversely proportional to the brilliance of the coder;-)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343918</id>
	<title>Teams</title>
	<author>jlowery</author>
	<datestamp>1260122520000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>I've worked with teams a large percentage of (supposedly) hotshot programmers, and on teams with a similar percentage of mediocre talent. In my experience, it is the team with the so-so developers that deliver the more maintainable code. Why? I think it's because they know their limitations and are not afraid to "talk out the process" of writing code. They ask for feedback and opinion.</p><p>What that leads to is a collaborative development process, where everyone has some idea of what the other is doing. And in these environments, for some reason, people take ownership and responsibility for their code, end-to-end.</p><p>Contrast that with the hotshot teams: they know too much to ask for help, resent questioning of their implementation, mess around in other peoples domain "because they know better", and engage in heated arguments over trivial or religious matters.  And in the final analysis, the lack of cooperation leads to disfunctional interfaces between components, idiosyncratic code, and incomplete functionality or low-quality performance.</p><p>Whereas the so-so teams learn to collaborate to get things done, the hotshot teams rely on heroics: they take on too much, show exaggerated progress by declaring their code complete even though it fails edge cases, and then spend outrageous overtime fixing 'bugs' (or worse, they're too important to work on bugs, they do features, so the lesser mortals on the team get to clean up after them). Because bug fixing doesn't get scheduled up front, the schedule slides and more work hours are demanded to catch up (with decreasing effect).</p><p>To my mind, the MAIN criteria for arriving at a maintainable codebase is OWNERSHIP, OPENNESS, and COLLABORATION. A collaborative team can do more in 40 hours than a heroic team can do in 60. They just don't look so impressive.</p></htmltext>
<tokenext>I 've worked with teams a large percentage of ( supposedly ) hotshot programmers , and on teams with a similar percentage of mediocre talent .
In my experience , it is the team with the so-so developers that deliver the more maintainable code .
Why ? I think it 's because they know their limitations and are not afraid to " talk out the process " of writing code .
They ask for feedback and opinion.What that leads to is a collaborative development process , where everyone has some idea of what the other is doing .
And in these environments , for some reason , people take ownership and responsibility for their code , end-to-end.Contrast that with the hotshot teams : they know too much to ask for help , resent questioning of their implementation , mess around in other peoples domain " because they know better " , and engage in heated arguments over trivial or religious matters .
And in the final analysis , the lack of cooperation leads to disfunctional interfaces between components , idiosyncratic code , and incomplete functionality or low-quality performance.Whereas the so-so teams learn to collaborate to get things done , the hotshot teams rely on heroics : they take on too much , show exaggerated progress by declaring their code complete even though it fails edge cases , and then spend outrageous overtime fixing 'bugs ' ( or worse , they 're too important to work on bugs , they do features , so the lesser mortals on the team get to clean up after them ) .
Because bug fixing does n't get scheduled up front , the schedule slides and more work hours are demanded to catch up ( with decreasing effect ) .To my mind , the MAIN criteria for arriving at a maintainable codebase is OWNERSHIP , OPENNESS , and COLLABORATION .
A collaborative team can do more in 40 hours than a heroic team can do in 60 .
They just do n't look so impressive .</tokentext>
<sentencetext>I've worked with teams a large percentage of (supposedly) hotshot programmers, and on teams with a similar percentage of mediocre talent.
In my experience, it is the team with the so-so developers that deliver the more maintainable code.
Why? I think it's because they know their limitations and are not afraid to "talk out the process" of writing code.
They ask for feedback and opinion.What that leads to is a collaborative development process, where everyone has some idea of what the other is doing.
And in these environments, for some reason, people take ownership and responsibility for their code, end-to-end.Contrast that with the hotshot teams: they know too much to ask for help, resent questioning of their implementation, mess around in other peoples domain "because they know better", and engage in heated arguments over trivial or religious matters.
And in the final analysis, the lack of cooperation leads to disfunctional interfaces between components, idiosyncratic code, and incomplete functionality or low-quality performance.Whereas the so-so teams learn to collaborate to get things done, the hotshot teams rely on heroics: they take on too much, show exaggerated progress by declaring their code complete even though it fails edge cases, and then spend outrageous overtime fixing 'bugs' (or worse, they're too important to work on bugs, they do features, so the lesser mortals on the team get to clean up after them).
Because bug fixing doesn't get scheduled up front, the schedule slides and more work hours are demanded to catch up (with decreasing effect).To my mind, the MAIN criteria for arriving at a maintainable codebase is OWNERSHIP, OPENNESS, and COLLABORATION.
A collaborative team can do more in 40 hours than a heroic team can do in 60.
They just don't look so impressive.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344840</id>
	<title>Re:What is clear to one ...</title>
	<author>James Youngman</author>
	<datestamp>1260129360000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>Goodness, how did that person get hired as a programmer if they weren't already fully familiar with arrays?   I wouldn't hire anybody as a programmer unless they were able to select an appropriate data structure for a problem, and explain why they selected that particular one.    (Well, at my current employer, the bar is much higher than that, but I'm speaking in general).</p></htmltext>
<tokenext>Goodness , how did that person get hired as a programmer if they were n't already fully familiar with arrays ?
I would n't hire anybody as a programmer unless they were able to select an appropriate data structure for a problem , and explain why they selected that particular one .
( Well , at my current employer , the bar is much higher than that , but I 'm speaking in general ) .</tokentext>
<sentencetext>Goodness, how did that person get hired as a programmer if they weren't already fully familiar with arrays?
I wouldn't hire anybody as a programmer unless they were able to select an appropriate data structure for a problem, and explain why they selected that particular one.
(Well, at my current employer, the bar is much higher than that, but I'm speaking in general).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343622</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30373862</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>toddestan</author>
	<datestamp>1260290340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>"Most of the variables in CRAP are one or two letters long. Originally, this was due to the memory constraints involved when programmers first designed and built the system." This is not particularly plausible. C is a compiled language, so using long variable names has no effect on the amount of memory used at run-time. It would also have been more or less a non-issue in terms of RAM used at compile-time. C only dates back to 1972, and didn't start to get popular until ca. 1980. By that time, using long variable names would have had a pretty negligible effect on RAM used by the compiler in proportion to total available RAM. And in any case, if compiles are taking too long, you just break up your files into smaller parts.</p></div></blockquote><p>You also need to take into account the space the<nobr> <wbr></nobr>.c file is going to take before it's compiled too.  I just took a look at a smallish program I made, consisting of about 3800 lines of source.  It's 108k, which is not a trivial amount of ram on a computer from the early-mid 1980's.</p></div>
	</htmltext>
<tokenext>" Most of the variables in CRAP are one or two letters long .
Originally , this was due to the memory constraints involved when programmers first designed and built the system .
" This is not particularly plausible .
C is a compiled language , so using long variable names has no effect on the amount of memory used at run-time .
It would also have been more or less a non-issue in terms of RAM used at compile-time .
C only dates back to 1972 , and did n't start to get popular until ca .
1980. By that time , using long variable names would have had a pretty negligible effect on RAM used by the compiler in proportion to total available RAM .
And in any case , if compiles are taking too long , you just break up your files into smaller parts.You also need to take into account the space the .c file is going to take before it 's compiled too .
I just took a look at a smallish program I made , consisting of about 3800 lines of source .
It 's 108k , which is not a trivial amount of ram on a computer from the early-mid 1980 's .</tokentext>
<sentencetext>"Most of the variables in CRAP are one or two letters long.
Originally, this was due to the memory constraints involved when programmers first designed and built the system.
" This is not particularly plausible.
C is a compiled language, so using long variable names has no effect on the amount of memory used at run-time.
It would also have been more or less a non-issue in terms of RAM used at compile-time.
C only dates back to 1972, and didn't start to get popular until ca.
1980. By that time, using long variable names would have had a pretty negligible effect on RAM used by the compiler in proportion to total available RAM.
And in any case, if compiles are taking too long, you just break up your files into smaller parts.You also need to take into account the space the .c file is going to take before it's compiled too.
I just took a look at a smallish program I made, consisting of about 3800 lines of source.
It's 108k, which is not a trivial amount of ram on a computer from the early-mid 1980's.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345924</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>Anonymous</author>
	<datestamp>1260094740000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>it's interesting that like many things, those least qualified<br>to evaluate code, have the strongest opinions.</p></htmltext>
<tokenext>it 's interesting that like many things , those least qualifiedto evaluate code , have the strongest opinions .</tokentext>
<sentencetext>it's interesting that like many things, those least qualifiedto evaluate code, have the strongest opinions.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344014</id>
	<title>I wrote my own platform</title>
	<author>holophrastic</author>
	<datestamp>1260123360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>...for web development.  And the primary goal of this platorm is to make doing typical things very straightforward, and easy-to-do-right and hard-to-do-differently.  Commenting teh code itself is completely useless because the code reads fluidly.  So comments are limited to what isn't programmed, or what has been removed for good reason.</p><p>Some advantages are quite clear when it comes to security things like user permissions and sql injection avoidance.  The platform makes it horribly difficult to do those kinds of things in the traditional way, and really easy to do it in the consistent way.</p><p>So the rule really is that if it's difficult to write, and it looks like carp when you're done, then there is a proper way to do it.</p><p>It's what a friend of mine has been saying for years.  It's not enough to make good code look good.  You've got to make bad code look bad.</p></htmltext>
<tokenext>...for web development .
And the primary goal of this platorm is to make doing typical things very straightforward , and easy-to-do-right and hard-to-do-differently .
Commenting teh code itself is completely useless because the code reads fluidly .
So comments are limited to what is n't programmed , or what has been removed for good reason.Some advantages are quite clear when it comes to security things like user permissions and sql injection avoidance .
The platform makes it horribly difficult to do those kinds of things in the traditional way , and really easy to do it in the consistent way.So the rule really is that if it 's difficult to write , and it looks like carp when you 're done , then there is a proper way to do it.It 's what a friend of mine has been saying for years .
It 's not enough to make good code look good .
You 've got to make bad code look bad .</tokentext>
<sentencetext>...for web development.
And the primary goal of this platorm is to make doing typical things very straightforward, and easy-to-do-right and hard-to-do-differently.
Commenting teh code itself is completely useless because the code reads fluidly.
So comments are limited to what isn't programmed, or what has been removed for good reason.Some advantages are quite clear when it comes to security things like user permissions and sql injection avoidance.
The platform makes it horribly difficult to do those kinds of things in the traditional way, and really easy to do it in the consistent way.So the rule really is that if it's difficult to write, and it looks like carp when you're done, then there is a proper way to do it.It's what a friend of mine has been saying for years.
It's not enough to make good code look good.
You've got to make bad code look bad.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344252</id>
	<title>Re:Literate Programming</title>
	<author>Anonymous</author>
	<datestamp>1260125280000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>Many years ago, a very smart man explained to me that my customer is not the compiler.  My customer is the next poor slob who has to work on the source code.  Software maintenance is a fact of life.  Someday, somebody is going to need to read and understand what is in your code.</p><p>Ignore maintainability at your peril.  If people on my team ignore maintainability, they become unemployed.</p><p>Do you even know who Donald Knuth is?  I'll take his advice over yours, any day.</p></htmltext>
<tokenext>Many years ago , a very smart man explained to me that my customer is not the compiler .
My customer is the next poor slob who has to work on the source code .
Software maintenance is a fact of life .
Someday , somebody is going to need to read and understand what is in your code.Ignore maintainability at your peril .
If people on my team ignore maintainability , they become unemployed.Do you even know who Donald Knuth is ?
I 'll take his advice over yours , any day .</tokentext>
<sentencetext>Many years ago, a very smart man explained to me that my customer is not the compiler.
My customer is the next poor slob who has to work on the source code.
Software maintenance is a fact of life.
Someday, somebody is going to need to read and understand what is in your code.Ignore maintainability at your peril.
If people on my team ignore maintainability, they become unemployed.Do you even know who Donald Knuth is?
I'll take his advice over yours, any day.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343638</id>
	<title>Baffled, what ancient age are you from?</title>
	<author>mauddib~</author>
	<datestamp>1260120060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'm baffled. Here we use extensive extra documentation, mostly outside of the code. Programming changes are related to changes in design documents and deployment documents. Also most of the design follows UML diagrams which are thoroughly kept together with all programming code. As far as we use programming code, every change is reviewed by another developer. Without these, we would quickly lose our minds, heads and bodies to the massive complexity.</p><p>I always thought NASA was one of the top quality software engineers, but apparently not in every department.</p></htmltext>
<tokenext>I 'm baffled .
Here we use extensive extra documentation , mostly outside of the code .
Programming changes are related to changes in design documents and deployment documents .
Also most of the design follows UML diagrams which are thoroughly kept together with all programming code .
As far as we use programming code , every change is reviewed by another developer .
Without these , we would quickly lose our minds , heads and bodies to the massive complexity.I always thought NASA was one of the top quality software engineers , but apparently not in every department .</tokentext>
<sentencetext>I'm baffled.
Here we use extensive extra documentation, mostly outside of the code.
Programming changes are related to changes in design documents and deployment documents.
Also most of the design follows UML diagrams which are thoroughly kept together with all programming code.
As far as we use programming code, every change is reviewed by another developer.
Without these, we would quickly lose our minds, heads and bodies to the massive complexity.I always thought NASA was one of the top quality software engineers, but apparently not in every department.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343542</id>
	<title>"elegant code" overhead coefficient</title>
	<author>GrimNotepad</author>
	<datestamp>1260118920000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>In my company i am the sole/lead/only developer, and as such i have my own defined best practices and i follow them adamantly, that said i have written clever couplets of code that "just work" they are commented from here to the nines yet 4-6 months and 3 projects later when it comes time to look at reviewing for a possible update in the project i can sometimes look at it and have to spend extra time to follow the elegant code around to get it "loaded" back into my head to see what i did.

i think that so long as programs are written by humans who can sometimes look at it sometimes as an art form there should always be an "elegant code" overhead coefficient worked into every project update.</htmltext>
<tokenext>In my company i am the sole/lead/only developer , and as such i have my own defined best practices and i follow them adamantly , that said i have written clever couplets of code that " just work " they are commented from here to the nines yet 4-6 months and 3 projects later when it comes time to look at reviewing for a possible update in the project i can sometimes look at it and have to spend extra time to follow the elegant code around to get it " loaded " back into my head to see what i did .
i think that so long as programs are written by humans who can sometimes look at it sometimes as an art form there should always be an " elegant code " overhead coefficient worked into every project update .</tokentext>
<sentencetext>In my company i am the sole/lead/only developer, and as such i have my own defined best practices and i follow them adamantly, that said i have written clever couplets of code that "just work" they are commented from here to the nines yet 4-6 months and 3 projects later when it comes time to look at reviewing for a possible update in the project i can sometimes look at it and have to spend extra time to follow the elegant code around to get it "loaded" back into my head to see what i did.
i think that so long as programs are written by humans who can sometimes look at it sometimes as an art form there should always be an "elegant code" overhead coefficient worked into every project update.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30350544</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>Anonymous</author>
	<datestamp>1260179760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><i>And this is relevant to 99.9\% of the software out there how?</i></p><p>Well, it's pretty much relevant to 100\% of kernels in current use - and probably 100\% of internal workings on consumer devices. Narrow range of work? hardly.<br>Get back to your blinkered Windows world and your<nobr> <wbr></nobr>.NET apps.</p></htmltext>
<tokenext>And this is relevant to 99.9 \ % of the software out there how ? Well , it 's pretty much relevant to 100 \ % of kernels in current use - and probably 100 \ % of internal workings on consumer devices .
Narrow range of work ?
hardly.Get back to your blinkered Windows world and your .NET apps .</tokentext>
<sentencetext>And this is relevant to 99.9\% of the software out there how?Well, it's pretty much relevant to 100\% of kernels in current use - and probably 100\% of internal workings on consumer devices.
Narrow range of work?
hardly.Get back to your blinkered Windows world and your .NET apps.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345322</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343734</id>
	<title>Re:What is clear to one ...</title>
	<author>Anonymous</author>
	<datestamp>1260120960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Exactly - verbosity (I mean not in variable names, which should be descriptive, but in how the code is written) makes things easier for novice programmers, but has a serious maintainability cost.  I've worked on highly complex pieces of software, and constantly struggle with this: when a change in behaviour is needed, I can accomplish it with a few lines changed in 5 minutes, but several others spend a week re-writing large amounts of their code because the required thing is not well encapsulated.</p><p>There's an inverse relationship between the level of abstraction and expressive power.  I believe in high levels of abstraction coupled with well commented code and long-ish descriptive names.  Others favour high levels of abstraction with terse names, which is very hard for anyone else to make sense of.  Yet others favour low levels of abstraction because they do not understand the higher level ones.  The problem with that approach is that there can be many orders of magnitude difference in what such "low abstraction" programmers can accomplish.  I'll take a shop of 5 programmers highly proficient in powerful techniques, over one of 75 "low abstraction level" programmers.</p><p>Excessive code verbosity also has an obscurity all its own.  When I see 60 lines of code doing what could be done in 1 or 2 lines, it's very hard for me to read such code, because not very much functionality fits on my screen at once.  I can't see the high level picture because the low level details are taking up so much space.</p></htmltext>
<tokenext>Exactly - verbosity ( I mean not in variable names , which should be descriptive , but in how the code is written ) makes things easier for novice programmers , but has a serious maintainability cost .
I 've worked on highly complex pieces of software , and constantly struggle with this : when a change in behaviour is needed , I can accomplish it with a few lines changed in 5 minutes , but several others spend a week re-writing large amounts of their code because the required thing is not well encapsulated.There 's an inverse relationship between the level of abstraction and expressive power .
I believe in high levels of abstraction coupled with well commented code and long-ish descriptive names .
Others favour high levels of abstraction with terse names , which is very hard for anyone else to make sense of .
Yet others favour low levels of abstraction because they do not understand the higher level ones .
The problem with that approach is that there can be many orders of magnitude difference in what such " low abstraction " programmers can accomplish .
I 'll take a shop of 5 programmers highly proficient in powerful techniques , over one of 75 " low abstraction level " programmers.Excessive code verbosity also has an obscurity all its own .
When I see 60 lines of code doing what could be done in 1 or 2 lines , it 's very hard for me to read such code , because not very much functionality fits on my screen at once .
I ca n't see the high level picture because the low level details are taking up so much space .</tokentext>
<sentencetext>Exactly - verbosity (I mean not in variable names, which should be descriptive, but in how the code is written) makes things easier for novice programmers, but has a serious maintainability cost.
I've worked on highly complex pieces of software, and constantly struggle with this: when a change in behaviour is needed, I can accomplish it with a few lines changed in 5 minutes, but several others spend a week re-writing large amounts of their code because the required thing is not well encapsulated.There's an inverse relationship between the level of abstraction and expressive power.
I believe in high levels of abstraction coupled with well commented code and long-ish descriptive names.
Others favour high levels of abstraction with terse names, which is very hard for anyone else to make sense of.
Yet others favour low levels of abstraction because they do not understand the higher level ones.
The problem with that approach is that there can be many orders of magnitude difference in what such "low abstraction" programmers can accomplish.
I'll take a shop of 5 programmers highly proficient in powerful techniques, over one of 75 "low abstraction level" programmers.Excessive code verbosity also has an obscurity all its own.
When I see 60 lines of code doing what could be done in 1 or 2 lines, it's very hard for me to read such code, because not very much functionality fits on my screen at once.
I can't see the high level picture because the low level details are taking up so much space.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343622</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345318</id>
	<title>Re:Literate Programming</title>
	<author>szetlan</author>
	<datestamp>1260132840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p><div class="quote"><p><div class="quote"><p>Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.</p></div><p>I'm sorry, but I can't help but disagree with this sentence. The purpose of creating a program really is to instruct the computer what to do. Not to explain other human beings what we want the computer to do.
Computers don't do what we want, they do what we tell them to do. Success in programming a computer comes from telling it what we want it to do.</p></div><p>Note quite right.  The purpose of creating a computer program is to get work done. This includes, but is not limited to, telling the computer what to do.  We want to maximize the amount of work done by the computer and minimize the work done by people.  This implies striking the right balance between optimizing the run-time of the program and optimizing BOTH the readability AND usability of the program.  When modifying a program, we have to balance effectiveness, readability, and usability.

Comparing the potential benefit of a faster-running program with the cost of poor readability or usability is difficult, but (at least in business) can be done by converting all units to dollars.  Dollars are then easily convertible to pizza and beer, units of measurement familiar to nearly every programmer in the world.

In some cases, cryptic one-liners that shave a few milliseconds off the per-cycle run-time produce many millions of pizzas and thousands of gallons of beer annually, at the expense of a few pies and a six-pack in maintenance per year.  Who cares if that code is hard to read?  We have PIZZA and BEER!  But saving a slice and a half-pint at the expense of an office pizza party<nobr> <wbr></nobr>.... that's just a travesty.

And don't get me started on all that pre-packaged stuff that costs nothing to install, runs really fast, and is super-maintainable -- but that costs the end-user all of Papa John's and most of Sam Adams just to make a few photocopies.  Feh.</p></div></div>
	</htmltext>
<tokenext>Let us change our traditional attitude to the construction of programs : Instead of imagining that our main task is to instruct a computer what to do , let us concentrate rather on explaining to human beings what we want a computer to do.I 'm sorry , but I ca n't help but disagree with this sentence .
The purpose of creating a program really is to instruct the computer what to do .
Not to explain other human beings what we want the computer to do .
Computers do n't do what we want , they do what we tell them to do .
Success in programming a computer comes from telling it what we want it to do.Note quite right .
The purpose of creating a computer program is to get work done .
This includes , but is not limited to , telling the computer what to do .
We want to maximize the amount of work done by the computer and minimize the work done by people .
This implies striking the right balance between optimizing the run-time of the program and optimizing BOTH the readability AND usability of the program .
When modifying a program , we have to balance effectiveness , readability , and usability .
Comparing the potential benefit of a faster-running program with the cost of poor readability or usability is difficult , but ( at least in business ) can be done by converting all units to dollars .
Dollars are then easily convertible to pizza and beer , units of measurement familiar to nearly every programmer in the world .
In some cases , cryptic one-liners that shave a few milliseconds off the per-cycle run-time produce many millions of pizzas and thousands of gallons of beer annually , at the expense of a few pies and a six-pack in maintenance per year .
Who cares if that code is hard to read ?
We have PIZZA and BEER !
But saving a slice and a half-pint at the expense of an office pizza party .... that 's just a travesty .
And do n't get me started on all that pre-packaged stuff that costs nothing to install , runs really fast , and is super-maintainable -- but that costs the end-user all of Papa John 's and most of Sam Adams just to make a few photocopies .
Feh .</tokentext>
<sentencetext>Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.I'm sorry, but I can't help but disagree with this sentence.
The purpose of creating a program really is to instruct the computer what to do.
Not to explain other human beings what we want the computer to do.
Computers don't do what we want, they do what we tell them to do.
Success in programming a computer comes from telling it what we want it to do.Note quite right.
The purpose of creating a computer program is to get work done.
This includes, but is not limited to, telling the computer what to do.
We want to maximize the amount of work done by the computer and minimize the work done by people.
This implies striking the right balance between optimizing the run-time of the program and optimizing BOTH the readability AND usability of the program.
When modifying a program, we have to balance effectiveness, readability, and usability.
Comparing the potential benefit of a faster-running program with the cost of poor readability or usability is difficult, but (at least in business) can be done by converting all units to dollars.
Dollars are then easily convertible to pizza and beer, units of measurement familiar to nearly every programmer in the world.
In some cases, cryptic one-liners that shave a few milliseconds off the per-cycle run-time produce many millions of pizzas and thousands of gallons of beer annually, at the expense of a few pies and a six-pack in maintenance per year.
Who cares if that code is hard to read?
We have PIZZA and BEER!
But saving a slice and a half-pint at the expense of an office pizza party .... that's just a travesty.
And don't get me started on all that pre-packaged stuff that costs nothing to install, runs really fast, and is super-maintainable -- but that costs the end-user all of Papa John's and most of Sam Adams just to make a few photocopies.
Feh.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343812</id>
	<title>what?</title>
	<author>Anonymous</author>
	<datestamp>1260121500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>why do we call this 'clever'?<br>clever as opposed to what, stupid?<br>maybe 'obscure' would have been a better word...<br>imho, the Linux Kernel Coding Style is the best.</p></htmltext>
<tokenext>why do we call this 'clever ' ? clever as opposed to what , stupid ? maybe 'obscure ' would have been a better word...imho , the Linux Kernel Coding Style is the best .</tokentext>
<sentencetext>why do we call this 'clever'?clever as opposed to what, stupid?maybe 'obscure' would have been a better word...imho, the Linux Kernel Coding Style is the best.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30347350</id>
	<title>Re:Literate Programming</title>
	<author>blaizer</author>
	<datestamp>1260104700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>There are actually 10 kinds of people:
  * Those who know the binary numeral system, and
  * those who don't.</htmltext>
<tokenext>There are actually 10 kinds of people : * Those who know the binary numeral system , and * those who do n't .</tokentext>
<sentencetext>There are actually 10 kinds of people:
  * Those who know the binary numeral system, and
  * those who don't.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344252</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30350170</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>Anonymous</author>
	<datestamp>1260218400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You're not correct.  The C standard guarantees that:</p><p>(((ss != NULL) &amp;&amp; (ss)) || ((ss == NULL) &amp;&amp; (!ss)))</p><p>By virtue of the fact that:</p><p>1.  A NULL pointer must compare equal to 0<br>2.  "Boolean" statements are in fact integer statements where nonzero is true and 0 is false<br>3.  Non-null pointers are not be equal to null pointers</p><p>As for C++, it has true booleans but ints still coerce to bool in the same manner, and therefore by extension pointer types still do.</p><p>If that doesn't work, your compiler is VERY broken.  Even if the internal representation of NULL is not bit-pattern 0x00000000 (or however long it is on the target architecture).</p></htmltext>
<tokenext>You 're not correct .
The C standard guarantees that : ( ( ( ss ! = NULL ) &amp;&amp; ( ss ) ) | | ( ( ss = = NULL ) &amp;&amp; ( ! ss ) ) ) By virtue of the fact that : 1 .
A NULL pointer must compare equal to 02 .
" Boolean " statements are in fact integer statements where nonzero is true and 0 is false3 .
Non-null pointers are not be equal to null pointersAs for C + + , it has true booleans but ints still coerce to bool in the same manner , and therefore by extension pointer types still do.If that does n't work , your compiler is VERY broken .
Even if the internal representation of NULL is not bit-pattern 0x00000000 ( or however long it is on the target architecture ) .</tokentext>
<sentencetext>You're not correct.
The C standard guarantees that:(((ss != NULL) &amp;&amp; (ss)) || ((ss == NULL) &amp;&amp; (!ss)))By virtue of the fact that:1.
A NULL pointer must compare equal to 02.
"Boolean" statements are in fact integer statements where nonzero is true and 0 is false3.
Non-null pointers are not be equal to null pointersAs for C++, it has true booleans but ints still coerce to bool in the same manner, and therefore by extension pointer types still do.If that doesn't work, your compiler is VERY broken.
Even if the internal representation of NULL is not bit-pattern 0x00000000 (or however long it is on the target architecture).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344966</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30347612</id>
	<title>Clever Bad? Bollocks</title>
	<author>Anonymous</author>
	<datestamp>1260106560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Any idiot saying clever doesn't pay the bills or clever is too difficult to maintain is simply admitting he's stupid. Grow some brains or get the fuck out of the industry. We do not want you, we never wanted you, and you are an infection.</p></htmltext>
<tokenext>Any idiot saying clever does n't pay the bills or clever is too difficult to maintain is simply admitting he 's stupid .
Grow some brains or get the fuck out of the industry .
We do not want you , we never wanted you , and you are an infection .</tokentext>
<sentencetext>Any idiot saying clever doesn't pay the bills or clever is too difficult to maintain is simply admitting he's stupid.
Grow some brains or get the fuck out of the industry.
We do not want you, we never wanted you, and you are an infection.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344496</id>
	<title>It all starts with Documentation</title>
	<author>CAOgdin</author>
	<datestamp>1260126900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I've proven to my clients, time-after-time, for more than half a century, that programming is done BACKWARDS from good practice:  We write code (maybe with comments), then we go back and document it. <br> <br>

Instead of some vague specification, we need to <b> <i>start</i> </b> with DOCUMENTATION.  We need to write the first draft of the user manual (or, in modular programming, the programmer's reference) BEFORE a line of code is written.  That document must be reviewed and amended until all (or a good representative sample of) the "consumers" of that software are satisfied with how it will work.  (For example, Windows is NEVER reviewed by real end users in simulation or documentation, so we get the persistent and buggy output of Redmond's programmers.)  AFTER we know what we're trying to achieve, we can write requisite code to achieve those results.<br> <br>
Yes, I know that's heresy...but it's the ENGINEERING way to do the job.</htmltext>
<tokenext>I 've proven to my clients , time-after-time , for more than half a century , that programming is done BACKWARDS from good practice : We write code ( maybe with comments ) , then we go back and document it .
Instead of some vague specification , we need to start with DOCUMENTATION .
We need to write the first draft of the user manual ( or , in modular programming , the programmer 's reference ) BEFORE a line of code is written .
That document must be reviewed and amended until all ( or a good representative sample of ) the " consumers " of that software are satisfied with how it will work .
( For example , Windows is NEVER reviewed by real end users in simulation or documentation , so we get the persistent and buggy output of Redmond 's programmers .
) AFTER we know what we 're trying to achieve , we can write requisite code to achieve those results .
Yes , I know that 's heresy...but it 's the ENGINEERING way to do the job .</tokentext>
<sentencetext>I've proven to my clients, time-after-time, for more than half a century, that programming is done BACKWARDS from good practice:  We write code (maybe with comments), then we go back and document it.
Instead of some vague specification, we need to  start  with DOCUMENTATION.
We need to write the first draft of the user manual (or, in modular programming, the programmer's reference) BEFORE a line of code is written.
That document must be reviewed and amended until all (or a good representative sample of) the "consumers" of that software are satisfied with how it will work.
(For example, Windows is NEVER reviewed by real end users in simulation or documentation, so we get the persistent and buggy output of Redmond's programmers.
)  AFTER we know what we're trying to achieve, we can write requisite code to achieve those results.
Yes, I know that's heresy...but it's the ENGINEERING way to do the job.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30350664</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>Anonymous</author>
	<datestamp>1260181140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>And replacing the cute one-liner with clearer (and just as fast, since it compiles down to the same instructions) code:</p><p>p = s-&gt;next;<br>while(p != NULL)<br>{<br>
&nbsp; &nbsp; &nbsp; &nbsp; p = p-&gt;next;<br>}</p><p>ps: forget about 'NULL != p'. Only ancient compilers cannot detect inadvertent assignment inside evaluation statements [and a coder using such a construct purposely is certainly beyond help<nobr> <wbr></nobr>:)].</p></htmltext>
<tokenext>And replacing the cute one-liner with clearer ( and just as fast , since it compiles down to the same instructions ) code : p = s- &gt; next ; while ( p ! = NULL ) {         p = p- &gt; next ; } ps : forget about 'NULL ! = p' .
Only ancient compilers can not detect inadvertent assignment inside evaluation statements [ and a coder using such a construct purposely is certainly beyond help : ) ] .</tokentext>
<sentencetext>And replacing the cute one-liner with clearer (and just as fast, since it compiles down to the same instructions) code:p = s-&gt;next;while(p != NULL){
        p = p-&gt;next;}ps: forget about 'NULL != p'.
Only ancient compilers cannot detect inadvertent assignment inside evaluation statements [and a coder using such a construct purposely is certainly beyond help :)].</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344830</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344754</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>Anonymous</author>
	<datestamp>1260128820000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p><i>C is a compiled language, so using long variable names has no effect on the amount of memory used at run-time</i></p><p>It does if you're embedding symbolic debugging information in that same binary - and running it on a system where the entire executable is loaded into memory at start, rather than paging in sections as needed.</p></htmltext>
<tokenext>C is a compiled language , so using long variable names has no effect on the amount of memory used at run-timeIt does if you 're embedding symbolic debugging information in that same binary - and running it on a system where the entire executable is loaded into memory at start , rather than paging in sections as needed .</tokentext>
<sentencetext>C is a compiled language, so using long variable names has no effect on the amount of memory used at run-timeIt does if you're embedding symbolic debugging information in that same binary - and running it on a system where the entire executable is loaded into memory at start, rather than paging in sections as needed.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344970</id>
	<title>Try working at EA</title>
	<author>Anonymous</author>
	<datestamp>1260130260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I worked for Electronic Arts in the '90's where nothing was documented. Not the code, not the tools, not the processes. During the final month before release, there would be a daily build and some teenagers would beta-test but there no other QA, no doc's, no reviews. Oh, they did have the "Wall of Shame" as I called it where bugs were assigned to specific coders. Great moral booster.</p><p>One tool I was required to use, specified all its time units in 1/100th's of a second. Another expressed amplitudes in dB mapped onto 0...75. None of this was commented or documented anywhere. You just had to unit test everything you touched to grok it's behaviour.</p><p>Needless to say, it drove me mad, espec. because I couldn't figure out why people were so resistant to change. All the programmers would just skunk away in the cubbies for weeks at a time, and keep the code to themselves like a shameful personal secret.</p><p>In the end, I figured the secrecy and lack of doc's was due to the company's vicious turnover rate; people figured they were less likely to be fired if they were the sole knowers of something. Also, no-one really wanted to help anyone else -- it was a very dog-eat-dog environment, with office politics trumping everything else.</p><p>From EA's point of view, I think it was actually cheaper in the end to have 20-something clueless coders churning out throwaway versions than to hire savvier, more experienced programmers. The buggy version would be replaced by next year's buggy version anyway. And by creating a paranoid work  atmosphere they also managed to suck a lot of unpaid overtime out of people.</p><p>My suspicion after 20 years of professional life is EA is not exceptional. Academics and programmers tend to agree on the need to document, test and verify, but in the business world the reality is that quick-n-dirty is cheaper. I've read all the arguments that debugging is more costly than coding, etc. but it's just not borne out by practice.</p></htmltext>
<tokenext>I worked for Electronic Arts in the '90 's where nothing was documented .
Not the code , not the tools , not the processes .
During the final month before release , there would be a daily build and some teenagers would beta-test but there no other QA , no doc 's , no reviews .
Oh , they did have the " Wall of Shame " as I called it where bugs were assigned to specific coders .
Great moral booster.One tool I was required to use , specified all its time units in 1/100th 's of a second .
Another expressed amplitudes in dB mapped onto 0...75 .
None of this was commented or documented anywhere .
You just had to unit test everything you touched to grok it 's behaviour.Needless to say , it drove me mad , espec .
because I could n't figure out why people were so resistant to change .
All the programmers would just skunk away in the cubbies for weeks at a time , and keep the code to themselves like a shameful personal secret.In the end , I figured the secrecy and lack of doc 's was due to the company 's vicious turnover rate ; people figured they were less likely to be fired if they were the sole knowers of something .
Also , no-one really wanted to help anyone else -- it was a very dog-eat-dog environment , with office politics trumping everything else.From EA 's point of view , I think it was actually cheaper in the end to have 20-something clueless coders churning out throwaway versions than to hire savvier , more experienced programmers .
The buggy version would be replaced by next year 's buggy version anyway .
And by creating a paranoid work atmosphere they also managed to suck a lot of unpaid overtime out of people.My suspicion after 20 years of professional life is EA is not exceptional .
Academics and programmers tend to agree on the need to document , test and verify , but in the business world the reality is that quick-n-dirty is cheaper .
I 've read all the arguments that debugging is more costly than coding , etc .
but it 's just not borne out by practice .</tokentext>
<sentencetext>I worked for Electronic Arts in the '90's where nothing was documented.
Not the code, not the tools, not the processes.
During the final month before release, there would be a daily build and some teenagers would beta-test but there no other QA, no doc's, no reviews.
Oh, they did have the "Wall of Shame" as I called it where bugs were assigned to specific coders.
Great moral booster.One tool I was required to use, specified all its time units in 1/100th's of a second.
Another expressed amplitudes in dB mapped onto 0...75.
None of this was commented or documented anywhere.
You just had to unit test everything you touched to grok it's behaviour.Needless to say, it drove me mad, espec.
because I couldn't figure out why people were so resistant to change.
All the programmers would just skunk away in the cubbies for weeks at a time, and keep the code to themselves like a shameful personal secret.In the end, I figured the secrecy and lack of doc's was due to the company's vicious turnover rate; people figured they were less likely to be fired if they were the sole knowers of something.
Also, no-one really wanted to help anyone else -- it was a very dog-eat-dog environment, with office politics trumping everything else.From EA's point of view, I think it was actually cheaper in the end to have 20-something clueless coders churning out throwaway versions than to hire savvier, more experienced programmers.
The buggy version would be replaced by next year's buggy version anyway.
And by creating a paranoid work  atmosphere they also managed to suck a lot of unpaid overtime out of people.My suspicion after 20 years of professional life is EA is not exceptional.
Academics and programmers tend to agree on the need to document, test and verify, but in the business world the reality is that quick-n-dirty is cheaper.
I've read all the arguments that debugging is more costly than coding, etc.
but it's just not borne out by practice.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344258</id>
	<title>It's all Zen</title>
	<author>furball</author>
	<datestamp>1260125340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>1k of code is simple in general to maintain. It probably has less bugs than 2k of code. It follows then that 999 bytes of code is simpler and probably has less probably of bugs than 1k of code. If you work with the logic, you arrive at the fact that if you write no code that is the simplest and most bug free version of anything you'll ever have.</p><p>Have you ever heard of a zero-day exploit to a peace of software that hasn't been written? Didn't think so!</p><p>Software development is really the domain of Zen monks.</p></htmltext>
<tokenext>1k of code is simple in general to maintain .
It probably has less bugs than 2k of code .
It follows then that 999 bytes of code is simpler and probably has less probably of bugs than 1k of code .
If you work with the logic , you arrive at the fact that if you write no code that is the simplest and most bug free version of anything you 'll ever have.Have you ever heard of a zero-day exploit to a peace of software that has n't been written ?
Did n't think so ! Software development is really the domain of Zen monks .</tokentext>
<sentencetext>1k of code is simple in general to maintain.
It probably has less bugs than 2k of code.
It follows then that 999 bytes of code is simpler and probably has less probably of bugs than 1k of code.
If you work with the logic, you arrive at the fact that if you write no code that is the simplest and most bug free version of anything you'll ever have.Have you ever heard of a zero-day exploit to a peace of software that hasn't been written?
Didn't think so!Software development is really the domain of Zen monks.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30348624</id>
	<title>Re:Literate Programming</title>
	<author>Anonymous</author>
	<datestamp>1260114540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Of course you have to tell the computer what to do. But the computer doesn't care about high level design, or even variable names. The point is, you can write code that will cause a computer to perform certain operations in many ways, but you should strive to write the code in the way that people after you can understand.</p></htmltext>
<tokenext>Of course you have to tell the computer what to do .
But the computer does n't care about high level design , or even variable names .
The point is , you can write code that will cause a computer to perform certain operations in many ways , but you should strive to write the code in the way that people after you can understand .</tokentext>
<sentencetext>Of course you have to tell the computer what to do.
But the computer doesn't care about high level design, or even variable names.
The point is, you can write code that will cause a computer to perform certain operations in many ways, but you should strive to write the code in the way that people after you can understand.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343510</id>
	<title>Simple...</title>
	<author>Anonymous</author>
	<datestamp>1260118620000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>Simple, clever doesn't pay the bills, reliable and maintainable do.  It's a cost benefit analysis: if that clever one-liner saves many man-hours of work, then probably a good idea.  If it saves you two or three lines of code and all of an addition 45 seconds, probably not worth the blow to maintainability and readability.  It's always a tradeoff...just have to decide which is more important in any given context, and at most companies, reliability and maintainability is king compared to a slight runtime increase or 45 seconds/3 lines shaved off.</p></htmltext>
<tokenext>Simple , clever does n't pay the bills , reliable and maintainable do .
It 's a cost benefit analysis : if that clever one-liner saves many man-hours of work , then probably a good idea .
If it saves you two or three lines of code and all of an addition 45 seconds , probably not worth the blow to maintainability and readability .
It 's always a tradeoff...just have to decide which is more important in any given context , and at most companies , reliability and maintainability is king compared to a slight runtime increase or 45 seconds/3 lines shaved off .</tokentext>
<sentencetext>Simple, clever doesn't pay the bills, reliable and maintainable do.
It's a cost benefit analysis: if that clever one-liner saves many man-hours of work, then probably a good idea.
If it saves you two or three lines of code and all of an addition 45 seconds, probably not worth the blow to maintainability and readability.
It's always a tradeoff...just have to decide which is more important in any given context, and at most companies, reliability and maintainability is king compared to a slight runtime increase or 45 seconds/3 lines shaved off.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345322</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>Anonymous</author>
	<datestamp>1260132900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>And this is relevant to 99.9\% of the software out there how?</p><p>"Facts" like this are what turn into programmer urban legends that haunt us forever.  "Facts" like it is better to manually inline your code rather than let the compiler do it.  "Facts" like if you are just copying a string you should do the pointer arithmetic yourself rather then "wasting space" pulling in the standard library for strncpy.  "Facts" like with<nobr> <wbr></nobr>.NET you should always set variables to "null" to save memory.   All rumors.  All urban legends.  All passed around like they are the truth.</p><p>When you make statements like yours, make sure to add *huge* guard bars.  You comment only applies to a very, very narrow range of programs in the wild.  In fact, if you worked on such a system you'd know this applies to you automatically.</p><p>In other words, your comment is garbage--write descriptive variable names and don't fucking worry about "saving memory" or "saving disk space" unless you are an complete idiot. If you are working on a system were long variables eat into your 10k of flash memory, then we can talk--though I'd question why you are embedding such detailed debug info in your device in the first place.</p></htmltext>
<tokenext>And this is relevant to 99.9 \ % of the software out there how ?
" Facts " like this are what turn into programmer urban legends that haunt us forever .
" Facts " like it is better to manually inline your code rather than let the compiler do it .
" Facts " like if you are just copying a string you should do the pointer arithmetic yourself rather then " wasting space " pulling in the standard library for strncpy .
" Facts " like with .NET you should always set variables to " null " to save memory .
All rumors .
All urban legends .
All passed around like they are the truth.When you make statements like yours , make sure to add * huge * guard bars .
You comment only applies to a very , very narrow range of programs in the wild .
In fact , if you worked on such a system you 'd know this applies to you automatically.In other words , your comment is garbage--write descriptive variable names and do n't fucking worry about " saving memory " or " saving disk space " unless you are an complete idiot .
If you are working on a system were long variables eat into your 10k of flash memory , then we can talk--though I 'd question why you are embedding such detailed debug info in your device in the first place .</tokentext>
<sentencetext>And this is relevant to 99.9\% of the software out there how?
"Facts" like this are what turn into programmer urban legends that haunt us forever.
"Facts" like it is better to manually inline your code rather than let the compiler do it.
"Facts" like if you are just copying a string you should do the pointer arithmetic yourself rather then "wasting space" pulling in the standard library for strncpy.
"Facts" like with .NET you should always set variables to "null" to save memory.
All rumors.
All urban legends.
All passed around like they are the truth.When you make statements like yours, make sure to add *huge* guard bars.
You comment only applies to a very, very narrow range of programs in the wild.
In fact, if you worked on such a system you'd know this applies to you automatically.In other words, your comment is garbage--write descriptive variable names and don't fucking worry about "saving memory" or "saving disk space" unless you are an complete idiot.
If you are working on a system were long variables eat into your 10k of flash memory, then we can talk--though I'd question why you are embedding such detailed debug info in your device in the first place.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344754</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343916</id>
	<title>keep it simply stated</title>
	<author>God of Lemmings</author>
	<datestamp>1260122520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Our workplace is such that everything has to be easy to follow and understandable with a glance.
This is not necessarily because someone else will be working on our code so much as that we
almost certainly end up coming back to it 6-12 months later, or that the person writing it won't
be the person maintaining it or porting it.
<br> <br>
If it isn't easy to follow, you can usually fix this by spreading out the code and  inserting more
comments, and avoiding shorthand statements like inline ternary that save typing, but don't
enhance readability. Inline comments are uncommon,  instead varying kinds of flower-boxes
before a section of code. In general, it ends up that being clever requires much more commenting
in the flower box to explain functionality, so in the end it becomes a wasted effort.
<br> <br>
A few days ago I saw someone going around with this sig from Brian Kernighan;
<br>
    Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.</htmltext>
<tokenext>Our workplace is such that everything has to be easy to follow and understandable with a glance .
This is not necessarily because someone else will be working on our code so much as that we almost certainly end up coming back to it 6-12 months later , or that the person writing it wo n't be the person maintaining it or porting it .
If it is n't easy to follow , you can usually fix this by spreading out the code and inserting more comments , and avoiding shorthand statements like inline ternary that save typing , but do n't enhance readability .
Inline comments are uncommon , instead varying kinds of flower-boxes before a section of code .
In general , it ends up that being clever requires much more commenting in the flower box to explain functionality , so in the end it becomes a wasted effort .
A few days ago I saw someone going around with this sig from Brian Kernighan ; Debugging is twice as hard as writing the code in the first place .
Therefore , if you write the code as cleverly as possible , you are , by definition , not smart enough to debug it .</tokentext>
<sentencetext>Our workplace is such that everything has to be easy to follow and understandable with a glance.
This is not necessarily because someone else will be working on our code so much as that we
almost certainly end up coming back to it 6-12 months later, or that the person writing it won't
be the person maintaining it or porting it.
If it isn't easy to follow, you can usually fix this by spreading out the code and  inserting more
comments, and avoiding shorthand statements like inline ternary that save typing, but don't
enhance readability.
Inline comments are uncommon,  instead varying kinds of flower-boxes
before a section of code.
In general, it ends up that being clever requires much more commenting
in the flower box to explain functionality, so in the end it becomes a wasted effort.
A few days ago I saw someone going around with this sig from Brian Kernighan;

    Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344176</id>
	<title>Names, meanings, code documentation &amp; culture</title>
	<author>Anonymous</author>
	<datestamp>1260124560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Meaning is very problematic beast. Philosophers has know already for few centuries how difficult it is to define proper names and point how meaning is bound to words or other constructs. If I have understood some what modern day consensus of philosophers any language will always be more or less defined for small audiences. To say that in practical way tech talk is talked by techies to techies. So called general language that can be heard in news or such will not cut, it just lacks practical way of saying difficult things e.g. news for nerds are not written same way as CNN articles.</p><p>Where does that lead us? Code documentation, style and even variable names can be meaningful and sensible activity, but only within limits of programming culture. It is waste of time to teach non programmers to understand 'this particular' code. Non programmers should first learn programming culture and then they should be able to understand. I understand many of you will say that there is no such thing as homogenous programming culture. In that you are absolutely right, and wrong. For example intending code is better than not intending, but we can argue till end of time is correct intend 4 or 8 chars. Programming languages have idiomatic expressions, one should always favor them. This sort of 'rules' are part of culture. But culture is greater construct than set or rules. In order to understand variable names for example one has to take a look of hackers dictionary (foo, bar, zyxxy...). Some times there are references to geek popular culture (I've seen magical number 42 too often that it would be just a coincident).</p><p>Defining coding practices is a very difficult task. The definition should match with culture and limit possibilities provided by culture. Paradoxes are hard to crack.</p></htmltext>
<tokenext>Meaning is very problematic beast .
Philosophers has know already for few centuries how difficult it is to define proper names and point how meaning is bound to words or other constructs .
If I have understood some what modern day consensus of philosophers any language will always be more or less defined for small audiences .
To say that in practical way tech talk is talked by techies to techies .
So called general language that can be heard in news or such will not cut , it just lacks practical way of saying difficult things e.g .
news for nerds are not written same way as CNN articles.Where does that lead us ?
Code documentation , style and even variable names can be meaningful and sensible activity , but only within limits of programming culture .
It is waste of time to teach non programmers to understand 'this particular ' code .
Non programmers should first learn programming culture and then they should be able to understand .
I understand many of you will say that there is no such thing as homogenous programming culture .
In that you are absolutely right , and wrong .
For example intending code is better than not intending , but we can argue till end of time is correct intend 4 or 8 chars .
Programming languages have idiomatic expressions , one should always favor them .
This sort of 'rules ' are part of culture .
But culture is greater construct than set or rules .
In order to understand variable names for example one has to take a look of hackers dictionary ( foo , bar , zyxxy... ) .
Some times there are references to geek popular culture ( I 've seen magical number 42 too often that it would be just a coincident ) .Defining coding practices is a very difficult task .
The definition should match with culture and limit possibilities provided by culture .
Paradoxes are hard to crack .</tokentext>
<sentencetext>Meaning is very problematic beast.
Philosophers has know already for few centuries how difficult it is to define proper names and point how meaning is bound to words or other constructs.
If I have understood some what modern day consensus of philosophers any language will always be more or less defined for small audiences.
To say that in practical way tech talk is talked by techies to techies.
So called general language that can be heard in news or such will not cut, it just lacks practical way of saying difficult things e.g.
news for nerds are not written same way as CNN articles.Where does that lead us?
Code documentation, style and even variable names can be meaningful and sensible activity, but only within limits of programming culture.
It is waste of time to teach non programmers to understand 'this particular' code.
Non programmers should first learn programming culture and then they should be able to understand.
I understand many of you will say that there is no such thing as homogenous programming culture.
In that you are absolutely right, and wrong.
For example intending code is better than not intending, but we can argue till end of time is correct intend 4 or 8 chars.
Programming languages have idiomatic expressions, one should always favor them.
This sort of 'rules' are part of culture.
But culture is greater construct than set or rules.
In order to understand variable names for example one has to take a look of hackers dictionary (foo, bar, zyxxy...).
Some times there are references to geek popular culture (I've seen magical number 42 too often that it would be just a coincident).Defining coding practices is a very difficult task.
The definition should match with culture and limit possibilities provided by culture.
Paradoxes are hard to crack.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343682</id>
	<title>Re:Literate Programming</title>
	<author>Anonymous</author>
	<datestamp>1260120480000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Yes, I use a similar way of thinking.<br>I couple this way of thinking about source code (meant for humans to read even before computers) with personal face to face exchange of information, especially when handing over maintenance of a codebase to someone else.</p></htmltext>
<tokenext>Yes , I use a similar way of thinking.I couple this way of thinking about source code ( meant for humans to read even before computers ) with personal face to face exchange of information , especially when handing over maintenance of a codebase to someone else .</tokentext>
<sentencetext>Yes, I use a similar way of thinking.I couple this way of thinking about source code (meant for humans to read even before computers) with personal face to face exchange of information, especially when handing over maintenance of a codebase to someone else.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30348888</id>
	<title>Re:What is clear to one ...</title>
	<author>Blakey Rat</author>
	<datestamp>1260117000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>When you're working on code that requires a lot of manipulation of a variable, typing a long, descriptive name 65 times is a bit of a PITA, and subject to its own bugs, when you misspell it a few times!</i></p><p>Maybe you should upgrade to an IDE built sometime in this century.</p></htmltext>
<tokenext>When you 're working on code that requires a lot of manipulation of a variable , typing a long , descriptive name 65 times is a bit of a PITA , and subject to its own bugs , when you misspell it a few times ! Maybe you should upgrade to an IDE built sometime in this century .</tokentext>
<sentencetext>When you're working on code that requires a lot of manipulation of a variable, typing a long, descriptive name 65 times is a bit of a PITA, and subject to its own bugs, when you misspell it a few times!Maybe you should upgrade to an IDE built sometime in this century.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343622</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344546</id>
	<title>STL not always a good choice</title>
	<author>Anonymous</author>
	<datestamp>1260127200000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>NASA, I'm sure, writes many things that must run in real time.  Unfortunately, STL is not always a good thing to use in this scenario.  My company actually has a coding standard to never use STL in code that is run in real time.  So why is that?  Let's say you're doing a vector.clear() operation.  In the most common linux implementations, the<nobr> <wbr></nobr>.clear() function does not deallocate memory.  However, that behavior is not in the C++ STL standard.  If I recall correctly, only the interface is defined.  What's going on underneath is omitted from the standard.  So here's an issue we had in one of our real time systems.  We were running VxWorks and a certain process was taking significantly longer on VxWorks than it did in linux.  The reason why is because the<nobr> <wbr></nobr>.clear() function in VxWorks deallocates memory, which was not expected due to how it works in linux.  So now you have a bug that took several months to find because no one felt they needed to dig into the STL code for VxWorks.  And all because the coder wanted to simplify his or her writing process at the expense of knowing exactly what the code would do in all situations.</p></htmltext>
<tokenext>NASA , I 'm sure , writes many things that must run in real time .
Unfortunately , STL is not always a good thing to use in this scenario .
My company actually has a coding standard to never use STL in code that is run in real time .
So why is that ?
Let 's say you 're doing a vector.clear ( ) operation .
In the most common linux implementations , the .clear ( ) function does not deallocate memory .
However , that behavior is not in the C + + STL standard .
If I recall correctly , only the interface is defined .
What 's going on underneath is omitted from the standard .
So here 's an issue we had in one of our real time systems .
We were running VxWorks and a certain process was taking significantly longer on VxWorks than it did in linux .
The reason why is because the .clear ( ) function in VxWorks deallocates memory , which was not expected due to how it works in linux .
So now you have a bug that took several months to find because no one felt they needed to dig into the STL code for VxWorks .
And all because the coder wanted to simplify his or her writing process at the expense of knowing exactly what the code would do in all situations .</tokentext>
<sentencetext>NASA, I'm sure, writes many things that must run in real time.
Unfortunately, STL is not always a good thing to use in this scenario.
My company actually has a coding standard to never use STL in code that is run in real time.
So why is that?
Let's say you're doing a vector.clear() operation.
In the most common linux implementations, the .clear() function does not deallocate memory.
However, that behavior is not in the C++ STL standard.
If I recall correctly, only the interface is defined.
What's going on underneath is omitted from the standard.
So here's an issue we had in one of our real time systems.
We were running VxWorks and a certain process was taking significantly longer on VxWorks than it did in linux.
The reason why is because the .clear() function in VxWorks deallocates memory, which was not expected due to how it works in linux.
So now you have a bug that took several months to find because no one felt they needed to dig into the STL code for VxWorks.
And all because the coder wanted to simplify his or her writing process at the expense of knowing exactly what the code would do in all situations.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345654</id>
	<title>Canonical examples of chutzpah?</title>
	<author>turing\_m</author>
	<datestamp>1260092340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I would think that correcting Knuth on programming practice has got to be way up there.</p><p>You might also consider telling the computer to use some line breaks when you separate your paragraphs, since the aim of slashdot is ostensibly to communicate with other people.</p><blockquote><div><p> <tt>&lt;br&gt;&lt;br&gt;</tt></p></div> </blockquote><p> does the trick.</p></div>
	</htmltext>
<tokenext>I would think that correcting Knuth on programming practice has got to be way up there.You might also consider telling the computer to use some line breaks when you separate your paragraphs , since the aim of slashdot is ostensibly to communicate with other people .
does the trick .</tokentext>
<sentencetext>I would think that correcting Knuth on programming practice has got to be way up there.You might also consider telling the computer to use some line breaks when you separate your paragraphs, since the aim of slashdot is ostensibly to communicate with other people.
does the trick.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30357276</id>
	<title>essence vs ceremony</title>
	<author>ZenDragon</author>
	<datestamp>1260177780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In my opinion this matter comes down to a balance of essence and ceremony in code. Essence is that much actual provides a function (business logic), and ceremony is simply that which we constantly repeat (program logic; i.e. error catching blocks, etc). One elegant one liner may provide essence in the code but at the loss of the ceremonial code that makes that code usable and easy to follow/maintain Personally I find the a best practice to maintain separation of those two elements such that ceremony can be mapped in through a defined path, without being overly verbose. In other words, keep your business logic separate from program logic. </p><p>In good practice this will help coders avoid the need for clever one liners so long as the business logic doesn&rsquo;t interfere with the program logic. In some cases when a clever one liner may be required they are only in the business logic and shouldn&rsquo;t interfere with the program thus making it much easier to folllow without having to trace it all over the place.</p><p>An example of this may be using a lambda invocation pattern to wrap error catching around a database factory implementation such that all calls to the database happen through one interface/class implementation. This allows you to change the business logic without touching ANY of the program code. I hope that makes sense, and I hope Im not misunderstanding the question either! lol</p></htmltext>
<tokenext>In my opinion this matter comes down to a balance of essence and ceremony in code .
Essence is that much actual provides a function ( business logic ) , and ceremony is simply that which we constantly repeat ( program logic ; i.e .
error catching blocks , etc ) .
One elegant one liner may provide essence in the code but at the loss of the ceremonial code that makes that code usable and easy to follow/maintain Personally I find the a best practice to maintain separation of those two elements such that ceremony can be mapped in through a defined path , without being overly verbose .
In other words , keep your business logic separate from program logic .
In good practice this will help coders avoid the need for clever one liners so long as the business logic doesn    t interfere with the program logic .
In some cases when a clever one liner may be required they are only in the business logic and shouldn    t interfere with the program thus making it much easier to folllow without having to trace it all over the place.An example of this may be using a lambda invocation pattern to wrap error catching around a database factory implementation such that all calls to the database happen through one interface/class implementation .
This allows you to change the business logic without touching ANY of the program code .
I hope that makes sense , and I hope Im not misunderstanding the question either !
lol</tokentext>
<sentencetext>In my opinion this matter comes down to a balance of essence and ceremony in code.
Essence is that much actual provides a function (business logic), and ceremony is simply that which we constantly repeat (program logic; i.e.
error catching blocks, etc).
One elegant one liner may provide essence in the code but at the loss of the ceremonial code that makes that code usable and easy to follow/maintain Personally I find the a best practice to maintain separation of those two elements such that ceremony can be mapped in through a defined path, without being overly verbose.
In other words, keep your business logic separate from program logic.
In good practice this will help coders avoid the need for clever one liners so long as the business logic doesn’t interfere with the program logic.
In some cases when a clever one liner may be required they are only in the business logic and shouldn’t interfere with the program thus making it much easier to folllow without having to trace it all over the place.An example of this may be using a lambda invocation pattern to wrap error catching around a database factory implementation such that all calls to the database happen through one interface/class implementation.
This allows you to change the business logic without touching ANY of the program code.
I hope that makes sense, and I hope Im not misunderstanding the question either!
lol</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343900</id>
	<title>Too MUCH of this</title>
	<author>Anonymous</author>
	<datestamp>1260122340000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>There is increasingly a meme that pretty code in a strongly typed language id OK, everything else is CRAP.<br><br>Well no, neatly written code, in whatever, is good, as are good code and clear comments where they are needed, ie NOT,<br><br>i = i++;<nobr> <wbr></nobr>//increment i<br><br>Some of the worst code I have seen written is in C++, Java and C#. OO over the top, full of OO jargon, code that wanders around a thousand method calls without solving the problem, and TOO MUCH CODE, zillions of complex libraries and dependancies.<br><br>Clarity, order and simplicity are the secret of writing good code, not language, tools or methodologies, and then it can be written in anything from Lisp to C#.</htmltext>
<tokenext>There is increasingly a meme that pretty code in a strongly typed language id OK , everything else is CRAP.Well no , neatly written code , in whatever , is good , as are good code and clear comments where they are needed , ie NOT,i = i + + ; //increment iSome of the worst code I have seen written is in C + + , Java and C # .
OO over the top , full of OO jargon , code that wanders around a thousand method calls without solving the problem , and TOO MUCH CODE , zillions of complex libraries and dependancies.Clarity , order and simplicity are the secret of writing good code , not language , tools or methodologies , and then it can be written in anything from Lisp to C # .</tokentext>
<sentencetext>There is increasingly a meme that pretty code in a strongly typed language id OK, everything else is CRAP.Well no, neatly written code, in whatever, is good, as are good code and clear comments where they are needed, ie NOT,i = i++; //increment iSome of the worst code I have seen written is in C++, Java and C#.
OO over the top, full of OO jargon, code that wanders around a thousand method calls without solving the problem, and TOO MUCH CODE, zillions of complex libraries and dependancies.Clarity, order and simplicity are the secret of writing good code, not language, tools or methodologies, and then it can be written in anything from Lisp to C#.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344468</id>
	<title>Re:Teams</title>
	<author>Anonymous</author>
	<datestamp>1260126720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I used to work with someone who thought in the hotshot way you describe.  The additional caveat to him was that, when he found something he didn't like in your code, the commit comment was something along the lines of "WTF is this s**t, fix it now."  Now I work in a team in the opposite camp.  On the one hand, I'd say that his method, while very irritating and prone to error, would push one do a certain amount of work per day (i.e. - a lot of it).  The opposite is somewhat more relaxed and, while it leads to somewhat less buggy code, it also seems to lead to more lax standards in code.  It's a tough line to follow; be skilled and care enough to put out good code yet humble enough to ask for help when you need it.  Ideally, if there were trust among the team members (people forget how to do stuff sometimes; admit to it) and agreement, everything would be ideal.  Ah well.</p></htmltext>
<tokenext>I used to work with someone who thought in the hotshot way you describe .
The additional caveat to him was that , when he found something he did n't like in your code , the commit comment was something along the lines of " WTF is this s * * t , fix it now .
" Now I work in a team in the opposite camp .
On the one hand , I 'd say that his method , while very irritating and prone to error , would push one do a certain amount of work per day ( i.e .
- a lot of it ) .
The opposite is somewhat more relaxed and , while it leads to somewhat less buggy code , it also seems to lead to more lax standards in code .
It 's a tough line to follow ; be skilled and care enough to put out good code yet humble enough to ask for help when you need it .
Ideally , if there were trust among the team members ( people forget how to do stuff sometimes ; admit to it ) and agreement , everything would be ideal .
Ah well .</tokentext>
<sentencetext>I used to work with someone who thought in the hotshot way you describe.
The additional caveat to him was that, when he found something he didn't like in your code, the commit comment was something along the lines of "WTF is this s**t, fix it now.
"  Now I work in a team in the opposite camp.
On the one hand, I'd say that his method, while very irritating and prone to error, would push one do a certain amount of work per day (i.e.
- a lot of it).
The opposite is somewhat more relaxed and, while it leads to somewhat less buggy code, it also seems to lead to more lax standards in code.
It's a tough line to follow; be skilled and care enough to put out good code yet humble enough to ask for help when you need it.
Ideally, if there were trust among the team members (people forget how to do stuff sometimes; admit to it) and agreement, everything would be ideal.
Ah well.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343918</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30363410</id>
	<title>Re:Rule of thumb</title>
	<author>sergueyz</author>
	<datestamp>1260273000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><a href="http://sequence.complete.org/hwn/20081025" title="complete.org" rel="nofollow">"Debugging code is admitting defeat."</a> [complete.org]</htmltext>
<tokenext>" Debugging code is admitting defeat .
" [ complete.org ]</tokentext>
<sentencetext>"Debugging code is admitting defeat.
" [complete.org]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343766</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343726</id>
	<title>communication is key, not just documentation</title>
	<author>Anonymous</author>
	<datestamp>1260120840000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>One person's clever, obscure trick is another person's common practice.</p><p>Communicate with the other coders in your project. Write decent comments.  TALK to the other coders.  Cooperate and share ideas.</p></htmltext>
<tokenext>One person 's clever , obscure trick is another person 's common practice.Communicate with the other coders in your project .
Write decent comments .
TALK to the other coders .
Cooperate and share ideas .</tokentext>
<sentencetext>One person's clever, obscure trick is another person's common practice.Communicate with the other coders in your project.
Write decent comments.
TALK to the other coders.
Cooperate and share ideas.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344440</id>
	<title>Oblig</title>
	<author>Anonymous</author>
	<datestamp>1260126600000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><nobr> <wbr></nobr></p><div class="quote"><p>...manageable practices that ultimately offer a lot of value to the next programmer down the line who will have to maintain the code.</p></div><p>Simple: Use Python<nobr> <wbr></nobr>;)</p><p>*ducks*</p></div>
	</htmltext>
<tokenext>...manageable practices that ultimately offer a lot of value to the next programmer down the line who will have to maintain the code.Simple : Use Python ; ) * ducks *</tokentext>
<sentencetext> ...manageable practices that ultimately offer a lot of value to the next programmer down the line who will have to maintain the code.Simple: Use Python ;)*ducks*
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343804</id>
	<title>Sane source control is critical</title>
	<author>Antique Geekmeister</author>
	<datestamp>1260121440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Using good source control helps, a lot. I've gotten very fond of git and its ancestror for style though not code, BitKeeper, because they let you do work locally and submit it centrally when you're ready.</p><p>Also, if your "coding standard" isn't built into your editors and common tools, you're doing something wrong. For example, if your C++ standard is not consistent with 'indent', you're doing something wrong.</p></htmltext>
<tokenext>Using good source control helps , a lot .
I 've gotten very fond of git and its ancestror for style though not code , BitKeeper , because they let you do work locally and submit it centrally when you 're ready.Also , if your " coding standard " is n't built into your editors and common tools , you 're doing something wrong .
For example , if your C + + standard is not consistent with 'indent ' , you 're doing something wrong .</tokentext>
<sentencetext>Using good source control helps, a lot.
I've gotten very fond of git and its ancestror for style though not code, BitKeeper, because they let you do work locally and submit it centrally when you're ready.Also, if your "coding standard" isn't built into your editors and common tools, you're doing something wrong.
For example, if your C++ standard is not consistent with 'indent', you're doing something wrong.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343792</id>
	<title>All code is obscure to the incompetent.</title>
	<author>Anonymous</author>
	<datestamp>1260121380000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>0</modscore>
	<htmltext><p>for(ss = s-&gt;ss; ss; ss = ss-&gt;ss);</p><p>Pretty standard way to traverse a linked list.</p></htmltext>
<tokenext>for ( ss = s- &gt; ss ; ss ; ss = ss- &gt; ss ) ; Pretty standard way to traverse a linked list .</tokentext>
<sentencetext>for(ss = s-&gt;ss; ss; ss = ss-&gt;ss);Pretty standard way to traverse a linked list.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346472</id>
	<title>I've not seen any corporate attention to quality</title>
	<author>RonMcMahon</author>
	<datestamp>1260098460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>90\% of my work has been in the Canadian Oil and Gas industry and EVERY company that I've worked for has sought 'get it done' above 'do it right'.  In two decades of programming both as a consultant and as an employee I've NEVER had a code review.  Even during my two years of Y2K work, whatever I delivered was just fine as long as the end client was happy. <br> <br>

I've inherited systems where the documentation was literally four pieces of 3"x3" sticky notes that covered 'all I needed to know' about 28 in-production apps that I was now the sole supporter of.  What was on those sticky notes?  The user accounts and passwords for the Oracle database back-ends for the systems and the application names.  As you can expect, in-code documentation was non-existent.  When I attempted to improve the level of documentation for these systems (even just putting down the 'basics' of the system information on a single sheet of paper), I was threatened with dismissal for being too slow in working with these systems.  The other developers who had to interface with these systems I now supported greatly appreciated this additional information as it empowered them and made their work faster, but only a few of them adopted the use of this single-page  documentation solution for fear of pissing off the same management that had overseen the creation of this fiasco.<br> <br>

Perhaps I've just been unlucky in my career and I've only stumbled into positions where results always override process, but since I've seen it in small companies, large multinationals and in three levels of Canadian Government, so I suspect that any talk about documenting systems and truly following 'best practices' is just so much BS.  What management wants is results ASAP.  When things fail it isn't management's fault, yet it is management that prevents systems from being built with adequate documentation and review because that takes longer and costs more, for which they are penalized, and when systems fail, it is the programmer who is at fault, not the manager.<br> <br>

I figured that once I moved into management that I could become part of the solution, but then I found my VP giving me the same results pressure AND the developers who reported to me, ironically, simply wanted the code to be the documentation (The Agile 'the tests ARE the documentation' BS).<br> <br>

Nowadays I simply program for myself and for my direct clients, and this is the only way that I've found to be able to ensure that systems are adequately documented without encountering a fight or threats on my employment.</htmltext>
<tokenext>90 \ % of my work has been in the Canadian Oil and Gas industry and EVERY company that I 've worked for has sought 'get it done ' above 'do it right' .
In two decades of programming both as a consultant and as an employee I 've NEVER had a code review .
Even during my two years of Y2K work , whatever I delivered was just fine as long as the end client was happy .
I 've inherited systems where the documentation was literally four pieces of 3 " x3 " sticky notes that covered 'all I needed to know ' about 28 in-production apps that I was now the sole supporter of .
What was on those sticky notes ?
The user accounts and passwords for the Oracle database back-ends for the systems and the application names .
As you can expect , in-code documentation was non-existent .
When I attempted to improve the level of documentation for these systems ( even just putting down the 'basics ' of the system information on a single sheet of paper ) , I was threatened with dismissal for being too slow in working with these systems .
The other developers who had to interface with these systems I now supported greatly appreciated this additional information as it empowered them and made their work faster , but only a few of them adopted the use of this single-page documentation solution for fear of pissing off the same management that had overseen the creation of this fiasco .
Perhaps I 've just been unlucky in my career and I 've only stumbled into positions where results always override process , but since I 've seen it in small companies , large multinationals and in three levels of Canadian Government , so I suspect that any talk about documenting systems and truly following 'best practices ' is just so much BS .
What management wants is results ASAP .
When things fail it is n't management 's fault , yet it is management that prevents systems from being built with adequate documentation and review because that takes longer and costs more , for which they are penalized , and when systems fail , it is the programmer who is at fault , not the manager .
I figured that once I moved into management that I could become part of the solution , but then I found my VP giving me the same results pressure AND the developers who reported to me , ironically , simply wanted the code to be the documentation ( The Agile 'the tests ARE the documentation ' BS ) .
Nowadays I simply program for myself and for my direct clients , and this is the only way that I 've found to be able to ensure that systems are adequately documented without encountering a fight or threats on my employment .</tokentext>
<sentencetext>90\% of my work has been in the Canadian Oil and Gas industry and EVERY company that I've worked for has sought 'get it done' above 'do it right'.
In two decades of programming both as a consultant and as an employee I've NEVER had a code review.
Even during my two years of Y2K work, whatever I delivered was just fine as long as the end client was happy.
I've inherited systems where the documentation was literally four pieces of 3"x3" sticky notes that covered 'all I needed to know' about 28 in-production apps that I was now the sole supporter of.
What was on those sticky notes?
The user accounts and passwords for the Oracle database back-ends for the systems and the application names.
As you can expect, in-code documentation was non-existent.
When I attempted to improve the level of documentation for these systems (even just putting down the 'basics' of the system information on a single sheet of paper), I was threatened with dismissal for being too slow in working with these systems.
The other developers who had to interface with these systems I now supported greatly appreciated this additional information as it empowered them and made their work faster, but only a few of them adopted the use of this single-page  documentation solution for fear of pissing off the same management that had overseen the creation of this fiasco.
Perhaps I've just been unlucky in my career and I've only stumbled into positions where results always override process, but since I've seen it in small companies, large multinationals and in three levels of Canadian Government, so I suspect that any talk about documenting systems and truly following 'best practices' is just so much BS.
What management wants is results ASAP.
When things fail it isn't management's fault, yet it is management that prevents systems from being built with adequate documentation and review because that takes longer and costs more, for which they are penalized, and when systems fail, it is the programmer who is at fault, not the manager.
I figured that once I moved into management that I could become part of the solution, but then I found my VP giving me the same results pressure AND the developers who reported to me, ironically, simply wanted the code to be the documentation (The Agile 'the tests ARE the documentation' BS).
Nowadays I simply program for myself and for my direct clients, and this is the only way that I've found to be able to ensure that systems are adequately documented without encountering a fight or threats on my employment.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344216</id>
	<title>A fool's errand</title>
	<author>ClosedSource</author>
	<datestamp>1260124920000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>After you've been in this business for more than 20 years without giving it up to become a manager or guru, you may find that coding practices are orthogonal to code quality.</p><p>Just do the best you can with the cards you've been given.</p></htmltext>
<tokenext>After you 've been in this business for more than 20 years without giving it up to become a manager or guru , you may find that coding practices are orthogonal to code quality.Just do the best you can with the cards you 've been given .</tokentext>
<sentencetext>After you've been in this business for more than 20 years without giving it up to become a manager or guru, you may find that coding practices are orthogonal to code quality.Just do the best you can with the cards you've been given.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343634</id>
	<title>Re:Literate Programming</title>
	<author>CortoMaltese</author>
	<datestamp>1260120060000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>Yup. I'd go as far as saying readability is more important than correctness; fixing or improving easy to understand programs is trivial compared to trying to decipher spaghetti code. You write code for other people, and that other people might be <b>you</b> a few years from now.
<p>
I'm afraid you can't really force this attitude on people by using coding standards etc. though. I think it's something every coder needs to figure out for themselves. Like Pragmatic Programmer says, "care about your craft".</p></htmltext>
<tokenext>Yup .
I 'd go as far as saying readability is more important than correctness ; fixing or improving easy to understand programs is trivial compared to trying to decipher spaghetti code .
You write code for other people , and that other people might be you a few years from now .
I 'm afraid you ca n't really force this attitude on people by using coding standards etc .
though. I think it 's something every coder needs to figure out for themselves .
Like Pragmatic Programmer says , " care about your craft " .</tokentext>
<sentencetext>Yup.
I'd go as far as saying readability is more important than correctness; fixing or improving easy to understand programs is trivial compared to trying to decipher spaghetti code.
You write code for other people, and that other people might be you a few years from now.
I'm afraid you can't really force this attitude on people by using coding standards etc.
though. I think it's something every coder needs to figure out for themselves.
Like Pragmatic Programmer says, "care about your craft".</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344966</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>Anonymous</author>
	<datestamp>1260130200000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Hmmm, sorry to disagree with you but if you were working in my shop and you wrote something like that, a warning of "That's enough of that shit" would be immediate.  Repeating that behavior would result in an invitation to go practice your "craft" elsewhere.</p><p>As many many others have pointed out in this and other articles on the same subject there is little to be gained by this type of nonsense and in many cases much to be lost.  An as another poster pointed out in a reply to your post, the reliance on a null pointer being treated as boolean is both risky and stupid since form one compiler implementation to another that evaluation is subject to change.  even if you wanted to write this statement this way then to make it at least a proper statement then it should be: "for(ss = s-&gt;ss; ss!=null; ss = ss-&gt;ss);"  ss != null is guaranteed to evaluate as boolean ss simply being null is not.</p></htmltext>
<tokenext>Hmmm , sorry to disagree with you but if you were working in my shop and you wrote something like that , a warning of " That 's enough of that shit " would be immediate .
Repeating that behavior would result in an invitation to go practice your " craft " elsewhere.As many many others have pointed out in this and other articles on the same subject there is little to be gained by this type of nonsense and in many cases much to be lost .
An as another poster pointed out in a reply to your post , the reliance on a null pointer being treated as boolean is both risky and stupid since form one compiler implementation to another that evaluation is subject to change .
even if you wanted to write this statement this way then to make it at least a proper statement then it should be : " for ( ss = s- &gt; ss ; ss ! = null ; ss = ss- &gt; ss ) ; " ss ! = null is guaranteed to evaluate as boolean ss simply being null is not .</tokentext>
<sentencetext>Hmmm, sorry to disagree with you but if you were working in my shop and you wrote something like that, a warning of "That's enough of that shit" would be immediate.
Repeating that behavior would result in an invitation to go practice your "craft" elsewhere.As many many others have pointed out in this and other articles on the same subject there is little to be gained by this type of nonsense and in many cases much to be lost.
An as another poster pointed out in a reply to your post, the reliance on a null pointer being treated as boolean is both risky and stupid since form one compiler implementation to another that evaluation is subject to change.
even if you wanted to write this statement this way then to make it at least a proper statement then it should be: "for(ss = s-&gt;ss; ss!=null; ss = ss-&gt;ss);"  ss != null is guaranteed to evaluate as boolean ss simply being null is not.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30347102</id>
	<title>Re:Literate Programming</title>
	<author>Rene S. Hollan</author>
	<datestamp>1260102900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The problem her is the background and skill set of "the next slob".</p><p>Do I include a treatise  on the merits of sliding window protocols in an implementation of a TCP stack? It makes sense if "the next slob" know nothing about networking, but is smart enough to learn. Of course, the PHB will expect us to be "interchangeable" when this is clearly not true.</p><p>Or, do I dare presume that someone called upon to maintain network code will be happy with unsigned long wnd;<nobr> <wbr></nobr>/* sliding window */ in a structure as adequate documentation?</p><p>Often one does not even <b>know</b> the scope of a piece of code one is given, or what presumptions were made about "the next slob" by "last slob".</p><p>But. by far, the largest problem appears to be aggressive documentation to the level of the "lowest common denominator" expected to maintain something of the "trees" of a program, with little regard to the overall "forest" of them.</p></htmltext>
<tokenext>The problem her is the background and skill set of " the next slob " .Do I include a treatise on the merits of sliding window protocols in an implementation of a TCP stack ?
It makes sense if " the next slob " know nothing about networking , but is smart enough to learn .
Of course , the PHB will expect us to be " interchangeable " when this is clearly not true.Or , do I dare presume that someone called upon to maintain network code will be happy with unsigned long wnd ; / * sliding window * / in a structure as adequate documentation ? Often one does not even know the scope of a piece of code one is given , or what presumptions were made about " the next slob " by " last slob " .But .
by far , the largest problem appears to be aggressive documentation to the level of the " lowest common denominator " expected to maintain something of the " trees " of a program , with little regard to the overall " forest " of them .</tokentext>
<sentencetext>The problem her is the background and skill set of "the next slob".Do I include a treatise  on the merits of sliding window protocols in an implementation of a TCP stack?
It makes sense if "the next slob" know nothing about networking, but is smart enough to learn.
Of course, the PHB will expect us to be "interchangeable" when this is clearly not true.Or, do I dare presume that someone called upon to maintain network code will be happy with unsigned long wnd; /* sliding window */ in a structure as adequate documentation?Often one does not even know the scope of a piece of code one is given, or what presumptions were made about "the next slob" by "last slob".But.
by far, the largest problem appears to be aggressive documentation to the level of the "lowest common denominator" expected to maintain something of the "trees" of a program, with little regard to the overall "forest" of them.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344252</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343930</id>
	<title>While I'm not an expert developer....</title>
	<author>MrCrassic</author>
	<datestamp>1260122580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The one job that I did have as one made me realize exactly how uncommon it is in corporate-level work to find code with nice, detailed comments describing what's going on where. I will blame the lack of comments for one project I was assigned taking months to complete rather than weeks or days, especially considering that it was pure Java Swing code (i.e. no NetBeans), which is especially infuriating to work with.</p></htmltext>
<tokenext>The one job that I did have as one made me realize exactly how uncommon it is in corporate-level work to find code with nice , detailed comments describing what 's going on where .
I will blame the lack of comments for one project I was assigned taking months to complete rather than weeks or days , especially considering that it was pure Java Swing code ( i.e .
no NetBeans ) , which is especially infuriating to work with .</tokentext>
<sentencetext>The one job that I did have as one made me realize exactly how uncommon it is in corporate-level work to find code with nice, detailed comments describing what's going on where.
I will blame the lack of comments for one project I was assigned taking months to complete rather than weeks or days, especially considering that it was pure Java Swing code (i.e.
no NetBeans), which is especially infuriating to work with.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344282</id>
	<title>Re:Literate Programming</title>
	<author>Alomex</author>
	<datestamp>1260125520000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><i>The purpose of creating a program really is to instruct the computer what to do. Not to explain other human beings what we want the computer to do.</i></p><p>This is a very common misconception, we do want other humans to know what we want the computer to do, namely the poor saps who end up maintaining your crappy code.</p><p>So if you think about it, there are two consumers of code: the compiler and the fellow who will maintain it for the next ten years. If you program with just one or the other in mind you are doing a darn poor job at writing code.</p><p><i>One should, however, try to make his code as readable and elegant as he possibly can without sacrificing precision in the message to the computer.</i></p><p>The computer doesn't complain if it has to work twice as hard to properly parse your code. So in the tradeoff between human and computer readability we must favor the human. Of course if we end up with incorrect code in the name of readability we have gone too far. I have yet to see code like this.</p></htmltext>
<tokenext>The purpose of creating a program really is to instruct the computer what to do .
Not to explain other human beings what we want the computer to do.This is a very common misconception , we do want other humans to know what we want the computer to do , namely the poor saps who end up maintaining your crappy code.So if you think about it , there are two consumers of code : the compiler and the fellow who will maintain it for the next ten years .
If you program with just one or the other in mind you are doing a darn poor job at writing code.One should , however , try to make his code as readable and elegant as he possibly can without sacrificing precision in the message to the computer.The computer does n't complain if it has to work twice as hard to properly parse your code .
So in the tradeoff between human and computer readability we must favor the human .
Of course if we end up with incorrect code in the name of readability we have gone too far .
I have yet to see code like this .</tokentext>
<sentencetext>The purpose of creating a program really is to instruct the computer what to do.
Not to explain other human beings what we want the computer to do.This is a very common misconception, we do want other humans to know what we want the computer to do, namely the poor saps who end up maintaining your crappy code.So if you think about it, there are two consumers of code: the compiler and the fellow who will maintain it for the next ten years.
If you program with just one or the other in mind you are doing a darn poor job at writing code.One should, however, try to make his code as readable and elegant as he possibly can without sacrificing precision in the message to the computer.The computer doesn't complain if it has to work twice as hard to properly parse your code.
So in the tradeoff between human and computer readability we must favor the human.
Of course if we end up with incorrect code in the name of readability we have gone too far.
I have yet to see code like this.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346674</id>
	<title>Re:author seems somewhat confused and inexperience</title>
	<author>dkf</author>
	<datestamp>1260099600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>And this is relevant to 99.9\% of the software out there how?</p></div><p>It isn't. <i>Now.</i> But if the code is inherited from the "olden days", then those stupid restrictions did matter back then. (I remember Ultrix. How I hated how Ultrix carried out linking. The old Linux a.out system was much nicer, despite being awful.)</p></div>
	</htmltext>
<tokenext>And this is relevant to 99.9 \ % of the software out there how ? It is n't .
Now. But if the code is inherited from the " olden days " , then those stupid restrictions did matter back then .
( I remember Ultrix .
How I hated how Ultrix carried out linking .
The old Linux a.out system was much nicer , despite being awful .
)</tokentext>
<sentencetext>And this is relevant to 99.9\% of the software out there how?It isn't.
Now. But if the code is inherited from the "olden days", then those stupid restrictions did matter back then.
(I remember Ultrix.
How I hated how Ultrix carried out linking.
The old Linux a.out system was much nicer, despite being awful.
)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345322</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343744</id>
	<title>Re:Subs and functions</title>
	<author>DarkIye</author>
	<datestamp>1260121080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I hope you're coding a washing machine or something.</htmltext>
<tokenext>I hope you 're coding a washing machine or something .</tokentext>
<sentencetext>I hope you're coding a washing machine or something.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343546</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344574</id>
	<title>Re:Too MUCH of this</title>
	<author>Krahar</author>
	<datestamp>1260127440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Some of the worst code I have seen written is in C++, Java and C#. OO over the top, full of OO jargon, code that wanders around a thousand method calls without solving the problem, and TOO MUCH CODE, zillions of complex libraries and dependancies.</p></div><p>Code that "wanders without solving the problem" is a direct consequence of writing cohesive classes that solve one problem and delegates everything it isn't responsible for. The point to appreciate such a thing is to consider the abstractions involved as the basic concepts with which to think about the program. This is an acquired skill. If you view a debug trace as the basic tool to understand your program, you will have a hard time, and that seems to be the basis of your frustration.</p></div>
	</htmltext>
<tokenext>Some of the worst code I have seen written is in C + + , Java and C # .
OO over the top , full of OO jargon , code that wanders around a thousand method calls without solving the problem , and TOO MUCH CODE , zillions of complex libraries and dependancies.Code that " wanders without solving the problem " is a direct consequence of writing cohesive classes that solve one problem and delegates everything it is n't responsible for .
The point to appreciate such a thing is to consider the abstractions involved as the basic concepts with which to think about the program .
This is an acquired skill .
If you view a debug trace as the basic tool to understand your program , you will have a hard time , and that seems to be the basis of your frustration .</tokentext>
<sentencetext>Some of the worst code I have seen written is in C++, Java and C#.
OO over the top, full of OO jargon, code that wanders around a thousand method calls without solving the problem, and TOO MUCH CODE, zillions of complex libraries and dependancies.Code that "wanders without solving the problem" is a direct consequence of writing cohesive classes that solve one problem and delegates everything it isn't responsible for.
The point to appreciate such a thing is to consider the abstractions involved as the basic concepts with which to think about the program.
This is an acquired skill.
If you view a debug trace as the basic tool to understand your program, you will have a hard time, and that seems to be the basis of your frustration.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343900</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344158</id>
	<title>Testability</title>
	<author>cmsjr</author>
	<datestamp>1260124440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>While coding style is certainly important, the most clearly written, nicely commented, richly documented source possible can't tell you if the code does what it's intended to. Formal coding standards may help mitigate the difficulty of debugging and modifying a program, but I think can you get a lot more bang for your buck by implementing a solid testing framework.  If I had to pick between coding behind someone with great style, or someone with great unit tests, I'd take the latter.</p></htmltext>
<tokenext>While coding style is certainly important , the most clearly written , nicely commented , richly documented source possible ca n't tell you if the code does what it 's intended to .
Formal coding standards may help mitigate the difficulty of debugging and modifying a program , but I think can you get a lot more bang for your buck by implementing a solid testing framework .
If I had to pick between coding behind someone with great style , or someone with great unit tests , I 'd take the latter .</tokentext>
<sentencetext>While coding style is certainly important, the most clearly written, nicely commented, richly documented source possible can't tell you if the code does what it's intended to.
Formal coding standards may help mitigate the difficulty of debugging and modifying a program, but I think can you get a lot more bang for your buck by implementing a solid testing framework.
If I had to pick between coding behind someone with great style, or someone with great unit tests, I'd take the latter.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345468</id>
	<title>Always write code as if...</title>
	<author>ebbe11</author>
	<datestamp>1260090600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>...the guy who is going to maintain it is a 6'6" bodybuilding psychotic maniac who knows where you live.</htmltext>
<tokenext>...the guy who is going to maintain it is a 6'6 " bodybuilding psychotic maniac who knows where you live .</tokentext>
<sentencetext>...the guy who is going to maintain it is a 6'6" bodybuilding psychotic maniac who knows where you live.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343740</id>
	<title>Optimize all the time... for clarity</title>
	<author>noidentity</author>
	<datestamp>1260121020000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>Optimization is fine, as long as you're "optimizing" the code to be more clear. This is a good way to redirect the energy that programmers often put into pointless performance optimization. Most understand that optimizing for one thing often de-optimizes somthing else, so they understand that you can't optimize for speed and clarity in many cases. Always looking for ways to make code clearer can become an enjoyable habit, as optimizing for speed is for many. Then you spend your idle moments eliminating many lines of code that you realize are unnecessary, bringing the code closer to its essence. My experience anyway.</htmltext>
<tokenext>Optimization is fine , as long as you 're " optimizing " the code to be more clear .
This is a good way to redirect the energy that programmers often put into pointless performance optimization .
Most understand that optimizing for one thing often de-optimizes somthing else , so they understand that you ca n't optimize for speed and clarity in many cases .
Always looking for ways to make code clearer can become an enjoyable habit , as optimizing for speed is for many .
Then you spend your idle moments eliminating many lines of code that you realize are unnecessary , bringing the code closer to its essence .
My experience anyway .</tokentext>
<sentencetext>Optimization is fine, as long as you're "optimizing" the code to be more clear.
This is a good way to redirect the energy that programmers often put into pointless performance optimization.
Most understand that optimizing for one thing often de-optimizes somthing else, so they understand that you can't optimize for speed and clarity in many cases.
Always looking for ways to make code clearer can become an enjoyable habit, as optimizing for speed is for many.
Then you spend your idle moments eliminating many lines of code that you realize are unnecessary, bringing the code closer to its essence.
My experience anyway.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346920</id>
	<title>Re:What is clear to one ...</title>
	<author>mikael</author>
	<datestamp>1260101640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>These days, there seem to be so many different ways of processing array data now, many of which seem to be mutually exclusive, multi-threaded code<nobr> <wbr></nobr>/OpenMP/MPI/TBB vs. STL / templates, that manually assigning/incrementing/testing an array index/loop pointer is a bad way of doing things.</p><p>Under STL, you just have an iterator that goes through the data structure, with just an initialize, increment and test functions. With some of the parallel processing macros, you just have a  forall(array) above a pair of parenthesis with the individual tasks.</p><p>At all the companies I interviewed for, they would have a series of test questions at a particular level - either how to manually manage linked lists (embedded device drivers), how to implement data structures using STL (R&amp;D) or how to implement multi-threading (parallel processing applications).</p></htmltext>
<tokenext>These days , there seem to be so many different ways of processing array data now , many of which seem to be mutually exclusive , multi-threaded code /OpenMP/MPI/TBB vs. STL / templates , that manually assigning/incrementing/testing an array index/loop pointer is a bad way of doing things.Under STL , you just have an iterator that goes through the data structure , with just an initialize , increment and test functions .
With some of the parallel processing macros , you just have a forall ( array ) above a pair of parenthesis with the individual tasks.At all the companies I interviewed for , they would have a series of test questions at a particular level - either how to manually manage linked lists ( embedded device drivers ) , how to implement data structures using STL ( R&amp;D ) or how to implement multi-threading ( parallel processing applications ) .</tokentext>
<sentencetext>These days, there seem to be so many different ways of processing array data now, many of which seem to be mutually exclusive, multi-threaded code /OpenMP/MPI/TBB vs. STL / templates, that manually assigning/incrementing/testing an array index/loop pointer is a bad way of doing things.Under STL, you just have an iterator that goes through the data structure, with just an initialize, increment and test functions.
With some of the parallel processing macros, you just have a  forall(array) above a pair of parenthesis with the individual tasks.At all the companies I interviewed for, they would have a series of test questions at a particular level - either how to manually manage linked lists (embedded device drivers), how to implement data structures using STL (R&amp;D) or how to implement multi-threading (parallel processing applications).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344840</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_65</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343900
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30360564
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_48</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346520
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345286
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343622
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345222
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343546
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30350644
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344754
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345322
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346674
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30348698
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343546
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30352696
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_66</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343622
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343734
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344966
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30350170
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344252
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30347344
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_58</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345348
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_63</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343622
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344840
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346920
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345338
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344830
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30347824
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343542
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343708
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_54</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30348624
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344966
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345704
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344800
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344424
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344814
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30373862
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_60</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345654
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346430
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343900
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344574
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_53</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345244
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343726
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30353670
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_49</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344468
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_52</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345062
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344252
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30347102
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343546
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343770
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346802
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30353612
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344966
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30351138
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343546
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343744
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343622
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30349034
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30363410
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_51</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345924
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345398
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343900
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30385964
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30350594
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344638
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30348124
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344830
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30347110
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_64</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345378
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_57</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30355890
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344830
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30350664
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343682
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_61</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343634
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344074
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_56</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344686
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344252
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30347350
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343622
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343826
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345464
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30347534
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344754
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345322
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30350544
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345318
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344638
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30349014
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_59</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345084
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343622
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30348888
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343666
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344310
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_62</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345796
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344282
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_55</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30351972
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344882
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345644
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345418
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344178
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30348326
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346684
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345294
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344338
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_50</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344638
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30348144
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346882
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_06_1456251_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344252
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346528
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343510
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343804
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345202
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343936
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343726
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30353670
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343530
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343682
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343634
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344074
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343736
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346520
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346882
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346684
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30350594
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345244
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30348624
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344252
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30347350
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346528
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30347102
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30347344
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30355890
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345318
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345644
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345378
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30351972
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345654
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346430
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345338
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345796
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344424
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344814
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345348
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344338
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344282
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345660
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345464
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30347534
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345240
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343674
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343834
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345564
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343792
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343838
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344966
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30351138
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30350170
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345704
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345084
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344830
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30347824
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30347110
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30350664
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344800
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344638
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30348124
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30349014
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30348144
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345924
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345062
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30373862
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345294
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344686
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30348698
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344754
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345322
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346674
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30350544
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345286
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343666
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344310
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344178
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30348326
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343766
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30363410
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343546
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343770
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346802
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30353612
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30350644
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343744
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30352696
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343764
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346064
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343622
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30349034
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344840
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30346920
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30348888
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343826
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343734
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345222
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343542
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343708
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344216
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343900
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30385964
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344574
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30360564
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345310
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345666
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_06_1456251.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30343918
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345418
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30345398
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344882
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_06_1456251.30344468
</commentlist>
</conversation>
