Discussion :

[RomainVALERI]

Bref, franchement ces super développeurs qui postent sur leur blog leur super guidelines comme si c'était des paroles d'évangiles et surtout la "one best way"...ça commence à me gonfler

Donnons des ressources, des vraies ! Et pas des listes de bonnes intentions !

Qu'en pensez-vous ?

J'en pense que :

> à partir du moment où les mecs postent sur leur blog, je ne vois pas bien qui ça peut déranger dans la mesure où ceux qui viennent consulter ce blog... consultent ce blog.

> qui a parlé de paroles d'évangile ? Chacun essaie de confronter ses propres "règles" à celles des autres pour les partager et les améliorer si possible.

> des ressources des vraies ? Il y a tout le reste de developpez.com et developpez.net ! Si tu veux éviter les règles générales et les conseils sur les bonnes pratiques, évite les thread qui s'appellent "Quelles règles les programmeurs débutants devraient-ils toujours respecter ?" et tout ira bien

[Huskinsson]

Ne pas non plus oublié d'indenter son code. Surtout si on souhaite le faire corriger par une personne plus expérimenté. Si l'on travail à plusieur définir des règles d'indentations strictes.

[zeyr2mejetrem]

Ne pas non plus oublié d'indenter son code. Surtout si on souhaite le faire corriger par une personne plus expérimenté. Si l'on travail à plusieur définir des règles d'indentations strictes.

Tout à fait d'accord.
Quand je commence un projet sous Eclipse, une de mes premières étapes est de définir les formatters.

Ainsi quand on crée une classe et qu'on a directement les règles d'indentations automatiques, le squelette JavaDoc avec les tags SVN avec de vrais TODO qui laissent une liste de tâches sur sa vue Eclipse =>
1) On n'a pas à se prendre la tête avec l'indentation
2) On ne peut pas dire "J'ai oublié de remplir la JavaDoc" ou "Dans le mail que t'as envoyé, le copier-coller de ton source, c'était quel révision ?"

[covao]

Il faut éviter la surcharge de commentaires ! Cela reviendrait à rendre illisible le code.

[Djromé]

Salut les Kracks,

Sans être programmateur, j'ai appris le VBA en utilisant le pas-à-pas et en copiant-collant des bouts de code piqués ou gracieusement donnés par la plupart d'entre vous (en vous remerciant). Il est vrai que l'important est de bien comprendre ce que l'on fait (lire les codes VBA n'est pas bien compliqué quand ils sont bien fait) mais les problèmes arrivent dans le complexe voir même dans le très simple, pour vous. Je m'explique, rien que de bien comprendre comment utiliser les différentes fenêtres et outils proposés peut être rébarbatif si personne ne vous l'a expliqué auparavant. Il y a des sites bien fait, dont celui-ci, mais pour moi les commentaires des actions du programme devraient être expliquer chaque fois (on a beau répéter plusieurs fois aux enfants de ne pas traverser la route, ça rentrera quand même en insistant), surtout pour les programmeurs occasionnels (ne me grondé pas, je souhaiterai juste m'attabler avec vous ;-). Le copier-coller des codes dépanne, mais ne soigne pas!

[mdelanno]

Je ne suis absolument pas d'accord avec le premier point. Scinder son code en X méthodes simplement pour limiter le nombre de lignes nuit gravement à la lisibilité du code. Pour lire et comprendre ce dernier, il faut alors sauter d'une méthode à l'autre, et on perd le contexte à chaque fois. Il vaut mieux utiliser des régions quand le langage supporte cette fonctionnalité ou les blocs repliables au niveau de l'IDE. Le code ne doit être déporté dans une méthode ou une fonction que si il est utilisé à plusieurs endroits.

Evidemment en VB.NET, comme on ne peut pas utiliser les régions dans le corps d'une méthode, on est obligé de scinder le code autrement. C'est une des raisons qui font que je n'apprécie pas trop ce langage.

[hegros]

Je ne suis absolument pas d'accord avec le premier point. Scinder son code en X méthodes simplement pour limiter le nombre de lignes nuit gravement à la lisibilité du code.

Découper ses méthodes en méthodes plus petites (et donc limiter le nombre de lignes de code par méthode) n'a rien à voir avec la lisibilité du code, c'est une réponse de conception qui ne se limite pas simplement à limiter le nombre de ligne pour limiter le nombre de ligne de code.

