If you give me code without comments...

I'LL BREAK YOUR FUCKING FACE!!!!11111

NO TROLL.

# FUCK OFF

if it's any good code, it would be self-documenting. comments irrelevant

>>3
Sometimes you have to do something tricky for whatever reason. This is a very good reason for comments. Also, you should only write comments that explain why rather than how.

>>3
That's why you only comment non-trivial things, or abstract reasoning behind the code.

#include <iostream>

int far ( int x )
{
 return (x-32)*(5/9);
}

int cel ( int x )
{
 return x+32*(9/5);
}

using namespace std;

int faren();

int cels();

int main ()
{
  int input;
 
  cout<<"1. Celsius to Fahrenheit\n";
  cout<<"2. Fahrenheit to Celsius\n";
  cout<<"Selection: ";
  cin>> input;
  switch ( input ) {
  case 1:           
    cels();
    break;
  case 2:           
    faren();
    break;
  default:           
    cout<<"Error\n";
    break;
  }

int faren {
 
  int x; 
  cout << "Temperature Farenhieht:";
  cin>> x;
  cin.ignore();
  cout << "Celsius:" << far(x);
  cin.get();
  }
 
int cels(){
  int x; 
  cout << "Temperature Celsius:";
  cin>> x;
  cin.ignore();
  cout << "Fahrenheit:" << cel (x);
  cin.get();
  }

STD!

>>6
needs more goto

>>3
So called "self-documenting" code tells you what it's doing, but not why.  Comments that say "what" are useless, since duh, that's what the code says.  Comments that say "why" are what people are always too stupid to include.  Then again, most programmers are just genetic programmers that beat against it randomly until it works and have no fucking clue why it works.

>>9
But "why" isn't the programmer's job, unless it's a non-corporate project.

>>1
Comments are rarely required, and they are often abused to the point where it is difficult to find the code buried inside.

>>10
It is definitely the programmers job to show why the decisions in his code fulfill the requirements.

>>12
Look, the only way to know if what the programmer is doing "fulfills" the requirements, every line of assembly generated must be analyzed. Comments do *not* prove this.

>>13
It's not a proof, it's a description of the decisions the programmer made that resulted in him writing that code.  What, you've never looked at code, scratched your head, and thought "Why the fuck did he put that in there?" or "How does this even work?"

>>14
Well, if the code isn't straightforward, then yes. Good programmers have a habit of making most of their code straightforward, with the exception usually being optimizations and shortcuts.

>>15
...and writing code with ordering dependencies, and when downcasting under preconditions enforced elsewhere, and when doing state machines or other fragmented code, and when writing workarounds for buggy libraries or OS calls, etc.  All of which are not optimizations nor shortcuts, but whose rationale needs to be documented in the code so others don't fuck it up.

If you give me code without a fully specified proof in Coq...
I'LL BREAK YOUR FUCKING FACE!!!!11111

>>15
Good programmers also make use of the language features available to good effect. Writing for an audience that is stupider than oneself is a good way to become stupid too.

>>18
Congratulations, according to this thing, you're fucking gay.

If you add a comment like this:
#include "stdafx.h" // lulz, why microsoft - you sux

or like this:
class Foo
{
  //----------------
  // Foo Constructor
  //----------------
  Foo()
  {
  }
};
I'LL BREAK YOUR FUCKING FACE!!!!11111

>>16
The details of both of those could easily be hidden in classes such as FSM and OSCommand. The point is that a good programmer keeps a consistent intuitive style where comments are only necessary in the implementation details of the various functions are in another file. The right design ensures that everything the client will see is clear. Comments will not help clients get a grasp of very complicated code, since they are generally less versed in the details of a programming language.

>>9 speaks the truth.

hey guys, check out the self-documenting code for quake 4:

// === CONFIDENTIAL ===
// QUAKE 4 SOURCE CODE FROM ID AND STUFF
#include <quake4.h>
int main(int argc, char **argv) {
    initializeGameEngineSoThatTheGameCanStart();
    loadTheBspMapWhereThePlayerStarts();
    initializeTheEntitiesInTheBspMap();
    while(true) {
        renderTheEntitiesFromThePlayersView();
        runTheGameLogicSoThatTheEntitiesCanAttackThePlayerAndStuff();
    }
}

>>1
I'll pin you down while >>1 breaks your fucking face.

>>24

That doesn't make any sense.

>>25
With his feet

>>26
Still doesn't make sense. I would not break my own face. Plus, I buy the code so I do the face breaking, not the other way around.

>>27
Oh, the first >>1 was superfluous. I was talking about morons who don't comment their code because they're too cool to comment.

Either you know the language or you don't. If you don't, no amount of commenting is going to help you understand wtf is going down.

>>29
my other troll is a pronunciation thread

>>29
Wow, what a failed troll.

>>29,30,31
i don't get why this is a troll attempt. i just dismissed it as just another retard giving his stupid opinion

35 Name: Anonymous 2012-06-25 23:35

ţ镗ၳ2㐑螁衡ᢗ咔皃脔ԧ㘉ᙷ舦ش㎘嘈攇虖葆襈楹呢商靠扖獃袀ᑱ邀቗䆆儥䡈㤴ѣ㐦劖掓挐䄱楴❹䦀䅈⥂圤ℙ␦匁衑㜅݇熅գ历無ቲ蕥衱ƅ᥶隉ᑒ镔钄䀤㌨㥁态椦鞗邂皗ځ፲䙂هQ癄䤱␔፩脨附䍖饘眀憅嚕蘲㄂芖ॐ犁䤑䝗褣爇⌘颈鍈栣᎓ᐴ塓࠷䜹⡰⤶ٸ腩禉袂㠧ជ除琈禘㠂❄瑳礕璈ㆇ挒╷ህ枖㍲挹䔗㤳閙⑈㠁垄ᢄ碇覙虦㥷朢᠃码∷剆癡搴垑ᡕ焇ᤧ∳券T瘸㘰╵ᦅ☴ㄇ㕆蜑〒㙃ဒ၀ផ㉁ᜡ䠆卆蘩玃ք甃ぱ爦ᔆ㈡蜇㤹٨ቹ᜔䐸頵╅爨蘸堘㈂襠ц琠በ䙠镂蒐兘ざ蘖ᒀ蕃捓Ԡ蝘焦剩阇舠ဴ啵—祧礔⡁砥偐ᔇ暄嚂阉㑡ᙢ剂熙䉖Ș̓٘蠰॰ȥ䜈ㆁ儩灉䍕蔣㝑葑途傂㌵嘄ވ膑恅硰靕ሧ霵螖靇肒錑鞆Йㄒ⠃遵折蠴䤳➐搸镁ض斄坵艅ɗ獲㑆ဂ➖⍱ᔘ㈱銉㉷蘉舒匦扔視⍃儒遣案瘉瞑㤶ខ瑠儙