You are not logged in.
EDIT: I decided this might be better off as a general style thread for C-like-syntax languages (C, C++, Java, ObjC, D)
Everyone, what's the general style you use with languages that have a bracketed syntax like C does?
What are the advantages to your style, as you see it? For example, K&R style saves vertical file length, but Allman (aka ANSI) makes block starts more clear.
A nice rundown of some common ones here: http://en.wikipedia.org/wiki/Indent_style
And, what is your preferred 'style' when it comes to comments in C?
Do you use the C++-style '//' comments for single lines, or do you still use the C-style '/**/', and why? Is there anyone that prefers C-style even if they don't care about supporting old non-C99 compilers?
Second, and this is what I'm most curious about, do you often put short comments on the same lines as source code? How often, and with how much of a space between the comment and the code itself?
When writing comments on the same line as code, do you capitalize the beginning of the comment? Do you add a period to the end?
Lastly, while we're on the subject, what's your 'rule' for line length? I like a 100-char limit, but 80-char is the 'standard', and some people use more than 100 due to a rise in large and widescreen monitors.
No holy wars, please! Just a few questions I've been pondering, it's all personal preference in the end
Last edited by Ranguvar (2009-11-21 01:05:26)
Offline
I always use /**/ just to be consistent. I also always put comments on a line by themselves, and don't really have a reason for that.
As far as the line length, I stick to the relatively agreed upon 80 character length with no exceptions. It just feels right.
Happy Hacking!
Twitter: http://twitter.com/bobbyrburden/
Website: http://codebutcher.com/
Offline
I honestly can't think what I do with comments in C and C++ as I only realy use it for assignments. I think I tend to use /**/ for block comments, say at the start of a function but most other comments I use //. I often use them at the end of lines, often on code blocks if there is a sizeable number of lines in them:
if (a < b) {
...
...
...
} // end if(a < b) {
Line length is tricky. I have pretty much settled on 80 characters. I have vim set to highlight anything beyond 80 characters in red. I also highlight trailing spaces on a line. Helps keep things neat. I like 80 characters as I can fit several terminals on ech screen without code wrapping. It also makes it easy to print out for reviewing. I don't really notice a difference when coding but I do prefer 80 column text when having to read back over it. Makes a big difference to me.
Offline
I mainly am using C++ right now for school and starting Haskell for fun. I haven't done any C in ages. I think my classes next semester will use C more though. My Robotics professor said we would be heavy in C, and I am guessing my Operating System class is probably using C code. But for now, I write a decent bit of C++ for school, and the professor gives us the freedom to do a lot of things how we want. So:
I always use 80 chars. I have my WM setup so my three terminals to the right of the browser on my main window have exactly room to display 80.
I use // comments almost all the time. I mainly use /**/ at the top of a program, and otherwise I reserve /**/ for commenting out blocks of code for testing purposes, since you can nest // inside /**/ but you can't nest /**/ inside another /**/.
Most of my comments are at the top of functions, but I'll occasionally stick little comments near anything I think if not self-explanatory. I've been trying to cut back on commenting within the code some, and it varies by the day how well a job I do of it.
To understand recursion, you must understand recursion.
Offline
/* like this for function documentation and other misc. doc
* I like to keep it to about 60 chars/line because I use a netbook
* as my main computer. */
// for simple comments like:
// this should be simplified in later versions for modularity
urxvtc / wmii / zsh / configs / onebluecat.net
Arch will not hold your hand
Offline
Comments are for wimps!
Offline
/*...*/ everywhere. Habit, I suppose.
When I was writing a lot of Java, I used to use a lot of C++ style line comments, but when I started with C I unlearned them, mainly for the sake of compiling with -ansi.
Offline
Comments are for wimps!
I guess that's why you usually break so much stuff
My comments are // for single line and /**/ for multi line.
"I'm Winston Wolfe. I solve problems."
~ Need moar games? [arch-games] ~ [aurcheck] AUR haz updates? ~
Offline
Comments are for wimps!
Oh no, not another Real Programmer!
The reason for "Allan broke it" has indeed been discovered
Offline
Comments are for wimps!
So are descriptive variable names, whats wrong with a2Z?
; Besides real programers dream and code in Assembler and get to pop their stack.
Live Free or Die !
Offline
Doesn't anyone use doxygen or one of the other docgen systems?
That tends to enforce a rather standard commenting style, and with emacs skeletons, most of the work short of writing the actual comment can be automated. It tends to look like what Lexion says.
Offline
Comments? What are those?
Yes, I know it's bad practice, but I don't write any comments. My prof doesn't look at the code anyway. Before I transferred colleges, I used to write great comments.
Offline
/**
* If I am doing a big comment full of
* things like explanations, then I use
* a C style comment like this.
*
* I use these pretty much only for
* function definitions, or anything else
* that is "outside" of code.
*/
// This is an example of a small comment, using
// C++ style. I can comment out my code using
// "/*" and "*/" and it's no problem!
pretendFunctionCall(pretendVariable);
I don't use a hard limit on how many columns wide my code is allowed to be, but if it "looks" too long then I will rewrite it.
if (
pretendFunction(pretendVariable) &&
anotherPretendFunction(
pretendVariable,
anotherPretendVariable,
yetAnotherPretendVariable
)
) {
// Do something amazing!
functionDoSomethingAmazing();
}
My code is probably all less than 100 columns. I always use complete sentences and proper punctuation and capitalization.
When I was in college, it was kind of fun getting into "formatting wars", but I'm happy to be comfortable with any style now, as long as it's consistent!
...but I still enjoy a good editor war, just for fun.
Offline
C style comments, C++ style seems foreign to me. I keep to 80 character limits.
Personally, I'd rather be back in Hobbiton.
Offline
My comment style depends on location and the actual complexity of the code, if it's something very large and complex I'd do something like this:
/************
*
* My head bit goes here and
* I take a nice bit of space
* to explain it.
*
*****************/
include "include1";// list of stuff loaded from it
include "include2";// class1, class2, func1
/*** func2 ******
* explained *
**************/
function func2(){
do_something();
if( $a < $b ){
func1();
$c = new class1();
while( $c->foo ){
$c->cheese('bar');
}// while => c.foo
}// if => (a < b)
do_another_thing();
}// func => func2
But rarely I use comments if the opening block is less than 10 or so lines from the opener, and if my function can't be explained I tend to extract it out where the definition on the top of the code explains it.
Offline
a comment for the header, a comment for before each function (you know like java-doc ?) and the header file which keeps track of all info we need from functions.
and of course block indentation !!!
/* the_end(int x) - receives x provides ... */
.../* the main() function */
void main(...){
int x;
for(...){
if(...){
printf(...);
};
};
the_end(x);
}
If people do not believe that mathematics is simple, it is only because they do not realize how complicated life is.
Simplicity is the ultimate sophistication.
Offline
I comment rabidly. Not to say "this line does such-and-such", which basically means "I can't write this more clearly", but mostly to describe the behavior of functions (and classes, in languages that have them). I think of it not so much as explaining your code as documenting your API. And believe me, it helps. I'm currently working on a project of less than 500 lines, all of which I wrote myself, and I still forget how to use the functions in it.
I find it best to write the description of the function, what it returns, what parameters it takes, what side effects it may have, etc., before actually implementing it. Put it in comments, mark it up a little -- pod, doxygen, javadoc, whatever -- and you're done with documentation. I think it actually saves me time because I get the design in my head before I start investing myself in implementation.
Offline
Still my biggest C program (pathetic, I know), this is a solution to K&R's Ch.1 Q.13, which you can read at the beginning of the file.
It's a good example of my current style.
http://repo.or.cz/w/tcpl.git/blob_plain … :/ch1/13.c
I use tabs for indentation, and spaces for aligning code, to allow anyone to set their own tab width.
I like 8-character indent in my editor, though. The clearly defined blocks really help.
Since the blocks are so clearly defined, I see no need for Allman-style:
if (something)
{
foo();
bar();
}
else
{
bar();
foo();
}
I use a more K&R style:
if (something) {
foo();
bar();
} else {
foo();
bar();
}
I use C-style comments for important single-liners and multi-liners, as such:
/*
* IMPORTANT
*/
For single-line comments that are descriptions of a following block of code, I use C++-style comments on their own line, capitalized and with some punctuation except for extremely short comments.
I have no patience for compilers that can't keep up with ISO/ANSI C99 (*cough*MSVC*cough*), which is around 10 years old now, and was publicly in the works long before that
// This next block of code kicks ass.
while (awesomeness) {
kick_ass("awesomeness");
foo();
}
And for comments that share lines with source code, they are quick lowercase sloppy notes in C-style. The C-style makes them stand out more and just looks better there, IMO.
No real rule on how far away from the code they are spaced, but usually a 5-char or so minimum, and I often align them with other comments.
super_fuction(1, 2455, "foobar"); /* note to make this understandable, if possible */
Last edited by Ranguvar (2009-11-21 06:50:16)
Offline
I don't use comments in those kernel drivers that we provide to our customers by the company, so I've got a sed script for it to remove all the comments in source files.
In my hobby/leisure time I follow desired part of the kernel/git coding style.
Offline
Not in-line commenting, but in line with the whole non-commenting thing:
To understand recursion, you must understand recursion.
Offline
Offline
I don't use comments in those kernel drivers that we provide to our customers by the company, so I've got a sed script for it to remove all the comments in source files.
LOLwut?
You actually do work to remove comments?
Offline
I use Qt everywhere I can and try to make my code follow it's established coding guidelines as closely as reasonable.
Offline
djszapi wrote:I don't use comments in those kernel drivers that we provide to our customers by the company, so I've got a sed script for it to remove all the comments in source files.
LOLwut?
You actually do work to remove comments?
That is quite cruel. I would expect if MS ever released something open source, that's what they would do
Offline
Ranguvar wrote:djszapi wrote:I don't use comments in those kernel drivers that we provide to our customers by the company, so I've got a sed script for it to remove all the comments in source files.
LOLwut?
You actually do work to remove comments?
That is quite cruel. I would expect if MS ever released something open source, that's what they would do
http://www.microsoft.com/presspass/feat … nuxqa.mspx
And I'm pretty sure they're commented, no way Linus would accept them if they weren't..
But we're getting off-topic now.
Offline