Techniques et astuces de programmation pour débutants et "confirmés", Partagez ici vos techniques et astuces pour mieux programmer

[macuserfr]

Bonjour à tous,

Nous voyons souvent sur ce forum des sujets demandant comment débuter en programmation, ou quel langage pour débuter. Ici je voudrais traiter d'un sujet connexe mais peu (pour ne pas dire pas) abordé: les méthodes et bonnes pratiques de programmation, indépendamment du langage.

Connaître un (voire plusieurs) langages de programmation est certes important pour programmer. Mais en dehors de sa syntaxe et grammaire, il y a plein de choses qui viennent en amont et qui permettent de coder plus vite ou plus efficacement. Certains points seront bien sûr sujets à de controverses, donc je demande par avance aux représentants des divers courants de pensée en conflit de présenter leurs arguments SANS rentrer dans des débats sans fin. Vous l'aurez compris, je demande votre participation pour enrichir ce fil, car je ne prétend pas avoir la science infuse ni tous les bons conseils à donner.

Ceci étant dit, voici un liste non exhaustive pour commencer:

• Réfléchir au problème et le modéliser avant de coder. Je citerai encore un de mes profs: "Le plus tôt vous commencez à coder, le plus tard vous finirez". Quand vous avez un nouveau programme à résoudre, commencez par le découper en boites gérant une partie de votre code de la façon la plus autonome des autres. Déroulez votre programme à la main sur une feuille de papier en pensant à tous les cas de figure qui peuvent se produire. Il n'y a qu'une fois que vous avez ce squelette clair dans votre tête que vous pouvez commencer à le coder.

• Nommez de façon propre vos variables et vos fonctions. D'une part, il faut que le nom soit en rapport avec ce que fait la variable/fonction (évitez var1, var2, toto, titi, tmp). D'autre part, prenez une convention de nom et tenez-vous y. Certain langages imposent une convention genre maFonction, MaClasse. D'autres ce sera ma_variable. Pour ceux qui n'en imposent pas, choisissez-en une.

• Des commentaires utiles! Inutile de raconter un roman pour décrire une fonction. Pour un commentaire de fonction dites en 2 lignes maximum ce qu'elle fait (si ça tient pas sur 2 lignes, c'est que votre fonction est trop compliquée et qu'il faut la découper pour faire plus simple) puis dire ce qu'on attent en arguments et quelle est la valeur de retour, en explicitant les valeurs particulières genre: "retourne la valeur de A, ou null en cas d'erreur"

Pour des commentaires de code, ne paraphrasez pas le code, c'est inutile, ça fait perdre du temps et à vous et au lecteur! Dites plutôt ce que vous voulez en faire:

Code

//Commentaire inutile: si a égal b ou b égal c
if(a == b || c==b)

Code

//Commentaire utile: si b appartient à l'ensemble
if(a == b || c==b)

Vous n'avez pas besoin de tout commenter, je dirait que commenter les fonctions et les passages difficiles c'est suffisant si le code a été bien découpé en fonctions.

• Avoir des notions d'algorithmique pour optimiser ses programmes

• Faire des test unitaires

• Indenter proprement son code

[noop]

Je me lance:

La documentation des programmes: pour moi la documentation externe d'un programme est 99% du temps inutile. Mieux vaut des commentaires pertinents dans les sources plutot qu'un document qui ne sera jamais remis a jour lors de l'évolution des sources. Pour le 1% restant, une documentation sur des points complexes est nécessaire

Concernant le langage C:
- éviter de mettre plusieurs instructions sur une seule ligne.
- utiliser les accolades dans les instructions if, do while, while etc.... Combien de fois j'ai vu une correction rapide devenir un vrai cauchemar a cause de celà

Code

// avant modif
if (...)
     instruction;

Code

// après modif
if (...)
     instruction;
     instruction_ajoutée_en_pensant_quelle_sera_exécutée_dans_le_then_implicite;

Code

// préférable !!!
if (...) {
     instruction;
}

Gestion de la mémoire: se fixer une règle et une seule pour les fonctions utilisateurs (pour les fonction système appliquer les règles des déveloper guides)
- l'appelant est propriétaire de la mémoire
- ne jamais faire confiance à l'appelant

Allocation mémoire: A moins d'écrire des programmes pour la fusée Ariane, il est inutile de tester si la zone allouée est nulle. Exemple:

Code

char * maChaine = (char *) malloc(sizeof(char) 10);
if (maChaine == NULL) {
   // ce test est inutile
}

Si le système n'est pas capable de vous allouer 10 caractères, le code qui va être exécuter dans le test va nécessiter lui aussi de la mémoire et peut être même plus que 10 caractères.....il va donc aussi planter. Un système auquel il manque 10 c est à genoux et va planter dans peu de temps.

Gestion des erreurs: La gestion des erreurs et des logs DOIT être mise en place au tout début d'un projet. J'ai trop souvent vu des programmes qui font du printf() ou du System.out.println(). Quand il faut tout réécrire ca plombe tout.

[Vin's]

Lors d'une condition d'égalité avec une constante, mettre la constante à gauche, comme ça si par mégarde on oublie un égal le compilo nous sort une erreur.

ex :

Code

if (MA_CONTANTE == a)

au lieu de :

Code

if (a == MA_CONTANTE)

Dans le cas de gcc, quelque chose comme "if (a = 3) ..." donne un avertissement lorsque -Wall est utilisé :

warning: suggest parentheses around assignment used as truth value

Donc personnellement, je préfère mettre la constante à droite.