Discussion :

[Matmal11]

Bonjour,

Je suis actuellement sur un projet interne de mon entreprise où j'ai des spécifications fonctionnelle sur mon application.

Avec l'objectif de dévellopper un système performant, tant au niveau du traitement des données que de la maintenance, je voudrais savoir s'il existe des normes de programmation générales.

Par exemple:
- Nombre de caractères max d'une ligne
- Nombre de lignes d'une classe (dans le cas du java ou de perl par exemple)

Je sais que chaque language est différent et que sans doute il n'existe pas de normes générales.
J'ai déjà travaillé sur d'autre projets où les "normes" étaient en fait des spécifications propres à chaque projet.

L'objectif pour moi serait d'avoir une idée, savoir s'il existe quelquechose ou si je doit me créer mes propres spec.

Merci d'avance.

Mat

[lykim1982]

salut,
commence par codé avec une norme.
bonne chance
voici un petit exemple de celui de mon entrepris :

3.1.2. Les variables
Le nom d'une variable est composé selon la nomenclature suivante :

i_tVariableName
Le préfixe « i » désigne l’indicateur de portée.
g : variable locale à une application
s : variable locale à un module.
p : variable passée en paramètre d’une fonction ou d’une méthode de classe.
« t » représente l’indicateur de type de la variable. On utilisera les indicateurs de type définis en annexe (cf. § Annexe 1). Pour les types non répertoriés en annexe ou les types propriétaires, inventer un indicateur de type parlant ou bien supprimer l’indicateur de type (conserver les préfixes pointeurs et tableaux).
« VariableName » est le nom de la variable. Ce nom, écrit en anglais, doit permettre de déterminer ce que la variable représente. Il est composé d’un ou plusieurs mots en minuscule commençant par une majuscule.

Notes :
Les variables doivent obligatoirement être initialisées à une valeur par défaut lors de leur déclaration.
Les membres de classe doivent être obligatoirement initialisés dans tous les constructeurs de la classe.

Exemples : int i = 0 ;
char *pszText = NULL ;
bool bTest = false ;

Les variables locales
Les variables locales à une fonction ou une méthode de classe ne possèdent pas d’indicateur de portée. Certaines variables, tels les indices de boucle, ne sont pas soumis aux règles d’identification des variables.

Exemples : int i = 0 ;
char *pszText = NULL ;

Les pointeurs
Si une variable est un pointeur, on ajoute le préfixe « p » à l’indicateur de type de la variable.
Exemple : long *plValue = NULL ;

Les tableaux
Si une variable est un tableau, on ajoute le préfixe « a » à l’indicateur de type de la variable.

Exemple : long alValues[100];

Les constantes
Si une variable est constante, on ajoute le préfixe « k » à l’indicateur de type de la variable.

Exemple : const long klValue = 10;

Les membres de classe C++
Le nom d’un membre de classe C++ est préfixé par l’indicateur de portée « m ». Si le membre de classe est statique, l’indicateur de portée devient « s ».

Exemple : class CMyClass {
protected :
long m_lMember ; // membre de classe
long s_lCount ; // membre de classe statique
} ;

Eviter au maximum les membres de classe publics. Privilégier des membres privés ou protégés et définir des accesseurs associés.

Exemple : class CMyClass {
protected :
long m_lMember ; // membre de classe
long s_lCount ; // membre de classe statique
public :
long GetMember()
} ;
long CMyClass ::GetMember()
{
return m_lMember ;
}

[nikko34]

salut,
commence par codé avec une norme.
bonne chance
voici un petit exemple de celui de mon entrepris :

et tu te retrouves avec du code genre:

Code :

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

1
2
std::string strMaStr = "";

Je partage ta douleur.

une vieille norme C adaptée vite fait au C++, c'est à fuir.

[koala01]

Salut,

De manière tout à fait générale, on peut estimer que:

