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

[Jaypee]

Bravo. C'est un très beau sujet.

Il faut noter que certains environnements pour le développement en Java apportent de nombreux outils allant dans ce sens.
Ayant plus d' expérience Java que C++, j' apporterai volontiers ma contribution. Il y a des pratiques qui commencent à se généraliser dans les différents langages à objets et il sera intéressant de faire des parallèles.

Il y a aussi les bibilothèques tellement utiles qu'elles devraient exister dans tous les langages. On pourrait faire l'état des lieu.
(gestion des "logs" par exemple)

à suivre,
J-P

[Hellstorm]

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)

Ce message a été modifié par Hellstorm - 27 Jul 2009, 08:30.

[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.

[Hellstorm]

Tiens au niveau des acolades je suis tout à fait d'accord avec toi noop, mais pas sur leur placement, personellement je trouve le code beaucoup plus lisible lorsque les acolades sont alignées :

Code

if (...)
{
   instructions;
}

Bon après ce n'est que mon avis.

[macuserfr]

J'suis plutôt pour les accolades alignées selon l'exemple de Hellstorm, à moins d'avoir une contrainte de place (genre petit script php dans du code HTML que tu veux pas faire occuper toute la page), ou sinon passer à Python et plus avoir d'accolades du tout (je ne l'ai personnellement pas fait, mais il paraît que c'est un bonheur.)

[noop]

Déclaration des blocs en C/C++: Effectivement j'écris les blocs de la manière suivante:

Code

if (...) {
   ...
} else {
   ...
}

En fait je ne fais que suivre ce qui était fait dans la norme C99. Mais je peux me tromper.

[macuserfr]

Je dirais que plus important qu'utiliser une forme ou l'autre, c'est d'utiliser toujours la même forme, pour avoir un code cohérent et lisible.

[Sedutom]

Ce n'est pas une obligation mais je préfère quand toutes les déclarations de variables sont regroupées au début du programme (dans certains langages c'est même obligatoire). Comme il l'est dit plus haut, le nom des variables doit être clair et si possible commentés (au moins par groupe) :

Code

//Vitesses des ondes de volume
double vitesseP;
double vitesseS;
//Fichiers
FILE *fichierIn;
FILE *fichierOut;

Lors de la lecture du code on pourra alors avoir la liste des variables facilement accessible. De plus, le code est plus lisible quand on sait quelle est l'utilité d'une variable.
Cela diminue aussi le risque d'oublier de déclarer une variable.

[bad_duck]

Je ne sais plus d'où ça sort (un mec de chez IBM à l'époque je crois) :

" Si on ne peut pas comprendre l'utilité d'un programme en lisant uniquement les commentaires, alors vous pouvez jeter l'ensemble du code ! "

[Jaypee]

La règle des accolades doit être fixée collectivement, l'une ou l'autre est correcte, ensuite il faut avoir moyen d'automatiquement formatter le source selon cette règle. Avec Eclipse, il y a un réglage pour le choisir et le raccourci c'est ctrl-alt-F

Mais idéalement tous les sources dans (CVS, SVN...) doivent avoir la même présentation. Dans le même ordre de choses, il faut voir s'il faut ajouter une entête avec copyright.

J-P

Ce message a été modifié par Jaypee - 27 Jul 2009, 13:14.

[noop]

Un petit guide pour tout langage qui s'apparente au langage C ou qui utilise le C:

Guide Superflu de programmation en langage C

Ce message a été modifié par noop - 27 Jul 2009, 13:50.

[Hellstorm]

Pour ce qui est des conventions de nommage, je trouve la notation hongroise pratique (toujours en C/C++)

[macuserfr]

12 réponses et 140 lectures pour un post qui a environ 24h, c'est pas mal tout ça

@noop -> Pas mal le PDF de ton lien

[Jaypee]

En C/C++, mettre les #define tout en majuscules et parenthéser sans parcimonie

L'exemple de Feuer dans le "C Puzzle book"est la macro :
#define NEG(x) -x

Si x est négatif, selon le compilateur, cela donne vraiment la valeur absolue ou bien --x.

Donc la bonne pratique est :
#define NEG(x) -(x)

J-P

