Les rubriques (actu, forums, tutos) de Développez
Réseaux sociaux
9   0


 Discussion forum

Quel est le meilleur conseil quand on programme ?

Le , par mitkl, Membre Expert
Le site Internet InformIT est un train de réaliser une série intéressante d'articles basée sur le même thème : Quel est le meilleur conseil que vous ayez reçu ?

Ainsi, plusieurs experts venant de différents horizons ont été conviés à répondre à cette question, voici un rapide résumé :

  • Erik Buck Erik Buck est un développeur iOS auteur de quelques livres sur ce domaine. Pour lui, le meilleur conseil tient en trois mots : "write less code" ou "Écrire moins de code" pour rendre une source plus simple et plus facile à maintenir.
  • Obie Fernandez Obie Fernandez est un développeur de Ruby et Ruby On Rails et auteur aussi de livres sur ces deux technologies. Son conseil : toujours prendre le temps de réfléchir quand on a une erreur avant de rajouter du code supplémentaire.
  • Danny Kalev Danny Kalev est un développeur C++ expérimenté, il est auteur de livre et a aussi participé au comité de standardisation du C++. Pour Danny Kalev, il faut lire des livres, lire des magazines, apprendre encore et toujours de nouvelles techniques. Il conclut avec cette phrase : "read much more than you write" ou "Lisez plus que vous ne codez".
  • Eric Lippert Eric Lippert est un développeur C# qui a travaillé chez Microsoft. Son avis : pour devenir meilleur, participer sur des forums ou des groupes de discussions en aidant ceux qui ont des questions, si vous avez la réponse, dites là, si vous ne l'avez pas, rechercher sa réponse sur Internet.
  • Mark Summerfield Mark Summerfield est un développeur et a écrit un livre sur le langage Go. Il n'a pas un mais deux conseils à adresser. Le premier : refactoriser son code rejoignant un peu l'idée d'Erik Buck de rendre le code plus facile à comprendre et donc à maintenir. Le deuxième : écrire des tests unitaires pour son code avant de l'intégrer au projet.
  • Bill Wagner Bill Wagner est auteur de livre sur le langage C#. Son conseil : d'abord rendre son code fonctionnel avant de vouloir l'améliorer ! Ça peut paraitre stupide mais il faut toujours garder cela en tête !


Source : The Best Programming Advice I Ever Got

Et vous ?

Avec qui êtes-vous le plus d'accord ?
Quel est le meilleur conseil que vous ayez reçu ?
Pour vous, quel est le meilleur conseil que l'on peut donner ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de sevyc64 sevyc64 - Modérateur http://www.developpez.com
le 08/05/2014 à 18:52
Citation Envoyé par DonQuiche  Voir le message
En pratique, sur une équipe de taille raisonnable, je n'ai vu que des avantages après l'abandon des commentaires.

Face à cet argument, je serais comme mon collègue

Citation Envoyé par pomauguet  Voir le message
C'est un peu radical de ne pas mettre de commentaire , mais je plussoie sur l'idée derrière ta règle.

Comme tu l'as dit, 95% des commentaires sont inutiles. Et de ceux-là, on s'en passe aisément.

Mais il reste les 5%. Et ceux-là ont toutes leurs importances, bien supérieure souvent à n'importe quelle règle de bonne écriture de code.

Qui n'a jamais eu affaire à un algorithme subtil à coder ou quelques lignes de commentaire en début de fonction, indiquant les particularités, épargnent des heures de réflexion et d'épluchage de doc pour savoir comment ça marche ...
Qui ne sait jamais retrouver devant une fonction censée traiter tout un tableau mais ne commençant qu'à l'index 1 et non pas 0 ...

Il ne faut pas bannir les commentaires, juste les inutiles.