1. 80 colonnes par ligne, c'est amplement suffisant
2. plus de 50 linges par fonction, ça commence vraiment à faire beaucoup
3. les noms (de variables, de fonctions, de type...) doivent être explicites
4. il vaut mieux préférer un codage "verbeux" (if(ptr==NULL) de préférence à if(!ptr) )
5. les représentations de noms doivent être fortement codifiée (présence de majuscule à certains endroits...)
6. Les notations hongroises et autres similaires sont généralement de nature à embrouiller plus qu'elles n'aident à la compréhension
7. Les commentaires "utiles" sont importants, mais il est préférable d'éviter ceux qui n'apportent rien

Le (1)et le (2) peuvent demander quelques explications:

Typiquement, les différentes consoles permettent de travailler sur 25 lignes de 80 colonnes, et il existe même des langages qui considère tout ce qui se trouve au-delà de la colonne 80 comme des commentaires (COBOL, par exemple)

Le fait de limiter le nombre de colonnes, outre le fait d'éviter qu'une partie ne soit considérée comme un commentaire, permettra d'éviter un affichage sous la forme de

Code :

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

1
2
                                                                          int la
variable;

(alors que le terme est lavariable), et le fait de limiter à 50 lignes permettra de ne nécessiter que deux "pages" pour avoir un aperçu de la fonction complète... ce qui en soit est déjà beaucoup

Pour ce qui est des commentaires, les commentaire utiles pourraient être

Code :

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

1
2
3
4
5
6
7
/* La fonction qui fait ...
 * @ in: argument1: (utilité)
 *       argument2: (utilité)
 *     ...
 * @ out: valeur renvoyée
 */

parce qu'il permettent de comprendre "facilement" ce qui est fait.

Par contre un commentaire inutile est du genre de

Code :

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

1
2
3
if(a>0) //si a est plus grand que 0
    a++; //on incrémente a

car il n'apporte aucune information pertinente: peut être aurait-il eu sa raison d'être si on avait précisé pourquoi a doit être plus grand (ou plus petit ou égal) à 0, mais ce n'est pas le cas...

J'aime particulièrement l'échelle de goret, même si je laisse à chacun le droit de ne pas être d'accord avec les points de vues exposés

[nikko34]

les 80 colonnes par lignes, en 2007, avec les langages modernes, les IDE modernes et les écrans modernes, je préfère que ça soit purement indicatif et pas du tout une obligation à respecter à la lettre.

Ne pas faire de longues lignes, certes, mais si on dépasse de 10 caractères... et bien tant pis, c'est pas grave.

Si dans les règles de codage il y a marqué qu'il faut utiliser une notation hongroise super verbeuse et en plus une limitation sur la longueur des lignes, plus des indentations/ajout d'espaces pas toujours heureux, ya moyen que les développeurs pètent un cable.

[koala01]

Penses quand même aussi au fait que de nombreux code sources risquent d'être imprimés...

Comme les polices utilisées dans ce cas sont souvent à taille fixe (un "i" prend la même largeur qu'un "u"), souvent imprimés en taille 10 ou 12, l'écran n'est qu'à titre indicatif, mais le raisonnement peut très bien être suivi pour ce qui est de l'impression...

Le problème devient en outre de plus en plus criant si l'on décide, afin d'économiser le papier, d'imprimer deux pages sur une feuille A4 (en recto/verso, cela nous permet l'obtention d'un bouquin très sympa )

Tu remarqueras en outre que, de mon côté, et bien que je ne l'ai pas dit explicitement, je déconseille fortement la notation hongroise (ben voila... c'est fait maintenant )

Et j'ai en outre oublié de parler d'une indentation rigoureuse, qui permet de repérer rapidement les différents blocs d'instructions

[Luc Hermitte]

a- les 80 colonnes par lignes, en 2007, avec les langages modernes, les IDE modernes et les écrans modernes, je préfère que ça soit purement indicatif et pas du tout une obligation à respecter à la lettre.

b- Si dans les règles de codage il y a marqué qu'il faut utiliser une notation hongroise super verbeuse et en plus une limitation sur la longueur des lignes, plus des indentations/ajout d'espaces pas toujours heureux, ya moyen que les développeurs pètent un cable.

a- Cela continue a voir des avantages certains :
- pouvoir splitter verticalement son éditeur pour avoir le .h à droite, le .cpp à gauche, et éventuellement d'autres colonnes pour d'autres choses
- L'impression n'est pas saccagée, et le rendu final sera homogène quelque soit le source imprimé (toujours la même taille de police)
- Certains outils ne gèrent pas super bien les dépassements (je pense à doxygen)

