Version imprimable
Bonjour
Je voulais savoir/sonder les personnes qui développent des logiciels, drivers, etc. à propos des règles de codages.
Est ce que vous vous imposez de telles règles ?
Vérifiez vous vos sources ?
Vous le faites comment ? Par des outils automatiques ? lesquels ?
Merci.
Salut,
je développe seul un gros projet depuis plusieurs années en Java, AnAcondA, et je m'impose le moins de règles possible.
Cependant, je respecte la syntaxe Java pour les noms de variables et de fonctions :
Pour les constantes :Code:maFonctionQuiFaitCa(int variableQuiVientDeLa)
Le plus possible, je donne des noms explicites aux variables et noms de fonction, même si je pioche joyeusement dans le franglais.Code:MA_CONSTANTE_QUI_BOUGE_PAS
Pour les commentaires, je suis un affreux et je ne prends pas le temps d'en faire, c'est pour ça que je fais très attention aux deux règles précédentes. Les rares commentaires que je fais (dans mon projet) sont pour signaler des bouts de code non fonctionnels ou provoquant une erreur.
Je vérifie mes sources uniquement par relecture, je n'utilise aucun outil automatique pour le faire, si ce n'est le compilo pour vérifier que le code fonctionne.
Pour la conception objet, je fais des objets les plus petits possibles, je fais parfois des objets providers de services qui sont alors assez gros mais dans l'ensemble, un objet dépasse rarement les 50-100 lignes de code. Du coup j'ai plusieurs centaines d'objets dans mon projet.
Je fais une réutilisation maximale, mais si un nouvel objet a des besoins qui ne collent pas avec l'ancienne signature, je crée un nouvel objet.
Et dans l'ensemble, pour vérifier mon code, j'utilise l'outil suivant :
while (:bug: ) {
je teste, je reteste, je fais tester par mes proches.
Et justement, c'est quand on fait tester par des proches qu'on voit le plus de bugs, car ils utilisent le projet différemment, leur approche ne les fait pas agir de la même façon que nous développeurs et apparaissent alors les bugs de conception.
}
Et si je sors de cette boucle c'est la fête ! :yaisse2:
Bonjour
moi pareil je développe en Java
Alors ce qu'il faut surtout faire c'est utiliser des variables bien définies afin de comprendre de quoi il s'agit si on relit plus tard ou autres.
A chaque mot on commence par une majuscule et on sépare par le tiret.
Sinon les commentaires tres important,car un code doit etre lisible et compréhensible pour n'imort qui le lit.
Sinon pour la source je vérifie en compilant et exécutant jusqu'à ce que je n'ai plus d'erreur.
Bonjour,
je developpe aussi en java. Et je m'efforce outre de commenter mes méthodes
de donner des noms significatifs, tout en separant par des majuscules les noms Different. Classe EtatInitial, méthode trouverUnElement() ... exple
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
class MaClasseExemple{ //atttribut static static int iChoix; //puis attributs de classe int unAttribut; // mais une utilisation en locale serait int iUnAttribut boolean estUnAttribut; String arTab[] ; //méthodes static //méthodes de classe //et enfin les constructeurs }
C'est au moins important que les nom de methodes disent ce qu'on veut qu'elles fassent.
BonjourCitation:
Envoyé par MonsieurAk
Je dirais que tout bon programmeur, quel que soit le langage utilisé, doit suivre des règles de codage (et pas seulement de codage, mais de logique et de bon sens aussi).
On ne suit pas les mêmes règles lorsqu'on code un projet de 500 lignes ou de 500 000 lignes...
En général, il est convenu de :
- utiliser des variables avec des noms explicites
- utiliser des fonctions/procédures/méthodes avec des noms explicites
- utiliser des """""""""" avec des préfixes différents par projet
- utiliser des majuscules pour les constantes
- utiliser des noms de fichiers explicites, avec éventuellement des préfixes différents par projet
- séparer en répertoires "fonctionnels" les fichiers (exemple : bin, src, doc, ou bien src/general, src/db, src/metier, src/interface, doc/html , ...
Vérification des sources : oui, mais par tests. Je n'ai jamais utilisé d'outil automatique, et je n'y crois pas. La programmation de grosses applications est trop subtile pour être "automatisable". Et donc pour la vérification, à part la mise de tous les flags de warnings à la compilation, il n'y a que le test..
En ce qui concerne les tests, un très bon "dépucelage" m'a été fourni lors de l'approbation officielle d'un logiciel pour la santé par un responsable des applications agréées. En ce qui concerne les logiciels avec IHM, le premier des tests est de soumettre l'appli à une manipulation "à l'aveugle" pendant une demi-journée : on lance l'appli, on ferme les yeux, et on clique n'importe où ou on appuie sur n'importe quelle touche du clavier, dans n'importe quel ordre... Si on passe ça sans crash, on a passé l'étape de robustesse, la fonctionalité n'étant plus qu'une mise au point. Et pour le reste des tests, mettre une série d'utilisateurs : il est certain qu'il n'utiliseront pas le logiciel tel que vous l'avez utilisé (même pendant les phases de test interne, automatique ou non). 99% des bugs resssortiront à ce moment là.
pour les tests d'une bibliotheque, les unit tests sont assez interessants. Ils permettent de tester le code lorsque des modifications de code importantes ont ete faites, tout en voulant conserver le meme comportement.
Sous linux, en C, la bibliotheque check aide a les ecrire simplement. Je ne sais pas si elle fonctionne sous windows. En c++, on peut utiliser boost::test, par exemple.
Avec gcc, on peut utiliser gcov pour voir si les unit tests ont utilise toutes les fonctions de la bibliotheque. On peut l'utiliser avec lcov pour avoir une jolie sortie en html.
@millie: certe, mais je repondais aux questions "Vérifiez vous vos sources ?
Vous le faites comment ? Par des outils automatiques ? lesquels ?" posees par l'auteur du thread
Dans un service de dévellopement mieux vaut imposer des règles de DEV.
Pour que n'importe qui reprendre facilement le Soft de QQ d'autre .
Les règles concernent essentiellement les noms des variables et
la structuration des prgs, et le suivi des versions .
Après reste a respecter un minimum de mise en page ds le code
tests etc........
et voili et voila
Nous développons à plusieurs un site web php/pgsql.
Nous avons des règles surtout au niveau de la nomenclature de nos variables, faisant le projet en objet, le php étant un langage peu typé, nous avons une espèce de notation hongroise inversée.
Pour le reste, je pense que si tu développe avec des gens un tant soit peu consciencieux, tu n'as pas besoin de règles, tout le monde est à même de comprendre qu'un code doit être clair et commenté (enfin je pense :))
Certes cela s'appelle du bon sens et c'est une évidence.Citation:
Envoyé par Linio
Mais qu'en est-il lorsque ce "tout le monde" est une population d'ingénieurs plus ou moins expérimentés, venant d'horizons différents et dont une partie sont des consultants de SII intervenants pour des missions à durée variable ?
Comment s'assurer de la qualité du code produit, surtout comment garantir la maintenabilité et la pérennité de l'application au fil du temps.
La mise en place de règles de codage est un bon indice du niveau de maturité d'une équipe (ou d'un service) de développement logiciel.
Mais qui dit règle de codage dit relecture et reprise du code.
On en revient toujours à la même question (à laquelle très peu d'ingénieur savent répondre), qu'elle est le coût de la ligne de code que je produis (je sais cela peut sembler un peu mercantile) quel est le niveau de qualité exigé de l'application que je développe ?
Voilà qui est simplement résumé...Citation:
Envoyé par sylvain giardini
Si l'on parle de développement en mode artisanal on peut considérer que la mise en place de règle de codage est un surcoût qu'il est difficile de faire accepter par les responsables. On se contente donc bien souvent du bon sens et de l'expérience des intervenants pour ne pas coder avec leurs pieds.
Par contre si l'on parle d'ingénierie logiciel au sein de services comptant plusieurs dizaines d'ingénieurs travaillant des projets de 6 mois à 3 ans nécessitant des garanties de maintenance et des certifications il va de soi que la mise en place de règles de codage est obligatoire.
Le plus difficile restera de rédiger ces règles, les faire appliquer et s'assurer qu'elles sont bien appliquées.
Une bonne façon de se mettre le pied à l'étrier est de s'inspirer de certains standards de l'industrie (à titre d'exemple : MISRA-C ou C++, on retrouve pas mal de tentative de standardisation pour beaucoup de langages) ou de faire appel à une société d'ingénierie spécialisée dans la qualité du logiciel (certification CMM ou autre).
Et dans ce cas cela a un coût qu'il faut prendre en compte dans la production.
Pour répondre à la question du post : nous avons en projet d'acquérir un outil de vérification automatique (Logiscope de Telelogic) qui permet de rédiger ses propres règles. Ce qu'il faut savoir c'est que ce n'est pas forcément l'outil qui est le plus couteux mais la mise à niveau des équipes et la mise en place du process qui doit te garantir que l'outil est utilisé, des métriques pour mesurer l'amélioration effective de la qualité du code et surtout essayer de fournir un ROI valable à ta direction. Cet outil concerne une population de plus de 60 ingénieurs, les règles de codage sont en cours de rédaction et je peux te dire que cela ne se fait pas en quelques jours. Nous avons bon espoir de tout déployer d'ici la fin de l'année 2007.
j'ai développé tout l'été dernier en WinDev 10, et il permet de mettre en place une chartre de programmation, ce qui fait que si tu déclares un entier, le prefixe va automatiquement se mettre:
le_entierLocal est un entier
lb_booleenLocal est un booleen
lc_chaineLocale est une chaine
C'est bizare au début mais c'est sympa pour relire et débugger, on se prend moins la tête pour savoir si un entier est local ou global par exemple.
Je vous encourage à regarder de plus prêt cette plateforme ultra puissante.
Citation:
Envoyé par j14z
Je ne vois pas trop l'intérêt de forcer les variables à avoir ce genre de nom :? Maintenant, avec les EDI qu'ils nous sortent, il suffit de mettre le curseur sur la variable pour voir le type ou retrouver tout de suite la définition.
De toute façon, il y a des noms qui "imposent" presque le type :
n, m, i, j, k, size pour des entiers
s, nom, prenom pour des chaines
isOpen, isConnected pour des booléens...
Salut,
Pour ma part, j'estime qu'il y a trois grosses idées qu'il faut garder en permanence à l'esprit:
- La complexité d'un projet est directement proportionnelle (exponentielle :question:) au nombre de gens qui interviennent dedans... la souplesse des règles doit diminuer en conséquence si elles ne sont pas dés le départ extrêmement rigides
- Un code est plus souvent lu qu'il n'est écrit: ce que l'on écrit aujourd'hui et qui nous semble si limpide ne le sera peut être pas forcément dans une semaine
- On passe généralement plus longtemps à chercher l'endroit où quelque chose cloche dans le code qu'à résoudre le problème
Partant de là, je n'hésite que peu à élever ce que d'aucun appellent tout simplement "le bon sens" au niveau de règles... Mais je les applique généralement sans même devoir y penser:
- j'utilise des noms (de variable, de fonction, de type...) qui décrivent le mieux possible l'usage qui en est fait tout en veillant quand même à garder une taille "raisonnable" dans ceux-ci (le risque de faute de frappe augmentant avec le nombre de lettre nécessaire pour désigner quelque chose... Même si l'auto-complétion est d'un grand secours ;))
- je "formate" mes noms:
- les noms de type et de fonction: la première lettre de chaque mot en majuscule (y compris la première lettre du premier mot)
- les noms de constante en majuscule
- les noms de membre en minuscule
- pas de notation "hongroise"
- je veille à ne faire qu'une "chose" par ligne: trois déclarations de variables (éventuellement avec leur initialisation ) = trois lignes
- je veille à une identation correcte et cohérente: le fait de pouvoir repérer facilement les différents blocs d'instructions facilite énormément les choses à mon gout ;)
Par contre, je reconnais volontier que je ne mets sans doute pas assez de commentaires, sauf dans les codes exemples que je fournis (dans lesquels j'en met peut être trop :aie:)
Je code principalement en C++, et je ne vérifie pas la mise en page de mon code autrement qu'à la lecture ;).
Pour ce qui est de l'exécutable, j'organise un "test du singe", mais de manière tout à fait manuelle ;)