En effet, plus c'est gros plus c'est fatalement plus compliqué et la réponse à un problème complexe et gros c'est son découpage en unité plus petite et donc plus simple.

Bien ordonner ses méthodes (l'ordre d'apparition dans la classe) cela augmente la lisibilité du code puisqu'un fichier source, à l'instar d'un journal pour reprendre les termes du livre Code Propre, on va le lire de haut en bas.

[sevyc64]

Vous me faites marrer avec votre "un débutant n'a rien à faire en entreprise".

Un certain nombre de développeurs de 40 ans et plus dont certains peuvent passer pour des experts ont appris à programmer sur le tas, en entreprise. Ils ne sont pas passer par l'école pour apprendre à programmer.

Et quand on voit certains stagiaires et débutants arrivés, pourtant sortant d'école d'ingé, etc... avec toutes leurs théories, préjugés et leur suffisance (moi je suis ingénieur, même s'y j'y connais rien), on se dit parfois, qu'ils auraient mieux fait de ne pas passer par la case école et d'apprendre directement en entreprise. Surtout quand il faut passer 6 mois à leur faire oublier ce qu'ils ont vu en école, et leur réapprendre tout.

Mais cela est de moins en moins possible, surtout quand les entreprises (SSII en particulier) recherche des jeunes de moins de 6 mois d'expérience (ça coute moins cher à payer) mais avec un bagage et des connaissances dignes d'un senior de plus 15 d'expérience.

[OWickerman]

Six, le débutant doit éviter l'abstrait, et toujours opter pour le concret.

Et vous ?

Quelles sont vos « 7 Règles d'Or » de la programmation ?

Et que pensez-vous de ces règles de Paul Vick?

Source : Blog Paul Vick

J'aimerai beaucoup savoir comment différencier abstrait et concret en programmation...

Sinon, ma règle N°1 : ne jamais écouter les vieux barbons qui croient tout savoir et ont peur pour leur poste à cause de leurs connaissances obsolètes cristallisées en dogmes.

[gwinyam]

J'aimerai beaucoup savoir comment différencier abstrait et concret en programmation...

Soit tu fais le truc terre à terre et tu doublonnes du code, soit tu abstrais au maximum, ce qui te permet de ne pas doubler le code mais devient plus difficile pour quelqu'un qui démarre sur les notions de base. Typiquement, il est plus facile pour un débutant de comprendre l'encapsulation puis l'héritage plutôt que l'encapsulation et l'héritage en même temps.

[_skip]

Soit tu fais le truc terre à terre et tu doublonnes du code, soit tu abstrais au maximum, ce qui te permet de ne pas doubler le code mais devient plus difficile pour quelqu'un qui démarre sur les notions de base. Typiquement, il est plus facile pour un débutant de comprendre l'encapsulation puis l'héritage plutôt que l'encapsulation et l'héritage en même temps.

Question de mesure, la seule chose qui compte à mon sens dans un code, c'est qu'il réponde au besoin et soit facile à maintenir. Je suis toujours partant de dire qu'il faut considérer la séparation des couches (le fameux 3 tiers), le concept "dry" et autres pratiques architecturales comme étant des façons **générales** de penser du code, mais en aucun cas comme des règles gravées sur pierre.

Quant aux design patterns, polymorphisme et l'orienté objet en général, ce sont juste des outils pour parvenir à son but. Les best practices ont beau dire et répéter qu'un pull-up est nécessaire chaque fois que 2 classes partagent ne serait-ce qu'une propriété get/set en commun, il existe des cas où une application trop stricte de cette "vérité universelle" peut vous donner des hiérarchies complètement folles, inutilement complexes et qui réduisent beaucoup votre marge de manoeuvre en cas de modification.
La même chose existe pour la plupart des DP, se forcer à les utiliser peut avoir des conséquences catastrophiques et aboutir à l'introduction de complexités supplémentaires.

La sur-abstraction et l'over-engineering sont pour moi parmi les plus grands ennemis du programmeur, débutant ou pas. Et ces deux pièges techniques sont exacerbés par l'omniprésence de frameworks pleins de "voodoo magic" qui vous laissent penser que vous pouvez vous déresponsabiliser de votre système de persistence et autres.

Je pense qu'il faut prendre ce recul par rapport à tous les bons conseils théoriques et best practices qu'on se plaît à nous rabâcher. Celui qui se retrouve devant son projet avec des délais à tenir et des impératifs de qualité, c'est vous, c'est pas Paul Vike, Martin Fowler, ou Dieu sait quel donneur de leçon dont vous avez cru bon de respecter les principes à la lettre.

