so /g/ do you write comments in your code? why?

>>60932292
1.no
2.cuz I ain't gay nor a fucking nerd kek

Yes, because I'm not a fucking nigger who hates documentation.

No, I don't for maintenance reasons.Anyone that can't understand the code from reading it shouldn't be modifying it.

>>60932292
I shit on different races and genders on my comments and unreachable code.
>mfw ppl use transphobic apps to defend mental illness haha

>>60932292

Yes, because it's part of the work product.

>>60932316

>not understanding what comments are

Don't LARP here.

whatever

>>60932292
I write more comments than I do code.

t. Javadoc stickler

not really

File: weighted_dips.jpg (63KB, 640x480px) Image search: [Google]

63KB, 640x480px

No, because good code doesn't require comments.

>>60932292
no function and variable names are my documentation

>>60932308
>making your life harder

>>60932292
ITT: fucking noobs who can't read C code like English

>>60933080
>int thisLoopCalculatesTheSumOfAllPrimesBetweenOneAndTwoMillionAndThenPerformsFizzBuzzBeforeReturningTheAnswer

>>60932292

yes

might as well

>>60933252
I like that function.
I'd like to buy a beer for that function.

Anyone who doesn't is a retarded asshole.

>>60932292
Web developer. I comment every class and method using either phpdoc or jsdoc.

/**
 * A brief description of what the class or method does.
 * @param {number} id - A number parameter.
 * @param {string=} name - An optional string parameter.
 * @returns {Object} Whatever the method returns.
 */

And so should you.

>>60933503
I always enforce xmldocs in my hobby projects. It's so convenient when you come back to a project after a while and have the documentation available from intellisense (I'm a Visual Studio babby).

/// <summary>
/// Performs the supplied <paramref name="operation"/> on the supplied <see cref="Bitmap"/> <paramref name="bitmap"/>.
/// </summary>
/// <param name="bitmap">
/// The <see cref="Bitmap"/> to perform the operation on.
/// </param>
/// <param name="operation">
/// The operation to perform on the contents of the supplied <see cref="Bitmap"/>.
/// </param>
/// <param name="lockMode">
/// The locking mode for the <see cref="Bitmap"/>. Defaults to <see cref="ImageLockMode.ReadOnly"/>.
/// </param>

>>60932292

Only if it's really hard. Then it's good to write comments because you'll be spending way more time thinking than writing anyway.

Doc comments for public functions.
Oneliners describing following few lines.
Shitton of // TODO ...

Only on lines or functions who's purpose isn't immediately obvious, or as a short description of what the variables passed to a complicated function do.

>>60932292
Your identifiers should be named suggestively enough that your code becomes "self-documenting"

It should never be necessary to rely on a comment to make it clear what your code is doing.

Sometimes it can be valuable to leave comment explaining *why* your code is doing something.

>>60933252
or, if you're not retarded:

String value = fizzBuzz(sumPrimesLessThan(2*million));

>>60932292
Because I code drunk and sleep deprived.

If it's a non-trivial method I'll write commented pseudocode first, then write the code for each line under the pseudo. Comments for free, just keep them updated

>>60933552

This. A lot of code is self documenting, but there are situations where it helps to understand the data being processed and why it's being processed that way.