Discussion :

[MonsieurAk]

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.

[anadoncamille]

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 :

Code :

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

maFonctionQuiFaitCa(int variableQuiVientDeLa)

Pour les constantes :

Code :

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

MA_CONSTANTE_QUI_BOUGE_PAS

Le plus possible, je donne des noms explicites aux variables et noms de fonction, même si je pioche joyeusement dans le franglais.

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 ( ) {
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 !

[capucine1983]

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.

[kossistus]

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 :

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

1
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.

[souviron34]

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.

Bonjour

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à.

[d'Oursse]

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]

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.

Ceci ne rentre pas vraiment dans les conventions de codage, mais ça l'avantage de forcer à concevoir l'application pour qu'elle soit facilement testée (et ça peut être un grand plus).

En C++, il y a également cppUnit et cxxUnit.

En Java, il y a évidemment Junit.

[d'Oursse]

@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

[sylvain giardini]

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