Discussion :

[la dos360]

Bonjour, Bonsoir,

je suis étudiant en deuxième année en BTS IRIS et je me demandais que voulait dire bien programmer ? et comment bien programmer ? A quoi cela sert ci ce n'est qu'à comprendre le code écrit?
Les failles de certains logiciel sont-elles dues à la qualité du code ? Et donc du développeur?

Merci

[imperio]

Je pense que tu touches la a une vaste question. Je dirais que la reponse depend de la personne meme si quelques points reviennent. Par exemple :

- un code clair et bien indente
- des noms de variables et de fonctions qui permettent de comprendre a quoi elles servent

Si tu as ca c'est deja un excellent debut. Apres il y a quelques petits trucs qui permettent de bien coder comme :

- mettre des commentaires expliquant un passage complique du code ou bien apportant des precisions
- ne pas mettre 10 000 lignes et 200 fonctions dans un meme fichier

A quoi cela sert ci ce n'est qu'à comprendre le code écrit?

Et bien c'est deja un excellent debut si tu codes avec d'autres personnes sur un meme projet. J'espere pour toi que tu n'auras jamais a reprendre un code existant degueulasse et non-documente.

Les failles de certains logiciel sont-elles dues à la qualité du code ? Et donc du développeur?

Tout depend de ce que tu appelles la qualite du code. Si tu veux dire "un truc facilement lisible par un humain", la reponse est sans doute non, meme si c'est bien plus facile de trouver une erreur s'il y en a une. Cependant les erreurs peuvent ne pas venir uniquement de ton code mais dans tous les cas, un developpeur consciencieux gerera toujours les cas d'erreurs.

[koala01]

Salut,

Bonjour, Bonsoir,

je suis étudiant en deuxième année en BTS IRIS et je me demandais que voulait dire bien programmer ?

Énoncée de la sorte, cette question revient à demander "qu'est ce que bien cuisiner"

C'est un sujet particulièrement vaste pour lequel il y aura sans doute autant de réponses que de gouts ou que de points de vue:

• Du point de vue du programmeur, cela signifie avoir un code clair, maintenable et évolutif
• Du point de vue du financier, cela signifie respecter au mieux les délais, et, s'il y avait même moyen de faire en trois jours ce qui est facturé une semaine, il serait ravi
• Du point de vue du responsable sécurité informatique, une application bien programmée est une application qui ne risque pas de donner l'accès indu à certaines informations sensibles
• Du point de vue du client, c'est une application qui fait ce qu'il attend de sa part.
• Du point de vue du graphiste, ce sera peut être une application qui présente "une zolie interface graphique, toute en couleur"
• Du point de vue de l'ergonome, ce sera une application qui permet d'accéder facilement au différentes fonctionnalités
• ...

et comment bien programmer ?

Il y a énormément de choses à dire si l'on veut répondre à cette question de manière exhaustive

A tel point que l'article que je voulais écrire sur le sujet s'est au final transformé en livre qui paraitra dans les bacs d'ici peu.

Pour résumer, il y a plusieurs aspects à prendre en compte:

1. L' expressivité du code : il est important de choisir des noms (de variables, de fonctions, de classe, ...) qui permettent au lecteur de savoir directement à quoi cela correspond
2. La mise en forme du code : Le lecteur aura beaucoup plus facile à se retrouver dans un code dans lequel il est en mesure repérer "visuellement" les différents blocs d'instructions, les différentes déclarations de variables ou les différentes étapes.
3. Le fait d'éviter de se répéter (recherche DRY sur internet ): Si tu répètes sans cesse le même code à différents endroits, il devient très difficile d'apporter une correction "globale" en cas de problèmes. tu oublieras systématiquement l'une ou l'autre des copies lorsque tu essayeras d'apporter une solution.
4. Le respect de certains principes, connus sous le nom de "loi de déméter" et des principes SOLID:
   
   • Loi de déméter : si un objet A manipule de manière interne un objet B, il n'y a pas forcément de raison pour que l'utilisateur d'un objet de type A doive connaitre l'objet de type B
   • S mis pour Single Responsability Principle (principe de la responsabilité unique)
   • O mis pour Open close Principle (principe ouvert fermé)
   • L mis pour Liskov Subtsitution Principle (principe de substitution de Liskov)
   • I mis pour Interface Segregation Principle (principe de ségrégation des interfaces)
   • D mis pour Depenancies Inversion Principle (principe d'inversion des dépencances)

Une recherche relative à ces différents termes sur ce forum t'apportera très certainement des précisions intéressantes

Et, bien sur, pour être en mesure de "bien programmer", il faut, selon moi, arriver à avoir une idée claire et précise des besoins qui doivent être rencontrés, et -- tant qu'à faire -- de la manière dont ces besoins risquent d'évoluer.

Par contre, je suis très critique envers les commentaires

Pour moi, un commentaire ne vaut, en tous les cas, que s'il ne se met pas à paraphraser le code qu'il commente.

Selon moi, on peut diviser les commentaires en plusieurs catégories:

• Les cartouche, qui expliquent au lecteur le but et le fonctionnement d'une classe ou d'une fonction. Ils sont généralement placé juste avant la classe ou la fonction qu'ils commentent
• Les commentaires à visée pédagogiques : ce sont des commentaires qui tentent d'expliquer au lecteur le pourquoi et / ou le comment de ce qui est fait
• Les commentaires qui paraphrasent le code : c'est le genre de commentaire qui indique que if(a == 3) signifie que l'on entrera dans le bloc d'instruction uniquement si a vaut 3
• Les commentaires qui ont pour objectif de signaler les différentes étapes dans un algorithme
• Les commentaires qui apportent certaines précision que le code seul n'apporte pas.

Les cartouches devraient presque être considérés comme "obligatoires":

Ils permettent au lecteur du code de déterminer facilement si la classe ou la fonction qu'il s'apprête à utiliser correspond bel et bien à ses besoins, et permettent même d'obtenir une documentation générée de manière automatique (par exemple, au travers d'outils comme doxygen).

