/tech/ - Technology★

The proper thing to do is to handwrite a 1:1 copy of your code in a notebook, and put your comments on that, that way you can reference it, but any faggot that steals your code will be forced to come to /tech/ and make a thread bitching about how people don't document their code.

>>892562 (OP)

>another bikeshedding topic

sage

>>892573

>"Oh no, somebody created thread I don't like on my slow board, oh what I'm going to do"

>>892562 (OP)

>spergs out over commenting (nevermind he complains "how comments work in c/c++" why apparently really being confused about what is too much and what is too little commenting)

>his example has no indentation whatsoever

hmmm

/* This program is illustrating a preferred comment etiquette
* and style.
* This is public domain
*/

/* Import C library */
#include <stdio.h>

main( )
{
/* This will produce the phrase "Hello World" which will
* be followed by a new line. This exits cleanly.
*/
        printf("hello, world\n");
}

It's not that hard

/////////////////////////////////////////////////////////////
/loooooooooooooooooooooooooooooooool/
/////////////////////////////////////////////////////////////

>>892620

#include <stdio.h>
void *main(void)
{
    puts("\x6b\x65\x6b\x6b\x69\x74\x79\x20\x6b\x65\x6b\x0a");
    return NULL;
}

>>892562 (OP)

You're fine.

Just note:

//This is a C++ style comment. It should work on most modern C utilities and compilers, but many older C utils and compilers can't process them.

[code]/* This is a C style comment. All C compilers and utilities will support this no matter the age.[/spoiler]

>>892562 (OP)

>not using the 1337 w@yZ

/*

 ▒███▒   ███   █▓██   ░███░   █▒██▒ ░███░  █████   ███    █▒██▒
 █▒ ░█  ▓▓ ▒█  █▓ ▓█  █▒ ▒█   ██  █ █▒ ▒█    █    █▓ ▓█   ██  █
 █▒░    █   █  █   █      █   █         █    █    █   █   █    
 ░███▒  █████  █   █  ▒████   █     ▒████    █    █   █   █    
    ▒█  █      █   █  █▒  █   █     █▒  █    █    █   █   █    
 █░ ▒█  ▓▓  █  █▓ ▓█  █░ ▓█   █     █░ ▓█    █░   █▓ ▓█   █    
 ▒███▒   ███▒  █▓██   ▒██▒█   █     ▒██▒█    ▒██   ███    █    
               █                                               
               █                                               
               █ 
*/

>>892626

>\x6b\x65\x6b\x6b\x69\x74\x79\x20\x6b\x65\x6b\x0a

>kekkity kek

\x6b\x65\x6b\

>>892633

It's not guaranteed how characters beyond 0x7f are going to be displayed (.nfo style shit generally relies on plain old codepage 437, use anything else and it'll look like random crap).

>>892562 (OP)

Typically in the header file, I'll document each of the functions, there arguments, any restrictions, and return value. In the source file, functions are only commented if they have a complicated procedure to follow. Inside of functions comment things that aren't obvious in what you are doing. Finally, I like to break some functions up with an abstract description of what is trying to be done in the following code.

In addition to these comments, you should be writing "self documenting code."

>>892645

>func1

>func2

That's not self documenting.

You put quotation marks around it to turn it into a no-op string literal.

That doesn't work if you already use string literals in your code but real programmers don't work with text anyway.

>>892643

It was more of a LARP tbh, though it can be done in UTF8 as well as CP437.

It is simple to convert between codepages, either in the terminal display or file format itself.

>>892676

what's the candy it looks really good but im allergic to peanuts

>>892629

It's also a standard C99 comment. If your C compiler doesn't support a 19-year old language standard revision, you should seriously get a fucking new compiler.

>>892643

>not using glorious unicode in comments

how do you even use nigger emojis then