Et de toutes façons, avec un éditeur intelligent capable de replier le code, il est toujours possible de se rajouter des replis customisés qui vont condenser sur une même ligne tous les arguments d'un appel un tant soit peu long.

b- Ne confondez pas la notation hongroise avec ce qu'elle n'est pas.
http://www.joelonsoftware.com/articles/Wrong.html
Dans les langages trop faiblement typés, ou quand on n'a pas envie de définir un type pour chaque entité numérique (ligne, colone), ou quand on manipule une même chose mais typée différemment (entier, enum, chaine native, chaine corba, ...), la notation hongroise a son intérêt.
Il ne faut pas la rejeter d'emblée pour cause d'abus massif suite à mauvaise compréhension généralisée.

[befalimpertinent]

1. plus de 50 linges par fonction, ça commence vraiment à faire beaucoup
2. il vaut mieux préférer un codage "verbeux" (if(ptr==NULL) de préférence à if(!ptr) )

Je suis tombé par hasard sur cette vielle discussion et je dois dire que je suis moyennement d'accord avec les points cités plus haut.
Si tu écris une fonction qui dépasse les 50 lignes, que faire ? Découper cette fonction en sous-fonctions? Si c'est la solution choisie (je n'en voit pas d'autre à vrai dire), le risque est de se retrouver avec des fonctions qui n'auront de sens que dans le code l'appelant. On perd alors le sens même d'une fonction car celles-ci ne seront probablement jamais utilisé en dehors de ce découpage. Et qu'apporte une fonction si elle n'est pas réutilisable ? Ajouté à cela le surcout dû aux passages des paramètres.Non vraiment à mon avis tant pis pour la fonction trop longue mais si elle est bien écrit le nombre de ligne importe peu.

Pour le second point, je ne suis pas d'accord avec l'exemple choisi : pour moi il vaut mieux toujours tester la validité d'un pointeur de cette façon

Code :

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

if(!ptr)

En effet, qui te dis que quelqu'un d'autre (qui a dit ?) n'a pas redéfini #define NULL=1 quelque part dans le code.

[souviron34]

Pour le second point, je ne suis pas d'accord avec l'exemple choisi : pour moi il vaut mieux toujours tester la validité d'un pointeur de cette façon

Code :

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

if(!ptr)

En effet, qui te dis que quelqu'un d'autre (qui a dit ?) n'a pas redéfini #define NULL=1 quelque part dans le code.

2 raisons :

1) le compilateur (bien réglé) le dira, et même sans être bien réglé risque de refuser la compil

2) tout simplement parce que l'opérateur "!" est un opérateur logique, fonctionnant sur le RESULTAT d'une opération ou d'un test... Et que (et c'est encore plus vrai en C99) un pointeur PEUT ne pas entrer dans la catégorie des choses testables.

Et il y a BEAUCOUP plus de chances d'être dans ce cas-là que dans le cas de la re-définition de NULL..

Et c'est une TRES mauvaise habitude à prendre que de ne pas tester par rapport à l'erreur attendue...

Un exemple :

un CERTAIN nombre de fonctions de la lib C renvoie 1 pour succès, 0 pour erreur. D'AUTRES renvoient 0 pour succès, 1 pour erreur...

[millie]

Et qu'apporte une fonction si elle n'est pas réutilisable ?

Cela ajoute de la sémantique à ton code. Donc une meilleure maintenance.

Ajouté à cela le surcout dû aux passages des paramètres.