Certains EDI sont d'ailleurs en mesure de faire apparaitre ces commentaires à l'utilisation

En outre, ils sont globalement beaucoup plus stables que les commentaires que l'on peut retrouver ailleurs dans le code : L'objectif d'une classe ou d'une fonction et les conditions qui doivent être respectées évolueront généralement très peu et, si c'est le cas, il y a de fortes chances pour que cela soit concrétisé par l'ajout d'une nouvelle classe ou d'une nouvelle fonction (quitte à ce que ce soit une surcharge de fonction existante).

Les commentaires à visée pédagogique sont très importants sur un forum ou dans un cours, pour permettre à celui qui les lit de se faire une idée précise de ce qui est fait. Mais ils n'ont strictement aucun intérêt dans du code de "production" : A priori, le lecteur d'un code de production est sensé connaitre un minimum le langage qu'il est occupé à lire. Le code de production ne doit donc pas se dissiper en essayant d'inculquer de nouvelles informations au lecteur.

Les commentaires qui paraphrasent le code devraient à mon sens être proscrits (s'ils n'ont aucune visée pédagogique s'entend): Ils sont beaucoup trop susceptibles obsolescence et risquent, s'il sont devenus obsolètes, d'induire le lecteur en erreur, étant donné qu'il y a de fortes chances qu'il se laisse aller à sa "paresse naturelle" et qu'il décide de passer le code correspondant au commentaire en se basant sur le fait que "bah, le commentaire a dit que..."

Les commentaires qui ont pour but de marquer les différentes étapes sont, très clairement, moins dangereux que les commentaires qui paraphrasent le code (malgré le fait qu'ils le fassent d'une certaine manière), mais leur utilité est discutable, étant donné que le SRP nous incite à faire en sorte que chaque fonction ne devrait avoir qu'une et une seule responsabilité.

On peut donc raisonnablement se poser la question de savoir si les différentes étapes marquées par ce genre de commentaire ne pourraient pas être prises charge par des fonctions spécifiques, rendant de facto les commentaires inutiles.

Enfin, comme il est difficile de prévoir toutes les situations spécifiques dans lesquelles on peut se trouver, il y a les commentaires qui apportent certaines précisions que le code n'apporte pas directement, étant alors entendu qu'ils ne paraphrasent pas le code.

L'utilité de ces commentaires mérite d'être évaluée au cas par cas, ce qui rend virtuellement impossible le fait de tracer une ligne de conduite générale à leur sujet

Mais celui qui décide de les écrire devrait au minimum se poser la question de leur pérennité (comprenez : à quel point le code peut il être modifié sans entrainer une obsolescence du commentaire) et de leur intérêt pour le lecteur suivant.

Nota: je ne cherche pas à relancer le débat sur les commentaires. Il y a déjà une discussion de cet ordre dans la rubrique générale développement.

A quoi cela sert ci ce n'est qu'à comprendre le code écrit?

Du point de vue du développeur, il faut te dire que ce que tu sembles considérer comme "la cerise sur le gâteau" est un besoin primordial!

Si l'on fait exception de quelques code "d'essais" qui te permettent de comprendre un principe et que tu oublies sans vergogne une fois que le principe est assimilé, il faut te dire qu'un code est beaucoup plus souvent analysé, relu ou modifié qu'il n'est écrit ou compilé.

Il faut déjà partir du principe qu'un code n'est sans doute jamais parfait dés sa première version:

• Tu peux avoir oublié une vérification qui, dans certaines conditions bien particulières, aura (dans le meilleur des cas) pour conséquence d'obtenir des résultats aberrant
• Tu peux avoir suivi une logique "sub optimale" qui occasionne une perte inacceptable de performances
• Tu peux vouloir faire évoluer ton code afin de prendre en compte de nouveaux besoins,
• j'en passe et de meilleures...

Si tu n'est pas en mesure de comprendre facilement le code qui t'es présenté, tu perdras énormément de temps lorsqu'il s'agira d'apporter des modifications, dont certaines seraient pourtant triviales.

Tout ce qui aura pour finalité de permettre au lecteur d'un code de le comprendre facilement doit donc être considéré comme primordial.

Lorsque tu codes quelque chose, tu dois veiller, dans l'ordre:

1. à ce que le code soit lisible et compréhensible
2. à ce que le code fasse ce que l'on attend de sa part
3. à ce que le code soit efficace.

Tu me demanderas sans doute pourquoi je le met dans cet ordre particulier, alors que ce qui importe au final est que le code soit efficace

La raison est bien simple : Un code qui ne fait pas ce qu'on attend de sa part n'a aucun intérêt, mais, si, en plus, il n'est pas facilement compréhensible par celui qui doit le modifier, il devient très difficile de le modifier afin qu'il finisse par faire ce qu'on attend de lui.

De la même manière, pour pouvoir rendre un code efficace, il faut être en mesure de comprendre ce que fait le code inefficace afin de déterminer l'endroit spécifique où la logique mérite d'être modifiée afin d'améliorer les performances.

Si tu n'est pas en mesure de comprendre le code, tu ne seras d'office pas en mesure de trouver les points de la logique qu'il te faut envisager de modifier

Les failles de certains logiciel sont-elles dues à la qualité du code ? Et donc du développeur?

De manière générale, 100% des failles ont pour origine l'interface entre la chaise et le clavier .

Il serait malhonnête de dire que toutes les failles sont exclusivement dues au "pauvre malheureux" qui a écrit le code car l'origine même des failles est particulièrement variée: Elles peuvent être dues au protocole utilisé, à une mauvaise analyse des besoins, à des erreurs de conception ou à de vrais problèmes au niveau de l'implémentation.

Une chose est sure, il sera particulièrement facile de taper sur la tête de celui qui s'est chargé de l'implémentation (car c'est en définitive celui qui concrétise l'ensemble du processus), mais ce n'est pas forcément pour cela qu'il est le responsable réel de l'une ou de l'autre faille


Cependant, une chose est certaine : il sera très certainement beaucoup plus facile d'obtenir un résultat "sans faille" si le code est compréhensible que s'il est plus ou moins obscure:

Non seulement la revue de code en est simplifiée, ce qui tend à permettre le repérage des failles éventuelles plus facile, mais la correction des failles réelles s'en trouve également simplifiée (car il est plus facile de déterminer à quel endroit agir pour y remédier).

En résumé, le développement de manière générale est une forme d'art dans laquelle on doit régulièrement composer avec de nombreux aspects, parfois antagonistes.

Nos ainés ont très tôt commencé à énoncer des "bonnes pratiques" dont certaines sont toujours d'application plus ou moins strictes, et dont d'autres n'ont simplement plus de raison d'être étant donné la manière dont le développement est actuellement envisagé.

Certaines "bonnes pratiques" sont un peu plus récentes, et il est difficile de prédire les canons au travers desquels on jugera qu'une application est "bien programmée" d'ici cinq, dix ou quinze ans.

Mais une chose est sûre : tout tournera (au niveau du développeur) toujours autour de la lisibilité du code et de la facilité avec laquelle il sera en mesure d’appréhender l'ensemble de la logique d'un code qu'il rencontre pour la première fois.

On ne peut pas forcément garantir qu'un code "bien écrit" sera exempt de tout problème, mais on peut en tout cas garantir qu'il sera beaucoup plus facile de résoudre les problèmes qui ne manqueront pas de se présenter si le code est "bien écrit" que s'il est mal écrit

[ManusDei]

A quoi cela sert ci ce n'est qu'à comprendre le code écrit?

Je rajoute une chose au long (et plus c'est long, plus c'est bon) message de koala01.

Le code que tu écris aujourd'hui, c'est probablement quelqu'un d'autre qui le modifiera dans 3, 4 ou 10 ans. Si il perd du temps à chercher à comprendre ce qui se passe, c'est son problème, c'est vrai (mais c'est pas sympa).

Mais si par hasard il arrive à te retrouver, il pourrait bien te tenir la jambe pendant quelques heures pour que tu lui expliques à quoi sert cette fonction dont tu n'as aucun souvenir, alors que tu as un truc urgent à finir.

Je conclurais par "Le code, c'est comme les toilettes, tu le laisses en sortant comme tu aimerais le trouver en entrant."

[Médinoc]

D'ailleurs, rien qu'au bout de six mois/un an maximum à bosser sur autre chose, si tu reviens sur ce programme tu es ce "quelqu'un d'autre".