Depuis un quelque mois je me suis mis à coder en C. Voici quelques notes et références récoltées lors de ce début de parcours.
Trouver la motivation :
Sans motivation, il est difficile d’apprendre, je mets toujours plus de cœur à l’ouvrage, si j’ai un objectif en ligne de mire. Pour moi, cela a démarré avec les cartes Arduino. Elles permettent de faire beaucoup de chose, mais on peut vite être limité lorsque l’on ai pas à l’aise avec le C. Le C est donc devenu une solution pour mes projets.
Trouver le bon media pour apprendre :
Il existe des dizaines de moyen d’apprendre un langage informatique, mais le plus souvent un seul cours vous convient le mieux. Pour moi ce fut le livre « Apprenez à programmer en C » par Mathieu Nebra aux éditions Openclassrooms. Cerise sur le gâteau le bouquin est disponible en ligne ici : /courses/apprenez-a-programmer-en-c
Personnellement je préfère le papier parce qu’il me permet une meilleure lecture et donc une meilleure mémorisation. Certains aspects du livre sont un peu datés, notamment dans le choix des librairies pour les exercices (SDL au lieu de la SDL2) mais ce n’est pas très grave, il m’a permis de faire rentrer les bonnes informations dans les bonnes cases de mon cerveau.
Un outil pour programmer :
Le livre suggère CODE::BLOCK pour coder et compiler ses programmes. Mais comme il avait tendance à planter sur ma Debian Testing et que je n’ai pas trouvé de mode nuit, j’ai opté pour la combinaison Gnome-builder et GCC.
Gnome-builder est un IDE jeune qui progresse rapidement, mais comme je n’en ai pas testé beaucoup d’autre, mon avis reste partiel.
Compiler :
J’ai choisi GCC, avant de connaître « clang », un compilateur doit avant tout être un bon compagnon pour coder et pas seulement un bon organisateur de 0 et de 1. Il doit vous guider et vous aiguiller, c’est le cas de gcc surtout quand on active les bonnes options de compilation. Il est là pour vous aider, et il faut juste savoir l’écouter et en tenir compte.
Voici un exemple avec une erreur:
#include <stdlib.h>#include <stdio.h>int main(int argc, char *argv[]){int i = 0;for (i=1; i <= 10; i++){printf("%d\n",);}printf("Je sais compter juqu'a %d\n",i-1);}
Lorsque je le compile :
gcc test.c -o test
j’obtiens :
test.c: In function ‘main’:
test.c:7:23: error: expected expression before ‘)’ token
printf("%d\n",);
^
gcc me fournit une indication claire sur le fait qu’il manque un argument à la ligne 10 pour renseigner %d : printf(« %d\n », i );
(A noter que
GCC 6
et le futur
GCC7
détaille encore plus. )
Personnellement, je force aussi le standard et j’ajoute les options -Wall -Wextra:
gcc -std=c11 -Wall -Wextra test.c -o test
Cela permet d’avoir des recommandations en plus qui demandent un peu plus de temps au début, mais après on est gagnant, notamment lors du débogage ou des évolutions du programme.
Pour les logiciels avec plusieurs fichiers C je vous conseille aussi d’utiliser l’outil MAKE pour faciliter la compilation et le déploiement. Voir le tutoriel de Emmanuel Delahaye ici .
Les commentaires :
Je vous conseille de lire les bonnes pratique de codage C du même auteur: ici
Notamment le passage sur les commentaires :
Comment bien commenter :
Le moins possible !
Le principe est de ne commenter que ce qui apporte un supplément d’information. Il est d’usage d’utiliser en priorité l’auto-documentation, c’est à dire un choix judicieux des identificateurs qui fait que le code se lit ‘comme un livre’…
Changement multiple dans le code :
Il arrive souvent de se tromper quand l’on code. Surtout au début, on imagine une fonction, on la colle un peu partout, mais il lui manque un argument, il faut changer son nom ou simplement la placer à un endroit plus judicieux.
Trouver :
Pour trouver un élément dans plusieurs fichiers j’utilise grep :
grep -R -n -i "monmotif" *.c
-R fait une recherche dans tous les dossiers, -n affiche le numéro de la ligne, -i permet de chercher un motif sans tenir compte de la casse contrairement à -e et *.c précise le type de fichier
grep -R -n -e "PREF_FILE" *
inc/const.h:25:#define PREF_FILE "preferences.ini" src/settings.c:36: prefFile = fopen(PREF_FILE, "r"); src/settings.c:53: fprintf(stderr, "Error opening %s: %s\n", PREF_FILE, strerror(errno)); src/settings.c:65: prefFile = fopen(PREF_FILE, "r");
Remplacer :
C’est plus dangereux mais cela permet de changer rapidement le nom d’une variable ou d’une fonction dont le nom ne paraît plus très judicieux.
sed -i 's/ancienNom/nouveauNom/g' main.c
On peut faire un test avant de lancer le changement pour être sûr de son coup :
grep -n - e "ancienNom" main.c | sed -i 's/ancienNom/nouveauNom/g'
Perso, je le fais que sur un fichier à la fois, je préfère assurer l’opération avant de le regretter. A noter qu’un fonction de rechercher/remplacer va arriver bientôt dans Gnome Builder : ici .
Trouver l’information :
La plupart des fonctions possèdent une entrée dans le man. Elle indique comment l’utiliser et où la trouver :
man SDL_BlitSurface
La commande affiche notamment dans quel header on peut la trouver et quel argument elle attend.
SYNOPSIS #include "SDL.h" int SDL_BlitSurface(SDL_Surface *src, SDL_Rect *srcrect, SDL_Surface *dst, SDL_Rect *dstrect);
On peut utiliser l’application apt-file pour Debian et ses dérivés pour trouver la lib nécessaire:
libsdl1.2-dev: /usr/include/SDL/SDL.h libsdl2-dev: /usr/include/SDL2/SDL.h
Dans mon cas je choisirais d’installer la libsdl2-dev pour pouvoir travailler avec SDL2 et j’indique #include <SDL2/SDL.h> dans mes fichiers pour préciser où la trouver.
Le man n’est pas tout et parfois pas toujours explicite, pensez à fouiller le web, il y a toujours quelqu’un qui a écrit la réponse quelque part.
Sauvegarder et partager son code :
Tout projet où l’on passe du temps mérite une sauvegarde régulière. Personnellement j’ai choisi de passer par la plate-forme github, mais il existe plein d’autre moyen. Github demande de se familiariser avec git, mais on trouve beaucoup d’aide sur Internet pour arriver à ses fins.
- https://git-scm.com/book/fr/v2
- https://www.grafikart.fr/formations/git/
- …
Conclusions :
Coder en C est faisable même pour un non informaticien, il faut prendre le temps de se documenter, la solution se trouve toujours entre votre chaise et votre clavier. Et si une question n’a pas de réponse, il faut juste reformuler la question.
À noter que la compréhension de l’anglais est indispensable, mais c’est comme coder, avec un peu de temps, de la motivation et un bon manuel, on apprend vite 🙂
