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

[cbrandt]

En C/Objective-C je mets toujours cette petite macro pour faciliter le traitement des erreurs:

Code

#define Fail(erreur,label) {if(erreur) goto label;}

oui, je sais, les goto c'est crade, mais c'est pour la bonne cause
Ça permet de regrouper le code de gestion d'erreur en fin de fonction, et ça s'utilise comme ça:

Code

int err;
...
err = appel_de_fonction ();
Fail (err, stop);
...
return;
stop:
NSLog (@"erreur: %d", err);
...

[schlum]

En C/Objective-C je mets toujours cette petite macro pour faciliter le traitement des erreurs:

Code

#define Fail(erreur,label) {if(erreur) goto label;}

oui, je sais, les goto c'est crade, mais c'est pour la bonne cause
Ça permet de regrouper le code de gestion d'erreur en fin de fonction, et ça s'utilise comme ça:

Code

int err;
...
err = appel_de_fonction ();
Fail (err, stop);
...
return;
stop:
NSLog (@"erreur: %d", err);
...

Beauh !
Et les NSException et @try @catch, c'est fait pour quoi ?
(oui, j'arrive après la guerre…)

[cbrandt]

En C/Objective-C je mets toujours cette petite macro pour faciliter le traitement des erreurs:

Code

#define Fail(erreur,label) {if(erreur) goto label;}

oui, je sais, les goto c'est crade, mais c'est pour la bonne cause
Ça permet de regrouper le code de gestion d'erreur en fin de fonction, et ça s'utilise comme ça:

Code

int err;
...
err = appel_de_fonction ();
Fail (err, stop);
...
return;
stop:
NSLog (@"erreur: %d", err);
...

Beauh !
Et les NSException et @try @catch, c'est fait pour quoi ?
(oui, j'arrive après la guerre…)

oui, bon… c'est vrai…
mais j'ai pris l'habitude, car j'ai commencé à mettre ça dans ma "toollib" perso qui marche sous MacOS, Windows et Linux… pour quand je fais du code serveur (portable) sans interface utilisateur…

[schlum]

oui, bon… c'est vrai…
mais j'ai pris l'habitude, car j'ai commencé à mettre ça dans ma "toollib" perso qui marche sous MacOS, Windows et Linux… pour quand je fais du code serveur (portable) sans interface utilisateur…

Ah oui… Si c'est multi-plateformes, je préfère le C++ avec le même mécanisme d'exceptions (mieux encore que celui d'Objective-C d'ailleurs).

Code

#define TRY try {

#define CATCH \
} catch (MyException &e) { \
    // Log \
    throw; \
}

#define CATCHIGN \
} catch (MyException &e) { \
    // Log \
}

#define THROW(msg) { \
    // Log \
    MyException newE; \
    throw newE; \
}

Et mettre des TRY … CATCH autour de chaque fonction / méthode

A Schlum, pas grave... il faut aussi signaler le @finally.

On y passe tout le temps, exception où pas.

C'est important pour faire le ménage après une exception. Certaines ressources système manquantes peuvent conduire au besoin de reboot d'un système si on ne les libère pas correctement : threads, file handles... Même en cas d' exception qui va immanquablement conduire à un crash, il faut faire ce ménage avant de s'écraser avec grâce.

J-P

Oui… Mais ne pas oublier que le NSAutoreleasePool en Obj-C est automatiquement nettoyé quand on saute avec une exception… même s'il n'est pas libéré dans le @finally
Donc il est plus facile de l'utiliser et de se passer de @finally quand c'est possible