Et encore, moi, perso, j'en met, de particulièrement inutiles.
J'aime bien, juste avant la signature de chaque méthode, mettre une ligne de * ou de # sur toute la largeur de ma page, pour bien découper mon fichier source et identifier immédiatement le début de chaque méthode. Utile lorsqu'on doit passer en revue du code source sur des IDE qui ne savant pas trop gérer la coloration syntaxique.
Il m'arrive aussi de faire de même dans les grosses fonctions (je maintiens, contre les "bonnes pensées" actuelles qu'il n'est pas forcément toujours pertinent de découper des longues fonctions en sous-fonctions), notamment dans des fonctions de traitement séquentiel par exemple, de mettre une petite ligne de commentaire (*, #, ., -, ou autre) pour bien identifier et séparer chaque étape.
(Sachant que personnellement, j'ai une horreur viscérale de l'accumulation de lignes vides dans le but de séparer du code)
Avatar de CodeurPlusPlus CodeurPlusPlus - Membre émérite http://www.developpez.com
le 08/05/2014 à 19:04
Citation Envoyé par Mr_Exal  Voir le message
Va dire ça aux deux guignols qui ont évalué mon projet de BTS (synthèse et reconnaissance vocale en Java), ils m'ont dit clairement que si je ne mettais aucun commentaire ils ne m'embaucheraient jamais (alors que toutes les fonctions étaient clairement nommées et le code bien plus que lisible).

Un peu d'humilité ne te ferait pas de mal. Tu ne peux pas évaluer objectivement la lisibilité du code que tu produis. Et si tu penses que tu peux faire lisible sans aucun commentaire, c'est que tu te sur-estimes complètement. Mais ce débat a déjà été fait et refait maintes fois.

Tu te permets de traiter de "guignols" des personnes qui connaissent mieux que toi leur métier.
Avatar de DonQuiche DonQuiche - Expert Confirmé Sénior http://www.developpez.com
le 09/05/2014 à 8:16
Citation Envoyé par sevyc64  Voir le message
Mais il reste les 5%. Et ceux-là ont toutes leurs importances, bien supérieure souvent à n'importe quelle règle de bonne écriture de code.

Nous sommes d'accord : quand j'ai parlé d'abandon des commentaires je ne voulais pas dire leur éradication totale, seulement l'arrêt des commentaires systématiques (JavaDoc/XmlDoc) et la recherche en priorité d'alternatives par le renommage ou le redécoupage.

Nous ne sommes pas commenticides !

Quant aux séparateurs que tu affectionnes, c'est une affaire de préférence, comme les espaces. A chaque équipe son choix en la matière.
Avatar de ptah35 ptah35 - Membre chevronné http://www.developpez.com
le 10/05/2014 à 9:47
S'agissant des commentaires j'applique le principe suivant : "Si tu peux le dire en code, dis le en code et utilise les commentaire pour le reste". Le reste c'est, par exemple, les en-tête de fichier (description, contexte, auteur, date de dernière modification, ...), selon les langages, les pré-condition, post-condition et invariant des méthodes, fonction ou procédure, des références bibliographiques ou des explications à propos d'un algorithme, du JavaDoc/XmlDoc pour la partie documentée d'une API, etc.

Pour les conseils, je pense que la refactorisation est très importante mais pour la pratiquer réellement il faut avant tout de bons tests unitaires et d'intégration. Faire de la refactorisation efficace nécessite de pouvoir autant que possible se libérer l'esprit de la peur de casser le code existant, sans tests cette peur est plus que légitime. Avec de bon tests en revanches, on sait que si après une modification les tests passent, sans pour autant avoir de certitude, on a un niveau de confiance raisonnable que l'on a rien cassé et s'il s'avère par la suite que c'était le cas, on pourra alors corriger le test fautif et/ou ajouter un ou plusieurs tests pour traiter spécifiquement le problème.
Avatar de sevyc64 sevyc64 - Modérateur http://www.developpez.com
le 10/05/2014 à 10:30
Citation Envoyé par ptah35  Voir le message
Le reste c'est, par exemple, les en-tête de fichier (description, contexte, auteur, date de dernière modification, ...),