[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.

[chombier]

En C/C++, mettre les #define tout en majuscules et parenthéser sans parcimonie

Je dirais même plus, en C++, éviter à tout prix les macros #define et les remplacer par des fonctions inline.

[edit]
une illustration de mon propos:
http://www.parashift.com/c++-faq-lite/inli...ns.html#faq-9.5
[/edit]

Ce message a été modifié par chombier - 27 Jul 2009, 14:56.

[Phil J. Fry]

• Indenter proprement son code

En Python, il est utile de mettre des commentaires de dédentation :

Code

....
for i ... :
    for j ... :
        ....
        ....
    # end for j
    ....
    ....
#end for i
....

[Hellstorm]

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.

Ahh j'avais jamais vu que gcc pouvait emettre un warnng pour ça, merci Vin's

[mpergand]

Code

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

Tiens au niveau des acolades je suis tout à fait d'accord avec toi noop, mais pas sur leur placement, personellement je trouve le code beaucoup plus lisible lorsque les acolades sont alignées :

Code

if (...)
{
   instructions;
}

Bon après ce n'est que mon avis.

Les gouts et les couleurs ...

Extrait de Guide du développement logiciel par Timothée Royer

Présentation des accolades
Une paire d’accolades délimite un élément de structure.
*** IMPÉRATIF ***
Une accolade fermante se trouve toujours à la verticale de l’accolade ouvrante correspondante.
(Exemple) A ne pas faire :

Code

int main(void)
{
    cout << "Les codes ASCII :" << endl;
    int col;
    for(int ligne = 0; ligne < 32; ligne++) {
        for(col = 0; col < 7; col++) {
            cout << (col*7+ligne) << ' '
                << char(col*7+ligne) << '\t';
        }
        cout << endl;
    }
}

Cette disposition permet de gagner deux lignes de code source. Elle fait cependant moins ressortir la structure logique du code. Elle n'est donc pas souhaitable. Le code source doit plutôt être présenté comme ceci :

Code

int main(void)
{
    cout << "Les codes ASCII :" << endl;
    int col;
    for(int ligne = 0; ligne < 32; ligne++)
    {
        for(col = 0; col < 7; col++)
        {
            cout << (col*7+ligne) << ' '
                 << char(col*7+ligne) << '\t';
        }
        cout << endl;
    }
}

En fait, dans la suite du doc, il utilise la même disposition que celle que j'utilise depuis plus de 20 ans, celle-ci:

Code

int main(void)
    {
    cout << "Les codes ASCII :" << endl;
    int col;
    for(int ligne = 0; ligne < 32; ligne++)
        {
        for(col = 0; col < 7; col++)
            {
            cout << (col*7+ligne) << ' '
                << char(col*7+ligne) << '\t';
            }
        cout << endl;
        }
    }

Cette disposition est pour moi la seule logique, car je ne trouve aucunes raisons pour que les accolades ne soient pas aux même niveau que les instructions qu'elles délimitent.


Ce message a été modifié par mpergand - 27 Jul 2009, 22:08.

[noop]

je propose d'ouvrir un sujet identique sur les "bonnes pratiques quant au placement des accolades"

[chombier]

Les gouts et les couleurs ...

Toutafé... ceci est une histoire de goût et n'a absolument rien à voir avec la programmation. Il y a eu une tentative de conciliation de l'indentation avec Python, mais même là, on trouve encore des râleurs qui hurlent contre l'indentateur ( ) à 2 colonnes, alors qu'ils en utilisent 4. Les ayatollah de l'indentation ont encore de beaux jours devant eux.
Plus simplement: chacun voit midi à sa porte, et ça risque de durer longtemps, et le compilateur s'en tape.

[macuserfr]

Bon, si tout le monde est d'accord pour dire que le chapitre accolades est clos, passons à un autre

Je propose de parler de variables: Il est de bon usage de mémoriser le résultat d'une opération dont on va se resservir plus tard pour économiser du cpu tout en utilisant un poil plus de mémoire. Ex:

Dans un code qui fait plusieurs fois appel à la longueur d'une chaîne de caractères, au lieu de faire appel sans cesse à une fonction strlen (longueur de la chaîne), on stocke son résultat une fois et on utilise notre variable ensuite (à moins que la longueur ai changé). L'utilisation d'une variable est bien moins coûteuse qu'un appel de fonction. Donc on fait un:

len = strlen(machaine);

Et ensuite, au lieu de réutiliser l'appel strlen() on utilise len.

Cela vaut aussi, je crois, quand on a besoin d'une information précise (une taile, par exemple) dans une structure de données complexe. Genre un tableau de plusieurs structures, chacune des structures comportant des sous-couches. Même principe, au lieu de faire plusieurs appels à des trucs infâmes du genre monTableauDeStruct[0]->Aile->quantiteDeCarburant, tu prends la quantiteDeCarburant dans une variable temporaire, tu travailles dessus et tu actualises le résultat à la fin de la fonction.

[noop]

Cela vaut aussi, je crois, quand on a besoin d'une information précise (une taile, par exemple) dans une structure de données complexe. Genre un tableau de plusieurs structures, chacune des structures comportant des sous-couches. Même principe, au lieu de faire plusieurs appels à des trucs infâmes du genre monTableauDeStruct[0]->Aile->quantiteDeCarburant, tu prends la quantiteDeCarburant dans une variable temporaire, tu travailles dessus et tu actualises le résultat à la fin de la fonction.

Je préfèrerais le code suivant:

Code

long * tempQuantitéCarburant = &(monTableauDeStruct[0]->Aile->quantiteDeCarburant);
....
*tempQuantiteCarburant += quantité;
....
*tempQuantiteCarburant += 10;

La mise à jour est automatique.....Un oubli est si vite arrivé

Concernant les variables, il y a une erreur très fréquente qui est la suivante:

Code

char * maFonction() {
   char maChaine[100];
   ...
   return maChaine;
}

Ne jamais retourner de pointeur sur la pile. Le résultat est "unpredictable" et en plus des problèmes de sécurité la donnée n'est pas fiable. En plus un appel a free() sur ce pointeur est une catastrophe.

[macuserfr]

Oui, les pointeurs!

Par contre dans ton deuxième exemple, maChaine est une variable locale, donc théoriquement détruite à la fin de la fonction. On est pas censé y accéder après.

[Hellstorm]

Comme tu dis macuserfr, on est pas censé, d'ou l'avertissement en de noop

[macuserfr]

Tiens, une astuce toute bête à laquelle je viens d'être confronté: Si vous avez une variable ou autre bout de chaîne à changer dans votre code, utilisez la fonction de recherche de votre éditeur de texte/IDE pour localiser toutes les instances. Si vous le faite à la main, vous pouvez en oublier...

[Hellstorm]

Ouaip, mais y a même mieux, du style rechercher et remplacé ça evite de devoir retaper X fois le même nom de variable, il faut rappeler que l'informaticien est fénéant

[macuserfr]

Oui, oui, quand je disais la fonction recherche, j'ai fait un remplacer et rechercher. J'ai pas osé un remplacer tout car ça peut vite dégénérer aussi dans l'autre sens...

[greg57]

Bon euh... si c'est pour conseiller de faire du rechercher remplacer je suis plus du tout sur de vouloir l'épingler ce sujet...