Pour une fonction longue justement, on peut pas dire qu'appeler une autre fonction soit coûteux par rapport à l'ensemble de la fonction. Et si cette fonction ne sert qu'à découper ta fonction, alors on l'intégre en général dans le même fichier (par exemple en C, on va pouvoir la déclarer static voir l'inliner en C++). Cela ne sert même à rien de présupposer sur ce type d'optimisation car il est possible que la fonction soit intégrée directement à la fonction appelante (donc il n'y aura même pas de passage de paramètre).

Il vaut toujours choisir la solution la plus maintenable. Et si ta fonction est réellement un goulot d'étranglement, alors il faudra revoir.

[GnuVince]

Bonjour,

Je suis actuellement sur un projet interne de mon entreprise où j'ai des spécifications fonctionnelle sur mon application.

Avec l'objectif de dévellopper un système performant, tant au niveau du traitement des données que de la maintenance, je voudrais savoir s'il existe des normes de programmation générales.

Par exemple:
- Nombre de caractères max d'une ligne
- Nombre de lignes d'une classe (dans le cas du java ou de perl par exemple)

Je sais que chaque language est différent et que sans doute il n'existe pas de normes générales.
J'ai déjà travaillé sur d'autre projets où les "normes" étaient en fait des spécifications propres à chaque projet.

L'objectif pour moi serait d'avoir une idée, savoir s'il existe quelquechose ou si je doit me créer mes propres spec.

Merci d'avance.

Mat

Lis "Perl Best Practices" par Damian Conway. Tous les points sont abordés en profondeurs. Beaucoup sont également transférables à d'autres langages.

[le Daoud]

Tu as les normes de Sun qui ont l'avantage d'être présentes sur beaucoup de projets. Pour t'assurer que tu es conforme tu peux utiliser checkstyle.

[souviron34]

Tu as plusieurs discussions traitant de règles simples :

http://www.developpez.net/forums/sho...d.php?t=387695

http://www.developpez.net/forums/sho...d.php?t=376119

Il y en a d'autres aussi..

[_vince_]

Bonjour,

Je suis actuellement sur un projet interne de mon entreprise où j'ai des spécifications fonctionnelle sur mon application.

Avec l'objectif de dévellopper un système performant, tant au niveau du traitement des données que de la maintenance, je voudrais savoir s'il existe des normes de programmation générales.

Par exemple:
- Nombre de caractères max d'une ligne
- Nombre de lignes d'une classe (dans le cas du java ou de perl par exemple)

Je sais que chaque language est différent et que sans doute il n'existe pas de normes générales.
J'ai déjà travaillé sur d'autre projets où les "normes" étaient en fait des spécifications propres à chaque projet.

L'objectif pour moi serait d'avoir une idée, savoir s'il existe quelquechose ou si je doit me créer mes propres spec.

Merci d'avance.

Mat

Meme si le sujet est un peu vieux, il sera toujours d'actualite.

Une norme peut etre ecrite dans les specifications, mais si les developpeurs ne l'acceptent pas, il ne l'utiliseront pas. On n'impose pas une norme a des programmeurs. Si norme il y a, elle doit etre ecrite par les developpeurs eux-memes.

Je pense qu'imposer un nombre de lignes ou de caracteres n'est pas tres utile. Une norme n'est qu'une petite partie de ce qu'on peut specifier pour avoir un code de qualite, qui je pense est le but recherche.

Mais pour faire court, voici quelques idees a la volee:

a) L'important est que le code soit lisible, i.e. n'importe qui doit pouvoir comprendre les intentions du programme, ce qu'il doit faire et la facon dont il le fait. Et tout ceci seulement en lisant le code, avec des commentaires pour renvoyer le lecteur a des documents papier pour les details.

b) le programme doit etre facilement maintenable. Eviter les copier-coller a travers tout le projet. Eviter de faire la meme chose ecrite de manieres differentes, etc.

c) Mettre un peu de programmation defensive pour que le programmeur se protege contre ses propres betises. Un des plus gros "bug" est le programmeur trop optimiste qui n'utilise aucune assertion pour verifier la logique de son programme.

d) je recommende la lecture de "tout sur le code" de steve mcconnel. Tous les programmeurs devraient le lire. Ca eviterait beaucoup de bugs.

En esperant que ca serve a quelqu'un...

[ib_issa]

bonjour à tous

Il y a pas tellement de norme en soit. Le principale c'est de se faire comprendre rapidement par soit même et par les autres.
Maintenant, j'en vois beaucoup qui tombe dans l'extrémiste ce qui à pour conséquence que le code devient indigeste avec des commentaires complètement inutiles, perte de temps. La personne qui va relire après n'est pas un golio normalement. Il doit faire aussi un minimum d'effort car il y a beaucoup de bon sens. Car la lecture du code se fait dans 98% des cas en diagonal. Il faut surtout des marqueurs visuel pour attirer l'attention.

