OSDev.org

Posted: **Mon Jun 27, 2011 3:52 am**

Love4Boobies wrote:As for the asterisk thing, the following might look a bit odd:
Code: Select all
int * a, * b, * c;

Yep. No comma operator.

Posted: **Tue Jun 28, 2011 5:25 am**

it drives me absolutely crazy when:

curly brackets don't have their own line

else {

Code: Select all

switch( c ) {

spaces are used as indentations

things inside parenthesis's are padded with spaces

Code: Select all

if ( a == *b )

Code: Select all

while( ( c = getchar() ) != EOF )

spaces are used between function names, statements, and parenthesis's without any consistency

here's a space

Code: Select all

if (

here's no space

Code: Select all

while(

why does sizeof get a space and not malloc?

Code: Select all

struct foo *bar = malloc(sizeof *foo);
size_t int_width = sizeof (int);

that last one was a more of a pet peeve, but I mean... really... what's with all the unnecessary whitespace that doesn't even really make it easier to read? and then not even enough whitespace that makes it MUCH easier to read for the curly brackets? spaces for indentations just makes a giant mess, and takes more space for your source code. it's not much, but with 1k lines of code and indentations everywhere, the space they use adds up. it could easily be an extra several kilobytes... that's nothing really... but doesn't it make you sick knowing that something is being wasted? or is our minds not in the maximum-perfectionist-efficiency state of minds? and if it's not, what are we doing trying to reinvent the wheel? and don't even claim not to be a perfectionist in the least, or you wouldn't even be bothering with a standard for code format. it's kind of a paradox from my point of view or more of an oxymoron.

I'd rather put 10 new lines between each of my functions than have 20 spaces for each indentation I need to make. clearly that's the biggest thing that drives me nuts with the way people format their code. for the love of ASM... stop using your space bar like it's an entire drum set...

Posted: **Tue Jun 28, 2011 5:41 am**

drew wrote:and then not even enough whitespace that makes it MUCH easier to read for the curly brackets?

If you use large enough identations (4 spaces and more), you can clearly separate blocks of code visually, and lines with an alone bracket start to feel like void, at least in my experience. Guess it's a matter of habits and opinion.

spaces for indentations just makes a giant mess

Care to be more precise ? In my experience, it's tabs which result in a mess when you open the source with an editor that has different tab size.

, and takes more space for your source code. it's not much, but with 1k lines of code and indentations everywhere, the space they use adds up. it could easily be an extra several kilobytes... that's nothing really... but doesn't it make you sick knowing that something is being wasted? or is our minds not in the maximum-perfectionist-efficiency state of minds?

Frankly, a few kilobytes are negligible nowadays. A single normally-sized picture takes much more space, yet many people love screenshots (me included).

and if it's not, what are we doing trying to reinvent the wheel? and don't even claim not to be a perfectionist in the least, or you wouldn't even be bothering with a standard for code format. it's kind of a paradox from my point of view or more of an oxymoron.

It's about making it easier to read code. The human mind has the ability to learn and perform things faster when it often encounters the same thing, included code that's formatted in the same way, it's sad not to use this possibility and make every piece of code look different and foreign to the reader.

I'd rather put 10 new lines between each of my functions than have 20 spaces for each indentation I need to make. clearly that's the biggest thing that drives me nuts with the way people format their code. for the love of ASM... stop using your space bar like it's an entire drum set...

You know, most people just set up their text editor so that TAB adds the right amount of spaces and stop to bother.

And although I agree that 20 spaces is too much, 4 or 8 clearly improve readability compared to 2. And force you to reduce conditional structure nesting in your code, which is a Very Good Thing...

Posted: **Tue Jun 28, 2011 8:40 am**

@ Fanael: Code style arguments have literally destroyed more than one otherwise perfectly good programmer team. Believe it or not, code style is important (as in, find a style and adhere to it, not as in, argue about it all day long).

All the arguments pro and con have long since be fielded elsewhere. There are no new arguments that could be fielded. It's all a matter of how much weight you put on which argument.

That's probably why we developers love argueing about it ad infinitum.

TAB vs. space...

TAB settings differ between editors. What looks well-aligned in one editor looks bad in another. Worse: Even with tabs, you need to agree on what width those TABs should be represented as on-screen, or you will get into whitespace edit wars.

One person uses 8-space TABs. In a struct, he uses one TAB to indent the type, and one TAB to have the struct members vertically aligned. "Looks good", he says.

Code: Select all

        int     foo;
        double  bar;

The next person, out of personal preference, uses 4-space TABs...

Code: Select all

    int foo;
    double  bar;

It is not immediately obvious that the source is correctly indented if using the correct TAB setting, or what that TAB setting should be.

Using a certain number of spaces solves these problems. Code looks identical regardless the TAB setting, the "correct" indent width is obvious from surrounding code - and it is very easy to make automated checks for violations of the "no TAB" rule.

Besides, we're talking a code style for the Wiki here. Try typing a TAB in the browser.

Posted: **Tue Jun 28, 2011 8:41 am**

berkus wrote:Since we stopped talking about the guide, and started talking about personal preferences, here's my take on parens:

There's no space after function names, e.g. main(
But there's space after reserved words, e.g. while (

Makes it easy to grep. Looks nice.

phpBB needs a 'like' or '+1' button. I'd upvote this.

Posted: **Tue Jun 28, 2011 9:25 am**

Solar wrote:@ Fanael: Code style arguments have literally destroyed more than one otherwise perfectly good programmer team. Believe it or not, code style is important (as in, find a style and adhere to it, not as in, argue about it all day long).

Believe me or not, I know this. It's just arguing about code style what is pointless and silly.

Posted: **Tue Jun 28, 2011 10:12 am**

Asking for discussion about a style guide probably isn't the smartest move, either...

Well, there you are. I've "been bold" and changed the "Request for Comment" into a Style Guide ("eat it or leave it"). I've used what's usually referred to as "ANSI style", as over the years I've found this meeting the least overall resistance from C/C++ coders. (You'll never get no resistance...) It's also the style I personally prefer, so flame away.

I've also cut away some of the stuff I feld was walking the line between "Wiki style guide" to "project style guide". We'd never see the end of it if we cross that line.

I won't beg Love4Boobie's pardon, and I won't ask for "comments" for the exact reason Fanael just pointed out.

Is there a good reason to not accept this as Wiki Style Guide?

Posted: **Tue Jun 28, 2011 10:17 am**

Solar wrote: Is there a good reason to not accept this as Wiki Style Guide?

I find this to be very similar to my own preferences and aside from a few small nitpicky things which I won't bring up, I'm perfectly happy with this style guide. I say we just move it out of Love4Boobies' user space and run with it.

Posted: **Tue Jun 28, 2011 12:14 pm**

Solar, you mean other than looking totally ugly?

But seriously, is it intentional that you have a space after if, but not after while? Usually I would suspect a typo there, but after such coding style discussions you're never certain...

Posted: **Tue Jun 28, 2011 12:30 pm**

Kevin wrote:...is it intentional that you have a space after if, but not after while?

I have no idea what you're talking about.

Posted: **Tue Jun 28, 2011 12:34 pm**

Oops, I meant switch, not while.

Posted: **Tue Jun 28, 2011 12:49 pm**

Ah. Hah. Hah.

Posted: **Tue Jun 28, 2011 3:44 pm**

No obvious flaws other than the g++-must-like-it command line that got typoed (and consequently fixed).

If we need a choice, this is probably as good as it gets. I plan on merging this to the manual of style, pending some more time for auditing.

Posted: **Wed Jun 29, 2011 2:57 am**

*Cough* 4 spaces can gtfo, tabs are better. If you want 4 space indenting, set your editor to display tabs as 4 space width. You can't do that with raw spaces. Tabs make everyone happy

</troll>

Edit: Tbh though I'm mainly being mischievous because I will probably never submit wholoesale code to the wiki. Most of my contributions have been theory so far, so yea lol :>

Posted: **Wed Jun 29, 2011 7:09 am**

Generally speaking, using hard tabs is problematic because it will misalign your code. Here's an example:

Code: Select all

for (p = list; p != NULL; p = p->next) <TAB> // hello,
<TAB> printf("%p ", p); <TABS> // world!

For the comments to be aligned:

<TABS> = 5 <TAB>'s, for hard tabs set to 4 spaces
<TABS> = 2 <TAB>'s, for hard tabs set to 8 spaces

Using hard tabs only on the left side isn't any better; when you work with a multi-column alignment, you're screwed again:

Code: Select all

if (a == b) <SPACES1> // hello,
<TAB> c = d; <SPACES2> // world!

In the above, the number of <SPACE>'s in <SPACE2> depends on both <TAB> and <SPACES1>, not just the latter.

The solution is to never use comments on the same line as code, but I see that as a limitation rather than an advantage.

OSDev.org

C coding style

Re: C coding style

Re: C coding style

Re: C coding style

Re: C coding style

Re: C coding style

Re: C coding style

Re: C coding style

Re: C coding style

Re: C coding style

Re: C coding style

Re: C coding style

Re: C coding style

Re: C coding style

Re: C coding style

Re: C coding style