Developpez.com

Plus de 14 000 cours et tutoriels en informatique professionnelle à consulter, à télécharger ou à visionner en vidéo.

Qu'est-ce qu'un code "propre" selon vous ?

Le , par brice01, Membre régulier
qu'un code "propre" selon vous ?


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


 Poster une réponse

Avatar de Franck SORIANO Franck SORIANO - Membre expert http://www.developpez.com
le 09/09/2009 à 12:59
Citation Envoyé par hegros  Voir le message
Le code c'est la vraie spécification...exécutable.

Pas vraiment. Les spécifications, c'est ce que tu veux/voulais que le code fasse (ou qu'il aurait dû faire) alors que le code, c'est ce qu'il fait réellement.
Idéalement, lorsque tu livres l'appli finale, les deux devraient dire la même chose.

Mais comment tu fais pour corriger un bug, si le code est ta spécification ? Tu ne peux alors plus savoir que ce que le code fait (en supposant qu'il soit suffisamment lisible), mais pas ce qu'il devait faire !

Je ne vois pas comment un testeur ou quelqu'un d'autre pourrait faire passer des tests unitaires sans avoir accès au code, c'est impossible

Ca c'est parce que pour toi spécifications = code.
Les tests s'établissent à partir des spécifications : Tu vérifies que le code fait bien ce que les specs disaient qu'il devait faire. Si tes specs sont bien définies indépendamment du code, tu n'as pas besoin du code pour savoir ce que tu dois tester.

Par contre, je ne vois pas comment on peut mesurer la couverture des tests par rapport au code, sans voir le code (sous une forme ou une autre).
Avatar de hegros hegros - Membre Expert http://www.developpez.com
le 09/09/2009 à 13:29
Citation Envoyé par Franck SORIANO  Voir le message
Pas vraiment. Les spécifications, c'est ce que tu veux/voulais que le code fasse (ou qu'il aurait dû faire) alors que le code, c'est ce qu'il fait réellement.
Idéalement, lorsque tu livres l'appli finale, les deux devraient dire la même chose.

Tu noteras la nuance tout de même, je parlais de spécification exécutable. Au delà de cela il y a effectivement tout un tas d'autres spécifications : fonctionnelles, systèmes, techniques, hardware, non fonctionnelle etc etc...