[tigunn]

A l'image des Robots d'Asimov, je vais ajouter une règle, la règle qui prévaut toutes les autres: "Ne te précipite pas, réfléchis, analyse bien; puis, ensuite, code"!!!!!
parce qu'il n'y a rien de pire qu'une méthode mal conçu, à part une classe inutile.

[Jitou]

Je suis d'accord avec tous le monde, la règle numéro 1 est commenter son code et cette règle est pour moi indétrônable. Un corollaire à cette règle serai de nommer le nom de ses variables et ses procédures le plus explicitement possible quitte à produire des noms à rallonge (tout en respectant les règles de nommage des langage utilisés). Réveillez vous les écrans limités à 80 colonnes ça n'existe plus ! Je vois trop souvent des lignes de code automatiquement coupées à 80 colonnes, je trouve ça complètement ridicule avec les résolutions incroyables des LCD actuels. Donc nourrissez vos lignes de code avec du commentaire, je préconise au minimum 50% de commentaires dans un fichier source, du plus basique car ce qui est basique pour vous ne l'est pas pour d'autre et inversement, et ce jusqu'au plus éloquent pour résumer un point fonctionnel en en-tête d'une procédure par exemple. Nommer correctement vos variables (et membres de classe) participe à la compréhension du code, les noms raccourcis n'ont de signification que pour vous et puis écrire du code ce n'est pas comme rédiger une petite annonce dans un journal ! Et ceux qui prétendent que cela nuit à la lisibilité du code doivent certainement utiliser de très vieux éditeurs (non pas de nom svp) qui ne connaissent pas la colorisation syntaxique ou d'autres facilités offertes par les éditeurs modernes (commentaires cachés par ex). C'est vrai qu'à une époque on pouvait s'affranchir de tous ces principes car en général un seul développeur écrivait et maintenait son propre code. Maintenant les équipes changent rapidement, la maintenance est en général un autre secteur de l'entreprise prise en charge par d'autres équipes voir d'autres sociétés spécialisées. Donc ne travaillez plus comme si vous étiez seul au monde, certain me dirons oui mais le développeur est par définition autiste, certe mais son travail ne pourra être valorisé que si il suit des principes et cela ne demande véritablement pas beaucoup d'effort. Je laisse le soin aux autres d'énumérer les autres règles (tests unitaires, découpage du code, multilevel logging, maitrise du langage etc ...).

PS: merci à maxinator pour la référence "Clean code"

[sevyc64]

Donc nourrissez vos lignes de code avec du commentaire, je préconise au minimum 50% de commentaires dans un fichier source,

50% soit 1 ligne de commentaire pour un ligne de code, c'est trop.

La règle communément admise c'est de 6 à 10% soit en gros une ligne de commentaire pour 10 à 15 lignes de code.
Ou, pour ce qui préfèreront, de 1 à 3 lignes de commentaire en début de chaque procédure et fonction.

Et c'est largement suffisant, car avec un code correctement découpé et agencé, des nom de variables et méthodes judicieusement choisis et suffisamment explicites, la plupart des commentaires sont superflus

[Jitou]

50% soit 1 ligne de commentaire pour un ligne de code, c'est trop

Oui j'ai peut être eu la main lourde mais je ne pensais pas non plus alterner nécessairement 1 ligne de code avec 1 ligne de commentaire ! Par contre des commentaires en début de méthode c'est insuffisant il faut commenter là où c'est nécessaire il faut penser le commentaire comme une aide contextuelle que l'on peut escamoter où afficher à loisir. Il ne faut pas incriminer les débutants au contraire car ce sont les plus aptes à adopter de nouvelles méthodes de travail pour peux qu'on les coach un peu. Par contre j'ai déjà vu des développeurs senior géniaux mis au placard simplement parce qu’ils étaient incapables de produire du code maintenable, une véritable perte sèche pour l'entreprise qui se trouve alors dans l'impossibilité de valoriser leur travail.

[xetqL]

Mes règles :
1- Se tenir au projet. Le projet à un but et celui-ci doit-être atteint, il faut le terminer coûte que coûte.
2- Éviter de passer par New-York pour aller à Marseille. La meilleure solution est souvent la plus simple.
3- Le code doit être explicite et ne demander qu'un minimum de commentaire.
4- Réinventer la roue (Cadre privé) si possible. Cela oblige à un minimum de réflexion.
5- Ne pas faire n'importe quoi, juste parce que l'on sait que ça marche. L'important est souvent de pouvoir comprendre clairement les étapes qu'effectuera mon programme !