je suis d'accord avec "berceker united"

[Mat.M]

Bonjour,

Je suis actuellement sur un projet interne de mon entreprise où j'ai des spécifications fonctionnelle sur mon application.

Avec l'objectif de dévellopper un système performant, tant au niveau du traitement des données que de la maintenance, je voudrais savoir s'il existe des normes de programmation générales.

Par exemple:
- Nombre de caractères max d'une ligne
- Nombre de lignes d'une classe (dans le cas du java ou de perl par exemple)

Mat

Si tu te préoccupes de savoir combien il ya de caractères max par ligne là tu est parti pour faire un projet Titanic et dépasser les délais faut faire attention.
Et tu risques de provoquer les ires de ton chef de projet...
Il ya plus essentiel dans un projet que de se demander si la syntaxe est bien académique...
D'accord faut faire un code propre et un minimum documenté mais faut pas pinailler non plus.

Cela relève du bon sens faut pas faire des lignes à rallonge.
Pour les classes s'il ya trop de lignes c'est que la conception est mauvaise il faut la refaire en UML par exemple ou simplement sur papier..

[Immobilis]

Salut,

Autant que possible:

• Factoriser à partir du moment où on fait appel plus d'une fois à une instruction. Ca parait logique mais bon.
• Programmer de manière fonctionnelle plutôt qu'impérative.
• Etre explicite = ne pas executer un morceau de code sur des variables dont on sait qu'elles existent parce qu'on n'est jamais sur de rien.
• N'utiliser que ce dont on a besoin au moment où on en a besoin.
• Ne pas trop en demander. De toutes façons, d'après le lien du post précédent, 80% des traitements effectués sont contenus dans 20% d'un programme.
• Ne pas réinventer la roue.

En programmation objet je me suis rendu compte qu'on les utilises (les objets métiers) parfois à tords. Ex: Je veux une liste (nom, prénom) de tous les utilisateurs de mon application. Est-il bien raisonnable de monter une collection d'objets "Utilisateur" et la parcourir pour en extraire les informations qui nous interessent parmis des dizaines d'autres? Un simple "SELECT NOM, PRENOM FROM UTILISATEURS" suffit.

En ce qui concerne la conception, je n'arrive pas à me servir d'UML (jamais eu de formation ni pris le temps de travailler là dessus). Je me débrouille et fais beaucoup de dessins jusqu'à ce que je vois bien les pièces du puzzle. Ca doit surement avoir ses limites.

Sinon, j'ai quitté une boite il y a quelques mois dans laquelle on travaillait sur le transcodage (ASP3 => ASP.NET) d'une appli web de gestion de documents et de données financières que j'avais faite.

Le projet a commencé en septembre 2006 et devait durer 3 mois. Il n'est toujours pas livré... Bon, il faut dire qu'entre temps le projet s'est transformé en une refonte (c-a-d repart à zéro sans tenir compte de l'existant). Aux dernières nouvelles l'ancien, qui devait être remplacé début 2007, est toujours en place.

Je dirais que le secret de la première version réside dans le fait que le responsable fonctionnel savait exactement ce qu'il voulait et l'expliquait clairement. On a même travaillé sans cahier des charges! J'étais le seul informaticien. Nous avons procédé par lots sur presque deux ans (en commençant sur Access). Les fonctionnalités se sont ajoutées les unes aux autres. Ce n'est pas non plus un site très volumineux mais plus d'une centaine de personnes l'utilisent sur 3 ou 4 pays.

Par la suite ça a été différent... Moralité: chi va piano, va sano e va lontano.

Sinon, je teste actuellement FXPRO qui valide un certain nombre de règles de codage.

Quelqu'un a-t-il un retour d'experience sur la loi de Demeter? Pas facile à saisir mais une architecture mulitiers serait-elle issue de cette loi? Une application web s'adresse aux objets métier qui s'adresse aux objets d'accès aux données.

A+