Discussion :

[Mat.M]

salut el_slapper 9 et 10 pour moi ça ne veut rien dire; ce n'est pas du tout explicite

[el_slapper]

salut el_slapper 9 et 10 pour moi ça ne veut rien dire; ce n'est pas du tout explicite

Ah, je comprends ce que tu veux dire, ça ouvre un autre débat. Le truc, c'est que quand on est sur l'application, c'est explicite : 9, c'est "autres", et 10, c'est "SMUR". (on a aussi ambulances, hélicos, véhicule personnel, pompiers, etc.....). Est-ce que ça a de la valeur ajoutée de créer une liste qui fait correspondre le code à sa valeur? Pour l'appli elle-même, évidemment. If codeTransportSMUR(ou un équivalent explicite), est bien plus lisible que If codeTransport = 10. On est d'accord.

Mais je ne suis pas coté applicatif. Je suis coté script de test automatique, et, au final, que 10 signifie SMUR, je m'en fous. A la maintenance du script, ça n'a aucune valeur ajoutée. Faut-il le mettre quand même? Mmmmh, bonne question. L'action que j'essaye de coder(entretemps, j'ai fini par la faire marcher, d'ailleurs), c'est juste de choisir la valeur "10" dans cet ActiveX piégeux. Je ne peux pas décemment mettre une valeur "SMUR" (d'autant plus que ça ne marcherait pas, puisque quand le robot tape deux chiffres, ça ne prend que le dernier, et que le code SMUR est sur deux chiffres, à moins de faire une usine à gaz pour un truc que je fais une fois en tout et pour tout).

Dit autrement, est-ce que ça vaut le cout de surarchitecturer le truc avec une fonction complexe que je ne rappellerais jamais ailleurs(j'en suis à peu près certain), juste pour que le code soit limpide et n'aie pas besoin de commentaires(suite à ta remarque, je crois que je vais juste rajouter un commentaire qui dit que 10="SMUR")? Vaste question. Je ne vais pas le faire, mais je sais que certains me le préconiseraient.

[Marco46]

À quelle fréquence pensez-vous utiliser des commentaires ? Rarement, souvent, très souvent ?

Jamais. Ça a été dur à écrire, ça doit être dur à lire.

Blague à part, le moins possible, il n'y a rien de pire que du commentaire obsolète induisant en erreur. Les tests automatisés ont bien plus de valeur, il vaut donc mieux écrire un test qu'un commentaire !

EDIT : Une seule exception, les commentaires de documentation d'API publique.

[the_mummy]

Ceci devrait faire l'objet d'une UE dans les formations de développement!!!
il y a trop de développeur (commentateur) chevronnés dans cet univers

[Luc Orient]

...

Bon, le COBOL est verbeux et les majuscules ont tendance à faire fuir les petits jeunes, désolé. Et tout ceci marche parcequ'on a soigneusement préparé ses booléens en amont. Le SELECT CASE TRUE est considéré comme une horreur dans d'autres langages, mais en COBOL, ça passe très bien ...

Petite précision, l'instruction de CHOIX multiple en COBOL n'est pas SELECT CASE mais EVALUATE WHEN ...

[el_slapper]

Petite précision, l'instruction de CHOIX multiple en COBOL n'est pas SELECT CASE mais EVALUATE WHEN ...

Exact, mais je parlais à des non cobolistes....(et j'ai beaucoup pratiqué le EVALUATE TRUE, donc)

[Nebulix]

Il est intéressant de considérer des exemples un peu moins niais.
Soit

Code :

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

1
2
3
4
5
//data[1..d1,1..d2]
// somme des carrés
for i:=1 to d1 do
for j:=1 to d2 do
somme:=somme+sqr(data[i,j]);

ou bien

Code :

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

1
2
3
4
for indice_balayant_la_première_dimension_du_tableau_des_données:=1 to première_dimension_tableau_des_données do
for indice_balayant_la_deuxième_dimension_du_tableau_des_données:=1 to deuxième_dimension_tableau_des_données do
somme_des_carrés_des_éléments_du_tableau_des_données:=somme_des_carrés_des_éléments_du_tableau_des_données+sqr(tableau_des_données[indice_balayant_la_première_dimension_du_tableau_des_données,indice_balayant_la_deuxième_dimension_du_tableau_des_données]);

[psychadelic]

Je me suis fait les dents en C en épluchant les bouquins de Scott Knaster.
J'ai travaillé sur des bibliotheques en C et C++ sur des produits financiers devant réaliser des formules complexes sur des indices complexes avec des variables complexe ou il faut parfois plusieurs heures avant d'en comprendre le sens et le comment du pourquoi.
Alors quand t'a passé un semaine sur un swap de taux avec des conversions de monnaies fluctuantes, ben ,tes super content de retrouver un gros commentaire qui t'explique ce qu'il ne faut surtout pas tripoter et un rappel des règles qui s'y appliquent, voir même des petits rappels triviaux pour te dire que cette variable joue sur un taux directeur, même si elle s'appelle justement taux_directeur, parce que je ne connais pas un développeur capable de garder la tête froide en jonglant avec 36 formules mathématiques et financières à longueur de journée.

Et pour en revenir à Scott Knaster, je fais comme lui, je dissémine de l'humour au second degré dans mon code (mais toujours en lien avec l’algorithme, parce que je me suis rendu compte que cela faisait toujours plaisir à ceux devaient re-tripoter le code, et que s'il est placé au bon endroit cela leur permettait de mieux se souvenir des écueils à éviter.

Les exemples de codes sur le sujet , c'est du flan à coté.

[fiduce]

Les commentaires ça sert à rien, c'est pas compilé (troll off)

Y a pire : ajouter un checkArgument compilé à la place d'un commentaire rappelant pourquoi on peut s'en passer ... (cf. l'avant dernier exemple ... qui est peut-être situé juste 10 lignes en dessous du checkArgument)

[acx01b]

Il me semble que vous n'avez pas parlé de la distinction énorme entre lire le code et l'exécuter avec un débugger.

À mon avis utiliser un débugger pour comprendre comment fonctionne un code c'est tout un art, dont bien des aspects restent encore à être développés,

et qu'en la matière les bonnes pratiques vont beaucoup plus loin que l'idée d'écrire un code propre et localement lisible avec quelques commentaires pertinents.

Typiquement la facilité à comprendre une méthode dépend énormément des paramètres donnés en entrée. C'est con mais pour comprendre un algorithme sur une liste, donner en entrée la liste vide ça marche moins bien.

[Matthieu Vergne]

Un code bien fait a des messages d'erreurs assez clairs pour comprendre ce qui ne va pas. Nécessiter le débogueur (ou des prints supplémentaires) pour comprendre ce qui ne va pas indique avant tout un code qui mériterait d'être amélioré.

Dit autrement, si "comprendre comment fonctionne un code c'est tout un art", que ce soit avec un débogueur ou un outil plus adapté, c'est que le code n'est pas aisément compréhensible. Or c'est justement l'objet d'une structuration logique du code, d'un nommage clair, de la documentation (messages d'erreurs inclus) et des commentaires (ce dernier étant l'objet du sujet). Si une information est nécessaire à la compréhension, soit elle doit être donnée, soit les informations nécessaires pour l'obtenir doivent être données à la place. Pour le dernier cas, je pense notamment aux informations qui sont techniquement ou légalement indisponibles.

Même si on peut toujours parler du débogueur pour être plus exhaustif, c'est regarder les conséquences plutôt que les causes, ce n'est donc pas régler le problème de manière définitive.