Borrowed, modified from Keith Trnka by Sara Sprenkle
This style guide may not cover all programming best practices, but I'll keep it up to date with what you need to get full credit for your programming style.
A program should work the way it's intended to, but simple working
is not enough to be considered really good code. The following are
goals of good programming:
| Variables | |
|---|---|
| Good | Bad |
|
distance velocity acceleration |
d ve A b c |
| Functions | |
| Good | Bad |
|
drawPicture squareRoot computePrice |
computeImage (less clear for this case) sqrt total |
meters)
YARDS_PER_METER)
computeDistance)
rowsInFile
rows_in_file
int main(void)
{
printf("Hello\n");
printf("Hello again\n");
return 0;
}
This is an example of bad indentation:
int main(void)
{
printf("Hello\n");
printf("Hello again\n");
return 0;
}
There are a few styles of placing curly braces { } in code. I've listed three styles below, but there are probably others; just make sure you stick with one.
int main(void)
{
printf("Hello\n");
printf("Hello again\n");
return 0;
}
int main(void) {
printf("Hello\n");
printf("Hello again\n");
return 0;
}
int main(void)
{
printf("Hello\n");
printf("Hello again\n");
return 0;
}
x = x0 + v0 * t + .5 * a * pow(t, 2);
| Good |
x=x0+v0*t+.5*a*pow(t, 2);
| Bad - tough to read |
/*
Sara Sprenkle (sprenks@udel.edu) 02/07/05
CISC105 Section 018
Lab02 lab02a.c
This program reads velocities, times, and accelerations from DISTANCE.DAT
and writes out a table of information to DISTANCE.OUT.
*/
int main(void) {
/* shows "Hello" on the screen */
printf("Hello\n");
/* shows "Hello again" on the screen */
printf("Hello again\n");
/* exits the program normally */
return 0;
}
Alternatively, comments may be placed on the same line if they are aligned horizontally, like this:
int main(void) {
printf("Hello\n"); /* shows "Hello" on the screen */
printf("Hello again\n"); /* shows "Hello again" on the screen */
return 0; /* exits the program normally */
}
/* Initialize balance */
balance = 0;
/* Initialize server address */
memset(&server_address, 0, sizeof(server_address));
server_address.sin_family = AF_INET;
server_address.sin_addr.s_addr = htonl(INADDR_ANY);
server_address.sin_port = htons(SERVER_TCP_PORT);
/* Open the listening socket */
if ((sock_server = socket(AF_INET, SOCK_STREAM, 0)) < 0)
{
perror("Server: Couldn't open listening socket");
exit(1);
}
...
printFirstRow(initialVelocity, time, acceleration, computeDistance(initialVelocity, time, acceleration))
...
It should be clear what this code does, even though you don't have
the code for the functions printFirstRow and
computeDistance.
Now look at another way to write it:
...
distance = initialVelocity * time + .5 * acceleration * pow(time, 2);
printf("%10d%10d%10d%10.1lf", initialVelocity, time, acceleration, distance);
...
Coincidentally, this method of programming helps both debugging and
extensibility. To see how, we need to look at a larger portion of each
program. I've used to comment /* read from file */ as a
placeholder for scanf statements.
| Using your own functions | Without your own functions |
|---|---|
...
|
...
|
Now, suppose that I tell you that your columns are incorrect. Maybe each column should be 15 characters wide instead of 10 characters wide. If you use your own functions, all you need to do is fix those functions. If you did the other way, now you must change every line. This demonstrates how functions can lead to extensible programs. But it's also important for debugging: without functions, you might forget to fix one row or make one typo, but with functions as shown above, you can't make those mistakes.
Here's some code with a long line:
double meters1, meters2, meters3, meters4, kilometers1, kilometers2, kilometers3, kilometers4, yards1, yards2, yards3, yards4;
You can group things together so that they fit within length of the screen:
double meters1, meters2, meters3, meters4;
double kilometers1, kilometers2, kilometers3, kilometers4;
double yards1, yards2, yards3, yards4;
Sometimes you might do this with a printf too:
printf("My %d buttons were exploring the Amazon when they discovered that they couldn't eat %d chickens.",
buttons, chickens);
You can also comment too much. If you find that you place a comment along with every line of code, you're probably commenting too much. Think about it like this: if you showed your code to someone in the class who doesn't really know you, you should only have comments on the things that they'll have trouble figuring out.
acceleration =
10. Have your program output the results using printf to the
terminal. As a second step, output to a file instead of to the
screen. As a third step, read values from a file instead of
hard-coding them.
Another way to approach this is to write functions that do the different parts of your program. Test each function separately before putting it all together.