======Programming PRO-Tips======
A collection of common sense practices to maximize success, minimize error, and boost productivity.

=====PROTIP: always initialize your variables=====
In  most cases, set to 0.

If a pointer, set to NULL.

Unless there is some preferred starting value based on the context of the program being written.

Even if the language auto-initializes its variables to 0, I find it very helpful from a documentation point of view.

=====PROTIP: ALWAYS add newlines after your debugging statements=====

I tend to also identify what I am debugging in the message as well:

<code c>
    fprintf(stderr, "highlights: %d\n", highlights);
</code>

and use **stderr**, so I can redirect away stuff in a flash. All so I don't accidentally mistake my debug output as errant program output.

For programs with naturally verbose output, I will also prepend a "[debug]" heading:

<code c>
    fprintf(stderr, "[debug] highlights: %d\n", highlights);
</code>

=====PROTIP: always use descriptive variable names=====
Oversight is one of the biggest sources of error in programming.

Naming your variables "i", "x", "a", or similarly non-descript names does not help in your program's readability.

Instead, go for contextually relevant things that pertain to the problem you are solving:

  * instead of 'i' and 'j' for loop variables, use "index" or "index2" (or "inner" and "outer", "row" and "col[umn]")
  * instead of 'x' to store an accumulation or count, perhaps "tally", "sum", or "count"

If **I** had a nickel for everytime a student asked //me// to explain **THEIR** code, I would be rich.

=====PROTIP: comment as you go=====
Much like handwriting out your notes, it doesn't SEEM valuable, except you are exposing your brain and lending focus to important concepts making up your solution.

Plus, you will start to problem solve better, simply from the added exposure (when it is fresh in your mind, and not some discouraging "bah! Have to go back and comment so I do not lose points" mindset).