Programming practices

From Applied Science

Some recommendations and small programming techniques are employed in the introduction. They are small details that do not determine whether you pass or fail, but are useful for learning purposes anyway.


Comments

  • All teachers recommend that you comment your programs, both because that counts for grading of the programming exercises, as well as because that makes your code more accessible for other people, or even yourself after a long time without reading your own code. Feel free to place comments before, after or sideways of blocks of code. The standardized format is /* ... */ (slash followed by an asterisk). If you want to you can use // (double slash format). Depending on the teacher, the standard format /* ... */ must be used. The difference between one and the other is related to the successive revisions of the C language specifications.

/* Receives an integer n and prints all its possible divisors between 1 and 10 */

void divisor (int n) {

for (i = 1; i <= 10; i++) if (n % i == 0) printf("%d is divisible by %d", n, i);

}


  • There is not need to explain the 'for' loop. Say that the counter begins with 1, explain the conditional, the count steps and the modulo operations. Just write in the comments what comes in and what comes out, what the function does. It's even worse to explain what the function doesn't do or misses depending on the case. The algorithms studied in an introduction are deterministic, either do or don't do something. The computer doesn't hesitate, doesn't ponder, doesn't ask questions.. To write "should print", "will print" or "is going to print" doesn't make sense if the algorithm either prints or not.

    PS: this is valid for imperative programming, but the concept of programming paradigm is not studied in this course. At best the teacher might say what it is and show some example of how things are in different paradigms.


Indentation

  • To indent is nothing more than placing blank spaces in your source code. Practically speaking, to indent has the same function of organizing a text in paragraphs. There are different styles of indentation, but unless your teacher is extremely strict, there is no rule to use one style or another. With or without indentation your program executes the same way.

int a = 2; int b = 3; int c; c = a + b;

It's not recommended to place many commands in the same line, it becomes harder to read.



if (variable == 10) {

/* do something */

if (number != 0) printf("etc");
else printf("...");

}

Curly brackets can be placed in any fashion you want to. If you want to you can place the opening bracket below the expression in the parenthesis. The blank space to the left can be a TAB or simple white spaces, that is used to indicate that that command is inside a block.


/* this function does something */

int func (int var, float var, ...) {

int local, local2,
local3, local4, local5, local6;

for (c = 0; c < x; c++) {

if (d == var) var2++;
else if (b == var2) break;

else {

counter--;
a = 0;

}

}

}

Comments written above the function are easier to read than comments written in the middle, polluting the code. If many vars are declared with the same type, it's a good idea to break the declaration in multiple, shorter, lines. Skip lines between an 'if' and an 'else' also helps to read. To obey to a vertical alignment is also good.


if      (d == var)  var2++;
else if (b == var2) break;
else                counter--;

This is another option, provided that the same pattern is always followed, without mixing it with different patterns, such as placing the comment below the conditional and in the next, to the right. Try to match the comparison expressions with the operator's precedence to avoid any confusion.


Variable's names

  • Use mnemonic names. That is, names that make sense and are easy to memorize. Avoid acronyms and codes such as "XYS123" or "IV (Integer Variable). Give preference to simple nouns, verbs, adjectives, etc. If you need to, use prefixes or suffixes. Omit prepositions. For example: entry_code, maximum_point, etc. For accessibility and simplification reasons you might prefer "uni_cod" instead of "university_code", or "uni_c". Another idea is to use acronyms, but placing a list of all full names at the beginning of your program to avoid confusion.


Clarity

  • Make your program readable, either trough proper comments usage and/or proper indentation. As a general rule, avoid excessively complicated operations. Very often the solution neither needs to be complicated nor it should be, because it'd perform worse. Excessively complicated operations are a good sign that there is an error in your program and that you are not being able to identify it. Or, some command or concept has not been properly understood and your are employing some incorrect method to solve the problem.


Check for user inputted data

  • Restrict the data input. To prevent the user from, whether intentionally or not, inputting invalid data, place some extra commands, such as 'IF' or loop blocks. The user inputs some value, if a check accuses that the value is invalid, warn the user or simply terminate the program. That is done to avoid doing calculations with incorrect/invalid values, such as characters in place of numbers. It's a programming technique, it makes more sense to avoid a incorrect input than to check if the input is invalid in the middle of some operation.