Another style/readability question...

[jackassplus]

If you have lots of variables:
char card_data[100]
[10];
char file_data[100][15];
double file_time[100] = {0};
double temp_time[100] = {0};
int j = 0;
int search_index;
char *ps;
char buf[BUFSIZE];
char *pattern[] = {
"[0-9]{10}\
\&",
"[A-Z]{2}[0-9]{3}[A-Z]{3}[0][0-9]{4}\\<",
"[0-9]\\.[0-9][0-9]\
\<",
"\\>Y\
\<"
};
regex_t re, re1, re2, re3;

Is there any rule/convention for declaring them? Should the chars be
together, ints together, etc?

 

[Eric Sosman]

If you have lots of variables:
char card_data[100]
[10];
char file_data[100][15];
double file_time[100] = {0};
double temp_time[100] = {0};
int j = 0;
int search_index;
char *ps;
char buf[BUFSIZE];
char *pattern[] = {
"[0-9]{10}\
\&",
"[A-Z]{2}[0-9]{3}[A-Z]{3}[0][0-9]{4}\\<",
"[0-9]\\.[0-9][0-9]\
\<",
"\\>Y\
\<"
};
regex_t re, re1, re2, re3;

Is there any rule/convention for declaring them? Should the chars be
together, ints together, etc?

They should be defined exactly as you have illustrated,
which ensures they won't compile. That prevents them from
spoiling anyone's view. ;-)

Group "functionally related" variables together. There
may be more than one logical grouping; pick whichever seems to
make the most sense.

If you have "lots" of variables, it may be that your
function is trying to do too much and would be better off
being split into multiple functions. "May be," not "is."

 

[jackassplus]

   They should be defined exactly as you have illustrated,

which ensures they won't compile.  That prevents them from
spoiling anyone's view.  ;-)

Google groups editor does some horrible things with tabs, newlines,
and such

If you have "lots" of variables, it may be that your
function is trying to do too much and would be better off
being split into multiple functions. "May be," not "is."

There is magic there. I haven't yet the experience to know when this
is occurring. All in due time...

 

[Nick Keighley]

There is magic there. I haven't yet the experience to know when this
is occurring. All in due time...

try writing a short discription of what the function does as viewed
from the outside. Give enough information so that a caller could use
your function only being able to see the prototype and your
description.

"loads cards and file information from the specified streams. Performs
validation and time-checking. Then parses the file data according to a
fixed regexp."

Everytime you start a new sentence or use a conjuction ("slurp file
data AND perform a twisty function AND resublimate the thiotoluene")
that implies your function is doing too much and should be broken up.

This is a rule-of-thumb and not an absolute rule. Also worry if you've
got more that 5 or 6 parameters or more than a couple of pages of code
or your 'if' nesting has made an 80 column layout unbearable.

K&R is full of small powerful functions. read it as a guide to good
design.