[kisitomomotene]

La meilleur documentation d'une application est son code source, et ses tests automatiques, ils sont les plus fiables.
regardez encore ce code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
// calcul du solde d'un client à partir du code client
  public int calculer(String nom){
...
}

Le code en réalité calcule le solde à partir du nom du client, mais le commentaire par erreur dit qu'il calcul à partir du code client. Résultat si quelqu'un se fit uniquement aux commentaires, il risque de calculer le solde d'un client à la place d'un autre! Moralité lire toujours le code et/ou exécuter des tests automatiques ne pas se fier uniquement aux commentaires.

Si la lecture d'un code source permet de retrouver les informations mentionnées dans les commentaires, alors ça augmente le temps de lecture inutilement, et par conséquent complique la maintenance, puisque qu'on perd trop de temps à relire les mêmes choses deux fois: une première fois dans un langage naturel, et une seconde fois dans un langage de programmation.

Conclusion: Ne pas mettre des commentaires inutiles, et dans la réalité peu sont des cas où les commentaires sont vraiment indispensables lorsque une bonne politique de nommage et de structuration du code est mise en place, du moins selon mon expérience personnelle.

[deuz59]

La meilleur documentation d'une application est son code source, et ses tests automatiques, ils sont les plus fiables.

...

Conclusion: Ne pas mettre des commentaires inutiles, et dans la réalité peu sont des cas où les commentaires sont vraiment indispensables lorsque une bonne politique de nommage et de structuration du code est mise en place, du moins selon mon expérience personnelle.

Je plussoie

[lod101]

La meilleur documentation d'une application est son code source, et ses tests automatiques, ils sont les plus fiables.
regardez encore ce code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
// calcul du solde d'un client à partir du code client
  public int calculer(String nom){
...
}

Le code en réalité calcule le solde à partir du nom du client, mais le commentaire par erreur dit qu'il calcul à partir du code client. Résultat si quelqu'un se fit uniquement aux commentaires, il risque de calculer le solde d'un client à la place d'un autre! Moralité lire toujours le code et/ou exécuter des tests automatiques ne pas se fier uniquement aux commentaires.

Si la lecture d'un code source permet de retrouver les informations mentionnées dans les commentaires, alors ça augmente le temps de lecture inutilement, et par conséquent complique la maintenance, puisque qu'on perd trop de temps à relire les mêmes choses deux fois: une première fois dans un langage naturel, et une seconde fois dans un langage de programmation.

Conclusion: Ne pas mettre des commentaires inutiles, et dans la réalité peu sont des cas où les commentaires sont vraiment indispensables lorsque une bonne politique de nommage et de structuration du code est mise en place, du moins selon mon expérience personnelle.

C'est sûr qu'avec des exemples comme ça on peut tout justifier...
Cependant même si le commentaire est incorrect, il reste partiellement intéressant puisqu'il nous dit sur quoi porte le calcul. Vu que le nommage de la méthode est trop imprécis et que cela arrive constament, le commentaire est donc toujours le bienvenu

Moi j'aurais préférer lire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
/// <summary>
/// Calcule le solde d'un client
/// </summary>
/// <remarks>
/// Le solde doit toujours être positif (par exemple)
/// </remarks>
/// <param name="codeClient">Code client</param>
/// <returns>Solde client</returns>
public int CalculerSolde(string codeClient)
{
     ...
 }

Ben oui, j'ai du code qui risque d'être réutiliser...

Contrairement à toi, moi le commentaire m'évite de lire le code. Si une portion de code à le commentaire "//Addition..." et que pour moi le bug est plutôt dans le bout code "//Soustraction" alors j'aurai gagné un peu temps

[kisitomomotene]

Contrairement à toi, moi le commentaire m'évite de lire le code. Si une portion de code à le commentaire "//Addition..." et que pour moi le bug est plutôt dans le bout code "//Soustraction" alors j'aurai gagné un peu temps

Je ne vois pas en quoi votre commentaire évite de lire le code, car rien ne prouve que ce que vous avez écrit dans le commentaire est réellement ce que votre code fait. C'était cela l'esprit de l'exemple que j'avais donné.
Par contre lorsqu'on écrit des test automatiques, l’exécution du test prouve que le code effectue ce qui est spécifié dans le test