Le genre de commentaire que, personnellement, je considère justement parfaitement inutile (et je sais de quoi je parle, j'en ai gérer pendant plusieurs années pour un client). La notion d'auteur peut être très vague lorsqu'on est dans une équipe de plusieurs développeurs, voire dans une boite comportant plusieurs équipes de plusieurs développeurs. Et si en plus en considère le turn-over de la boite .... Sauf à y renseigner l'annuaire, ça sert pas à grand chose.
Les notions de modifications, dernière modification, etc, sont souvent rarement à jour au delà de la 4 ou 5ème version du fichier, surtout lorsque les entêtes en question concerne à la fois le fichier lui-même mais aussi chaque méthode dans le fichier.

De plus, dans une structure organisée, qui possède un gestionnaire de source type svn ou github, ce genre de commentaire est rendu obsolète par le gestionnaire de source, bien plus efficace à ce niveau là.

Mais après, effectivement, chacun voit son propre intérêt dans sa façon de faire.

Pour le cas que j'ai eu à gérer durant plusieurs années, sur ce point là et sur la doc qui allait avec, il n'était pas rare qu'il me faille 1/2h pour faire une modif, et ensuite 3 jours pour gérer toutes ces notions de versions, tant dans les sources que sur la doc qu'il fallait modifier entièrement. Sans compter les tests, qui, au delà du test fonctionnel de la modif, consistaient à redérouler l'entièreté des tests pour la non régression, une inspection de code, un file-compare, une relecture complète de la doc, ...
Bref rien de très productif.
Alors qu'avec un gestionnaire de source, il suffit de produire un rapport d'évolution entre les 2 releases, ça prend 30sec !
Avatar de ptah35 ptah35 - Membre chevronné http://www.developpez.com
le 10/05/2014 à 12:34
Citation Envoyé par sevyc64  Voir le message
Le genre de commentaire que, personnellement, je considère justement parfaitement inutile (et je sais de quoi je parle, j'en ai gérer pendant plusieurs années pour un client). La notion d'auteur peut être très vague lorsqu'on est dans une équipe de plusieurs développeurs, voire dans une boite comportant plusieurs équipes de plusieurs développeurs. Et si en plus en considère le turn-over de la boite .... Sauf à y renseigner l'annuaire, ça sert pas à grand chose.
Les notions de modifications, dernière modification, etc, sont souvent rarement à jour au delà de la 4 ou 5ème version du fichier, surtout lorsque les entêtes en question concerne à la fois le fichier lui-même mais aussi chaque méthode dans le fichier.

De plus, dans une structure organisée, qui possède un gestionnaire de source type svn ou github, ce genre de commentaire est rendu obsolète par le gestionnaire de source, bien plus efficace à ce niveau là.

Mais après, effectivement, chacun voit son propre intérêt dans sa façon de faire.

Pour le cas que j'ai eu à gérer durant plusieurs années, sur ce point là et sur la doc qui allait avec, il n'était pas rare qu'il me faille 1/2h pour faire une modif, et ensuite 3 jours pour gérer toutes ces notions de versions, tant dans les sources que sur la doc qu'il fallait modifier entièrement. Sans compter les tests, qui, au delà du test fonctionnel de la modif, consistaient à redérouler l'entièreté des tests pour la non régression, une inspection de code, un file-compare, une relecture complète de la doc, ...
Bref rien de très productif.
Alors qu'avec un gestionnaire de source, il suffit de produire un rapport d'évolution entre les 2 releases, ça prend 30sec !

Pour l'auteur et la date je pensais pour les deux à la dernière modification mais j'admet que ce n'est pas forcément nécessaire, l'information étant effectivement dans le système de gestion de version qui est, selon moi, une absolue nécessité si l'on est professionnel et je ne vois que peu de raison de s'en passer dans les autre cas. Je pense néanmoins qu'une description du contexte dans lequel on utilise le fichier et une brève description de son contenu reste utile. D'une manière générale ce que l'on écrit sous forme de commentaire doit être relativement stable et c'est le cas de la description du contexte d'un fichier, du JavaDoc d'une API qui est publiée ou des pré-conditions, post-conditions et invariants d'une méthode. Mais le principe est :

"Si tu peux le dire en code, dis le en code et utilise les commentaires pour le reste"

A chacun de décider ce qui est utile ou non dans le reste, mais le fait de dire uniquement en code ce qui peut être dit en code évide déjà une bonne partie des commentaires susceptibles de devenir obsolètes.
Avatar de Mr_Exal Mr_Exal - Expert Confirmé http://www.developpez.com
le 19/05/2014 à 9:10
Citation Envoyé par CodeurPlusPlus  Voir le message
Un peu d'humilité ne te ferait pas de mal. Tu ne peux pas évaluer objectivement la lisibilité du code que tu produis. Et si tu penses que tu peux faire lisible sans aucun commentaire, c'est que tu te sur-estimes complètement. Mais ce débat a déjà été fait et refait maintes fois.

Tu te permets de traiter de "guignols" des personnes qui connaissent mieux que toi leur métier.

J'en ai discuté (et montré ce que j'avais produis autant en terme de code que d'oral) avec plusieurs personnes du métier et crois moi oui ce sont deux guignols. Rien qu'à travers les questions qu'ils m'ont posé ils n'ont strictement rien écouté de ce que je leur ai raconté (et crois mois que j'avais passé des oraux blancs devant des personnes ne connaissant pas du tout mon sujet avant, qui ont un QI moyen normal et qui ont tout à fait compris de quoi il s'agissait).
Avatar de el_slapper el_slapper - Expert Confirmé Sénior http://www.developpez.com
le 19/05/2014 à 11:35
Citation Envoyé par Mr_Exal  Voir le message
J'en ai discuté (et montré ce que j'avais produis autant en terme de code que d'oral) avec plusieurs personnes du métier et crois moi oui ce sont deux guignols. Rien qu'à travers les questions qu'ils m'ont posé ils n'ont strictement rien écouté de ce que je leur ai raconté (et crois mois que j'avais passé des oraux blancs devant des personnes ne connaissant pas du tout mon sujet avant, qui ont un QI moyen normal et qui ont tout à fait compris de quoi il s'agissait).

Je n'aime pas tailler, mais je vais le faire quand même : tu est un mauvais programmeur parceque tu manques cruellement d'humilité. On a toujours plein de trucs à apprendre, y compris de gens qui ne pensent pas comme nous. En partant du principe qu'ils n'ont rien à t'apprendre, alors tu te limites toi-même, dans un univers ou l'apprentissage est essentiel.
Avatar de Mr_Exal Mr_Exal - Expert Confirmé http://www.developpez.com
le 19/05/2014 à 13:12
Citation Envoyé par el_slapper  Voir le message
Je n'aime pas tailler, mais je vais le faire quand même : tu est un mauvais programmeur parceque tu manques cruellement d'humilité. On a toujours plein de trucs à apprendre, y compris de gens qui ne pensent pas comme nous. En partant du principe qu'ils n'ont rien à t'apprendre, alors tu te limites toi-même, dans un univers ou l'apprentissage est essentiel.

Je n'appelle pas ça du manque d'humilité, juste savoir faire la part des choses.

Je suis bien conscient que la formation est permanente dans nos métiers et qu'il vaut mieux être ouvert à tout et à chacun.

Seulement, pour entendre les réflexions qu'ils m'ont fait pendant mon oral j'avais un peu autre chose à faire que de me faire casser comme une merde pendant 45 minutes (après, soit, c'était peut être le but de l'exercice, mais même mes profs ont halluciné quand je leur ai raconté ce qu'il s'est passé (des réflexions du genre "Ah c'est ça vos Schémas UML ? Mais c'est de la merde.")).

Je ne vois pas trop en quoi c'est pertinent de se foutre de la gueule du candidat que tu as en face de toi pendant tout le long de son oral et de le casser à chaque fois que tu ouvres ta bouche.

Maintenant j'en suis pas à dire "Bouhouhou les vilains jurys ils ont été méchants."

[troll] Je ne fais pas (encore) de marketing je n'ai pas (encore) besoin d'étudier les cons pour chercher à comprendre comment ils fonctionnent. [/troll]
Avatar de alyno alyno - Invité de passage http://www.developpez.com
le 26/01/2015 à 16:02
Tout réside dans la motivation, et aussi à la l'implication de la personne, comme aider des gens en difficulté dans des forums.
Parce que avoir le sentiment d'apporter son aide nous permet aussi d'apprendre des choses plus vite qu'on ne peut l'imaginer.
C'est pourquoi je suis du même avis que Mr Eric Lippert
Avatar de Laurent 1973 Laurent 1973 - Membre émérite http://www.developpez.com
le 26/01/2015 à 17:05
Codez en imaginant que la personne qui va maintenir votre code est un psychopathe meurtrier qui connaît votre adresse.


Offres d'emploi IT
Gestionnaire Paie (H/F)
CDI
Grey Consulting - Ile de France - Paris - 2ème arrondissement
TECHNICIENS INFORMATIQUES CONFIRMES POLYVALENTS (H/F)
CDI
HELPLINE - Ile de France - Paris (75008)
Développeur web h/f
CDI
Multi-Impact - Champagne Ardennes - Reims (51100)

Voir plus d'offres Voir la carte des offres IT
Responsable bénévole de la rubrique Ruby & Rails : Didier Mouronval -