What's your prefered program layout?

Some people do:

Code:

#include <stdio.h>

int main(void) { 
 printf("Hello, world,");
 if(1) {
  printf(" and goodbye.");
 }
}

but I do:

Code:

#include <stdio.h>

int main(void) 
{ 
 printf("Hello, world,");
 if(1) 
 {
   printf(" and goodbye.");
 }
}

I don't see why the hell they do the first one, because it is near impossible to keep track of the brackets. Are they stupid or do they have a reason?

Also, assembly can be used from within C[++] programs, and therefore we should have an assembly board. We need one.

Oh, this is my 500th post. I have no life.

I agree with you brian. To bad that both K & R and Stroustrup is doing it the wrong way.

Maybe it's a pre-ANSI whitespace thingy, and "old school" programmers haven't changed.

I personally like:

Code:

#include <stdio.h>
int main(void){printf("Hello, world,"); if(1){printf(" and goodbye.");}}

>Are they stupid or do they have a reason?
Well, since I use a variation of K&R I can safely say that there is a reason. Too much vertical white space makes a program look messy, and since code SHOULD be indented properly there's no need to line up brackets, just line up the indention.

Here's my preferred style

Code:

#include <stdio.h>
#include <stdlib.h>

int main ( void )
{
  printf ( "Hello world" );
  if ( 1 ) {
    printf ( ", and goodbye!\n" );
  }
  return EXIT_SUCCESS;
}

However, I prefer not to use braces in my if statements or loops if there is only one statement in the body. My functions have the starting and ending braces on their own line but everything else with braces has the opening brace one space after the statement and the closing brace on its own line.

I find the 'every brace on its own line' method better for people who are starting out to get a feel for the structure of programs, but eventually a style like that will feel more cumbersome than variations of K&R, which is why K&R tends to be more common among more experienced coders. An exception that I see is the indented braces:

Code:

#include <stdio.h>
#include <stdlib.h>

int main (void)
  {
  printf ("Hello world");
  if (1)
    {
    printf (", and goodbye\n");
    }
  return 0;
  }

For some reason I find this style very hard to follow, despite indention, but how you write your programs is a matter of personal preference unless your employer gives specific instructions on formatting.

-Prelude

#include <waga.h>

int main()
{

printf("Your mom");

return 0;
}

int message[]={0x40,0x08,0x1D,0x07,0x00,0x03,-0x4F,0x57,-0x08,0x03,-0x06,-0x08,-0x43,-0x17};
main(){int i,*j,*t;for(i-=(!i+i+!!i+~i+i),j=message;i<13;i+=-(i+~i)){t=j;++j;*j+=*t;putc(*j,stdout);};};

That's better

You spelt "mum" incorrectly.

hey govt, you kept my hello world

> hey govt, you kept my hello world

I found it on an old post this afternoon... Actually, I was thinking about it when I saw this thread

< points at Prelude's answer and agrees >

The indentation by itself should tell you the flow of the program - the braces only matter to the compiler, and it really doesn't care about indentation and {} placement.

To that extent, I prefer to place them where they have the least visual impact, because ultimately, they are only of use to the compiler, and (if your indentation is correct), they add nothing to program understanding.

You only have to look at all the badly posted code on this board to see this - sure all the {} are correct, but with it all indented to the left side of the screen, actually figuring out what the code does is a real challenge. The placement of the {} doesn't help at all, and you still have to format it to stand any real chance of understanding it.

And to save you getting in a mess, consider one of these approaches.
1. Get a syntax-aware editor which automatically includes and indents the }, each time you type a {.

2. At the very least, get an editor which does {} matching for you.

3. If you don't have 1., get into the habit of typing the } immediately after typing the {. Sure its a few extra cursor movements, but it beats trying to find out how many } you need after typing a page of nested code.

Oh, and K&R evolved when all code was written on 80*24 terminals, and it was a waste of screen space to have {} on lines by themselves.

A bad habit I have is ->

#include <stdio.h>

int main(void)
{
printf("Hello, world,");
if(1) {printf(" and goodbye.");}
}

For some unknown reason if I only have one command in between brackets I make it one line. With comments of course

Depends on where and what you started on.

I write in WIN32 and have long nested functions.
If I can I will leave out all the chicken lips I can.

Code:

if(!bMoreThanOneLine) DoThatVoodooYouDoSoWell(bThing);

I get legacy code or complex maths functions from others who started on punch cards. They tend to declare one letter variables to save time. Very hard to understand no matter the indentation.

Code:

   
   for (i=0; i<ne; i++)
   {
     (*(C+i)) = (double *) malloc (nn*sizeof(double));
     if ((*(C+i)) == NULL) return (OUT_OF_MEM);

     for (j=0; j<nn; j++) (*((*(C+i))+j)) = 0.0;
     for (j=0; j<ne; j++)
     {
        (*(*(C+j))) += s*sm;
	       (*((*(C+j))+ne)) += (s*y*sm);
	         s *= x;
     }

     for (j=1; j<ne; j++)
     {
         (*((*(C+ne-1))+j)) += s*sm;
	        s *= x;
     }
   }

I get legacy code or complex maths functions from others who started on punch cards. They tend to declare one letter variables to save time. Very hard to understand no matter the indentation.

Is it ever commented? Or do you get it excactly as you wrote it?

Thats it. As I got it.

That bit is only a part of the function to take a line on a greyscale image, convert to a start point, length and array of coef (so smaller to pass around network). Later to be 'reconstituted' and drawn to a screen or saved to file and compared to later captures. (we do digital video image processing inc OCR on moving objects)

No comments in punch cards, no comments ever. Thing is, I don't realy have to understand it until it goes wrong, I just don't like including things in my programs I don't understand, and trying to fix them later.