Mais comment tu fais pour corriger un bug, si le code est ta spécification ? Tu ne peux alors plus savoir que ce que le code fait (en supposant qu'il soit suffisamment lisible), mais pas ce qu'il devait faire !


cela dépend si c'est un bug qui touche le fonctionnel ou la technique. Si j'ai un bug parce que j'ai oublié d'allouer un pointeur ou de libérer la mémoire alors la spécification ne me sera d'aucune utilité, de même si j'ai écris a=6 au lieu de a==6 pour un test d'égalité la spécification ne me sert à rien non plus.

Ca c'est parce que pour toi spécifications = code.

non, code = spécification exécutable ce n'est pas toutes les spécifications, ma phrase allait plutôt dans le sens : c'est la seule spécification qui au final compte.

Effectivement tu n'as pas besoin de code pour écrire un test unitaire je pense que l'approche DDT en est un bon exemple par la pratique
Avatar de jabbounet jabbounet - Membre expert http://www.developpez.com
le 09/09/2009 à 13:32
Par contre, je ne vois pas comment on peut mesurer la couverture des tests par rapport au code, sans voir le code (sous une forme ou une autre).


c'est pour cela que j'ai dit pas officiellement accès au code....

autrement à l'époque on utilisait cet outil pour les tests unitaire
http://www-01.ibm.com/software/awdto...ime/index.html
Avatar de Nebulix Nebulix - Membre éclairé http://www.developpez.com
le 09/09/2009 à 17:29
Citation Envoyé par jabbounet  Voir le message
là c'est plus un problème de suivi du logiciel.

Donc c'est la faute d'un collègue, pas la tienne
mais
ça ne résoud pas le problème
il est dommage de ne pas prévenir l'incident quand c'est si facile
Avatar de jabbounet jabbounet - Membre expert http://www.developpez.com
le 09/09/2009 à 23:32
Citation Envoyé par Nebulix  Voir le message
Donc c'est la faute d'un collègue, pas la tienne
mais

C'est aussi le tiens, si tu as un rôle quelconque par rapport au devenir de ce logiciel, que ce soit en tant que codeur ou big boss , chaque personne a sa part de responsabilité.
je suis peu être un peu bête mais j'ai horreur de me défausser sur quelqu'un d'autre...

ça ne résoud pas le problème
il est dommage de ne pas prévenir l'incident quand c'est si facile

il est en effet toujours mieux d'anticiper un minimum, cela entre dans le cadre de la gestion des risque, simplement personne n'est parfait et devin.
Avatar de Nebulix Nebulix - Membre éclairé http://www.developpez.com
le 10/09/2009 à 9:25
Citation Envoyé par jabbounet  Voir le message
C'est aussi le tiens, si tu as un rôle quelconque par rapport au devenir de ce logiciel, que ce soit en tant que codeur ou big boss , chaque personne a sa part de responsabilité.
je suis peu être un peu bête mais j'ai horreur de me défausser sur quelqu'un d'autre...


Le style direct d'un forum peut conduire à des incompréhensions. Le "tu" que j'ai employé s'adresse à tout le monde, moi compris. Nous sommes là pour partager nos expériences et améliorer nos pratiques, exprimer des désaccords, pas critiquer des personnes. Si tu t'es senti personnellemnt visé, je te prie de m'excuser.
Avatar de jabbounet jabbounet - Membre expert http://www.developpez.com
le 10/09/2009 à 16:49
Citation Envoyé par Nebulix  Voir le message

Le style direct d'un forum peut conduire à des incompréhensions. Le "tu" que j'ai employé s'adresse à tout le monde, moi compris. Nous sommes là pour partager nos expériences et améliorer nos pratiques, exprimer des désaccords, pas critiquer des personnes. Si tu t'es senti personnellemnt visé, je te prie de m'excuser.

T'inquiete il en faut plus que cela pour me sentir visé . et effectivement avec un forum il manque une bonne partie de la communication que tu peux avoir a l'oral (gestuelle,...)
Avatar de ouhraniufr ouhraniufr - En attente de confirmation mail http://www.developpez.com
le 15/03/2012 à 15:27
Bonjour,
Qui peut me dire, comment peut on améliorer la lisibilité d'un code? je serai très reconnaissante si je trouve une repense
Merci
Avatar de gangsoleil gangsoleil - Modérateur http://www.developpez.com
le 15/03/2012 à 15:58
Bonjour,

Ca depend d'ou tu pars.

Si le code est obfusque et illisible, il faut commencer par le rendre comprehensible : renommer les fonctions, commenter, aerer, ...

Si le code est au contraire lisible et commente, on peut passer a de la doc generee type doxygen, ...
Avatar de el_slapper el_slapper - Expert éminent sénior http://www.developpez.com
le 15/03/2012 à 16:16
Citation Envoyé par ouhraniufr  Voir le message
Bonjour,
Qui peut me dire, comment peut on améliorer la lisibilité d'un code? je serai très reconnaissante si je trouve une repense
Merci


Très bonne question, mais la réponse dépend fortement du langage - et de son état. Je peux te donner des conseils pour du Cobol généré automatiquement(une horreur que j'ai appris à dompter par la force des choses), mais pas pour du java(dont les contraintes structurelles sont radicalement différentes).

Un truc quand même : les tests. Rendre un code plus lisible, c'est prendre le risque de le casser(surtout si on réorganise un boucle qui fait 2 pages et qui tourne sur des GO TO et des compteurs gérés en dur). Donc, avoir une couverture de tests complète, si possible automatique, pour vérifier qu'on ne casse rien. Et avoir les moyens de revenir en arrière(versions, sauvegardes...).
Avatar de koala01 koala01 - Expert éminent sénior http://www.developpez.com
le 15/03/2012 à 18:13
Citation Envoyé par ouhraniufr  Voir le message
Bonjour,
Qui peut me dire, comment peut on améliorer la lisibilité d'un code? je serai très reconnaissante si je trouve une repense
Merci

De manière très générale (car toutes les situations sont différentes), je conseillerais, dans un premier temps:
  1. de choisir des noms explicites (qui indiquent, rien qu'à la lecture, de que l'on fait), en fonction des restrictions imposées par le langage
  2. de respecter des règles strictes de nommages (éviter d'avoir un nom de fonction qui commence par une majuscules et un autre qui commence par une minuscule, par exemple )
  3. d'indenter correctement les différents blocs les uns par rapport aux autres, de manière à pouvoir les repérer
  4. de respecter la règle d'une ligne par instruction
  5. de placer les symboles de blocs (si le langage en définis) même lorsqu'ils ne sont pas requis
  6. de ne pas hésiter à commenter un bloc de code qui serait vraiment trop nébuleux (en veillant cependant autant que possible à décrire la raison pour laquelle on fait quelque chose et non ce que l'on fait )
  7. d'éviter autant que possible les sucres syntaxiques s'ils n'apportent vraiment rien

Dans un deuxième temps, on peut envisager un refactoring au niveau des fonctions en:
  1. séparant correctement les différentes responsabilités de sorte à ce que chaque fonction n'en ai pas plus d'une
  2. factorisant au besoin certains blocs de fonction
  3. essayant d'arriver à des fonctions de "taille acceptable": 20 à 30 lignes ( +/- XX ) par fonction, c'est déjà pas mal
Si le code reste encore nébuleux malgré tout cela, peut etre faudra-t-il refactorer plus en profondeur, mais on entre alors dans un autre débat qui tient carrément de la conception
Offres d'emploi IT
St-conception d'outils de pilotage
Renault - Ile de France - Guyancourt
Chargé de production informatique
Pro-RH - Ile de France - Buchelay (78200)
Chargé d'études risques h/f
DEXIA CREDIT LOCAL - Ile de France - Paris (75000)

Voir plus d'offres Voir la carte des offres IT
Responsables bénévoles de la rubrique Access : Pierre Fauconnier - Arkham46 -