Choose, document, and use a style guide for provided code about c HOT 7 CLOSED

To get things rolling, how about the Linux kernel style but with a more reasonable indent (3 spaces instead of 8)?

In other words, something like this:

static int blah(int a)
   for (i = 0; i < num_elements; i++) {
      foo[i] = foo[i] + 42;

      if (foo[i] < 35) {
         printf ("Foo!");
         foo[i]--;
      } else {
         printf ("Bar!");
         foo[i]++;
      }
   }

   return a;
}

This is widely used, already documented, and can be auto-formatted using GNU indent on any reasonable OS with the following settings:

-nbad -bap -nbc -bbo -hnl -br -brs -c33 -cd33 -ncdb -ce -ci4 
-cli0 -d0 -di1 -nfc1 -i3 -nut -ip0 -l80 -lp -npcs -nprs -npsl -sai
-saf -saw -ncs -nsc -sob -nfca -cp33 -ss -il1

We could even integrate a formatting check into our CI build to help us maintain consistent style.

from c.

I don't think you'll ever get 100% agreement on any coding style, but that looks like a sane set of choices to me, and the autoformatting idea is great 👍

I think you have the wrong settings listed for indent though. As far as I can tell you need to remove -i8 and instead use -i3 -nut to get an indentation level of 3 without tabs.

from c.

Thanks @patricksjackson. I've updated my post above and will test this out once I'm on my development machine.

from c.

I agree that the ability to use a simple program like indent is key to enforcing a formatting standard. At least, it would immediately answer the question "is my code formatted correctly?" Something that I have often asked myself on other language tracks.

from c.

This should also include a preference for C99 features (#53)

from c.

This should also include a preference for fixed-width types (#52)

from c.

Once we update the contributing guide, we need to also document the odd #includes for the example solutions, (writing the code as if the files are named something else) see conversation in #50.

from c.