I have been dealing with programming for several years now (I am still a student but with a lot of internships). Mostly working with C++, Python and MATLAB, I noticed that whenever I download an SDK or a library from Internet/GitHub and look inside, the code is much more complex than mine, using error catches everywhere and other things that would never come to my mind while writing my own code. My question is, how can I learn or practice this kind of things? From my experience, no programming course talked about coding style, when and how to use try/catch efficiently, how to debug faster etc… I am also not thinking about using mutex while accessing one variable from different functions at the same time because my code is simply working without them and I didn’t face any problem until now.
Currently I am working on a project using Python and Pycharm is helping me a lot keeping a correct coding style but it is limited to the syntax and naming conventions.
4
Well as soon as you write up some code and get it working, ask for a review on Code Review.SE. That’s almost exactly what the site is for!
Plenty of people over there would be more than happy to get more rep help you write clean code.
Considering the error catches: do lots and lots of debugging, your own applications but also others. And also, let your programs be used by other people. They will do things in ways you never imagined.
If you only use your own code you will follow the pre-programmed path in your head and everything will go right.
The most reliable way to get better is to practice. Not just do things, but strategically work at the border of your capabilities and then reflect on what works, what doesn’t, and why.
1
A general rule of thumb when using some external library (which you always do in application programming, at least using the standard C library in C) is to check for failure of most functions you are calling.
A typical simple example is stdio(3) and <stdlib.h> functions. You certainly should always check when using fopen(3) (or popen(3)) and malloc(3). So don’t code
/// BAD SINCE NO CHECKS
FILE* fil = fopen("outfile.txt", "w");
fprintf (fil, "something, e.g. one is %dn", 1);
But at the very least:
FILE* fil = fopen("outfile.txt", "w");
if (!fil) { perror("fopen outfile.txt"); exit(EXIT_FAILURE); };
fprintf (fil, "something, e.g. one is %dn", 1);
and likewise coding simply
/// BAD SINCE NO CHECKS
struct somestruct_st *ptr = malloc(sizeof(struct somestruct_st));
ptr->somefield = 2;
is wrong, you should at least:
struct somestruct_st *ptr = malloc(sizeof(struct somestruct_st));
if (!ptr) { perror("malloc somestruct_st"); exit(EXIT_FAILURE); };
ptr->somefield = 2;
There are some functions which you could test but you often don’t. A typical example is fclose(3). If you are very careful you should test it, but I usually don’t.
Notice that testing corner cases failures (like above) may be hard. On Linux, lowering disk quotas and limits (with setrlimit(2) …) may help, since you could almost force some of these failures.
Notice that server software (which runs many days) should take more care about detecting and reporting error than a simple commandline tool.
For critical embedded software (like your heart pacemaker, your airline aircraft) checking all cases is essential. static program analysis may help (but is not a silver bullet).
Also, study the source code of (and contribute to) existing free software. It will teach you a lot. And learn several programming languages (certainly Ocaml or Haskell, Scheme or CommonLisp will teach you a lot!).
Take also time to read the documentation of the functions or libraries that you are using.