Discussion :

[_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...

[Invité]

J'ajouterais aussi:

• Le livre C++ Coding Standards propse des idées intéressantes, qui vont au-delà de la simple façon de nommer une variable (au passage, la première suggestion est: ne pas normaliser ce qui n'en vaut pas la peine).
• Il faut être prudent de ne pas prendre une norme de codage comme excuse pour laisser la réflexion et le bon sens sur le bord de la route. Une norme de codage n'est absolument pas un garde-fou contre le mauvais code, mieux vaut privilégier la communication entre les développeurs et les revues de code.

Carl

[Sba3Net]

En un MOT :::: ANSI

[berceker united]

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 terminerais aussi par le faite que c'est pas la norme de programmation qui est important mais la logique de développements. Car même si votre code est certifié conforme ISO457892 du code de l'O.N.U et de la sureté nucléaire international en collaboration avec AIRBUS, NASA et LeaderPrice. Si le code n'est pas logique alors ça vaut pas plus que les boites de mon chat de la marque Ronron.


Conseille : Définir un protocole de développement dès le départ. Qu'il soit pas très conforme avec les "dit" norme en vigueur n'est pas grave. Le plus important, c'est que l'application soit du début à la fin se conformer au protocole que vous avez déterminé au départ. Il ne faut pas changer en cour de route.

J'en parle avec expérience car j'ai déjà travaillé avec une équipe qui plaçait des normes stricts mais jamais il parlait d'une logique de programmation commune. Chacun faisait à sa sauce. Finalement, ça nous a pas plus aidé lorsqu'il fallait récupérer le code des autres.
Ma messe est dite

[sleepy2002]

Niveau outil de vérification de normes côté Java, il y a CheckStyle. Dans les EDI, il est bien intégré et son analyze en temps réel permet de corriger rapidement les parties de code non conformes.

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.

La mise en place des tests unitaires (TU) assure une robustesse du code (à condition que leur couverture tente de couvrir 100%, voir API JCoverage ou équivalent). De plus ils guident le nouveau développeur dans la compréhension du code associé.
Enfin des Tests Fonctionnels (TR) sont une garantie supplémentaire.

b) le programme doit etre facilement maintenable.

Cf note sur les TU et TR.

Eviter les copier-coller a travers tout le projet. Eviter de faire la meme chose ecrite de manieres differentes, etc.

Ne pas hésiter à remanier le code (Refactoring en Anglais). Les TU et les TR garantiront la non régression du code.

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

[ZouBi]

Peut on, pour eviter l'encombrement de l'espace noms des variables globles, les utiliser dans un namespace?

[millie]

Peut on, pour eviter l'encombrement de l'espace noms des variables globles, les utiliser dans un namespace?

On conseille surtout d'éviter des variables globales.

[souviron34]

Peut on, pour eviter l'encombrement de l'espace noms des variables globles

oui, ne pas en utiliser

Non, serieusement, en utiliser LE MINIMUM !!!!!!!!!!!


Si il y en a plus de 2 ou 5 en moyenne par module, c'est un probleme de conception. ET IL NE DEVRAIT Y EN AVOIR AUCUNE inter-module...

[Edit]
Grilled !!!!
[/Edit]

[Scyrius]

Hello,
Je tiens juste à donner mon avis en tant que développeur Labview (entre autres ...)

Pour ceux qui ne connaissent pas, LV est un langage graphique très puissant connu en industrie. Pour coder, aucun texte a saisir, il "suffit" de relier par des fils un certain nombre de boites correspondant à des fonctions …

LV possède aussi ses normes des développements:
- une fonction sur un écran: cela revient aux 20 lignes et 80 colonnes de codes.
- on code de gauche a droite: code clair et lisible….
- pas ou peu de globales : chaque fonction a des paramètres d'entrées sur lesquelles on travaille et des paramètres de sorties.
Je passe sur le reste.

Donc, pour résumer mon intervention, pour moi, une norme de développement doit être telle que, lorsque l'on regarde un code quelque soit le langage, il faut le comprendre immédiatement. Cela joue donc sur la lisibilité, le nommage ( fonctions et variables), les commentaires et avant tout sur la simplicité du code.
Cela rejoint d'ailleurs à tout ce qui a été dit auparavant.

[TheDrev]

Pour ma part je pense que s'il n'existe pas de norme bien définie pour un langage, c'est de choisir une norme quelconque (ex : notation hongroise, formalisme Java, CamelTyping, un mélange ou votre propre convention etc), mais surtout et avant tout : de s'y tenir rigoureusement dans l'ensemble du code !
On peut ne pas avoir de préférence pour une norme ou une autre, mais en changer d'une page a une autre est infernale !

[Aizen64]

Ça risque de ne pas plaire a tout le monde mais je pense qu'actuelement il ne faut pas se prendre la tête sur la longueur de certaines lignes, pour le C/C++ je ne ferai pas de commentaires parce que c'est des languages qui me donnent des boutons a cause :

- des pointeurs, c'est vraiment chiant à utiliser, mon TP sur les listes chainées m'a suffit

- une syntaxe trop rigoureuse, si t'oublies un ; en fin de ligne, allez hop, tu peux facilement te retrouver avec au moins 10 erreurs par le compilateur juste pour cette erreur

- la création d'interfaces graphiques trop laborieuse

Avec un langage comme C# par exemple, pas besoin de se casser la tête, tu peux tapper approximativement le début du nom de ta variable, les variables sont listées et l'IntelliSense est très pratique

L'ironie c'est que je critique la plupart des développeurs qui font actuellement des softs trop gourmands mais d'un point de vue facilité de dev et correction de bug, pour moi je veux bien laisser ça de côté.

J'ai déjà vu des noms de méthodes aussi longs sur des gros projets et ça pose pas de problèmes :

RecupererIdClasseMachin

[HanLee]

Ça risque de ne pas plaire a tout le monde mais je pense qu'actuelement il ne faut pas se prendre la tête sur la longueur de certaines lignes, pour le C/C++ je ne ferai pas de commentaires parce que c'est des languages qui me donnent des boutons a cause :

- des pointeurs, c'est vraiment chiant à utiliser, mon TP sur les listes chainées m'a suffit

- une syntaxe trop rigoureuse, si t'oublies un ; en fin de ligne, allez hop, tu peux facilement te retrouver avec au moins 10 erreurs par le compilateur juste pour cette erreur

- la création d'interfaces graphiques trop laborieuse

Avec un langage comme C# par exemple, pas besoin de se casser la tête, tu peux tapper approximativement le début du nom de ta variable, les variables sont listées et l'IntelliSense est très pratique

L'ironie c'est que je critique la plupart des développeurs qui font actuellement des softs trop gourmands mais d'un point de vue facilité de dev et correction de bug, pour moi je veux bien laisser ça de côté.

J'ai déjà vu des noms de méthodes aussi longs sur des gros projets et ça pose pas de problèmes :

RecupererIdClasseMachin

- Tu utilises tout le temps des pointeurs sans le savoir en Java, C#... Et c'est pas difficile à utiliser. Le truc c'est que tu ne gère pas la mémoire aussi explicitement qu'en C, grâce au garbage collector, et tu ne fais pas d'arithmétique de pointeurs (d'ailleurs, je l'utilise rarement en C++).

Et en C++ on sait que les pointeurs faut faire gaffe, donc on évite de les utiliser au maximum, et sinon des pointeurs intelligents. Beaucoup d'outils nous permettent de les éviter dans la STL. Après faut chercher dans Boost.

- La syntaxe rigoureuse... Elle est aussi rigoureuse que ce soit en OCaml, Java, C#, C ou C++. Ce sont les erreurs indiquées par le compilateur qui ne sont peut-être pas claires de manière équivalente selon les compilateurs.

- La création d'interface graphiques en C++ est très facile et rapide avec Qt... Ca depend des outils. Tu peux coder à la main, tu peux créer tout ça avec le designer aussi.

- Oui dans C# c'est super pratique l'autocomplétion, mais ça n'a quasiment rien à voir avec le langage. Elle est vraiment bluffante je l'accorde sous VS2005, mais ça vient des moyens accordés par Microsoft.
L'éditeur de Visual C++ a quand même clairement été laissé de côté, niveau édition de code, factorisation,... Mais tout de même, l'intellisense marche assez bien, l'autocomplétion aussi.

Tu peux sinon aussi voir du côté d'eclipse avec CDT il est plutôt bien fourni niveau outils C++ de ce que j'ai vu. Je trouve l'autocomplétion bien meilleure qu'avec VC++ pour l'instant. L'intégration gratuite de Qt est top.

La majorité des critiques que tu peux faire viennent du fait qu'il y a eu énormément de moyens pour rendre accessible et facile d'utilisation des outils mines de rien difficiles à bien réaliser... Il y a aussi l'aspect marketing qui entre en jeu, la volonté de mettre en avant certains outils.

[Chatbour]

Salut à tous et à toutes

Et en C++ on sait que les pointeurs faut faire gaffe, donc on évite de les utiliser au maximum, et sinon des pointeurs intelligents. Beaucoup d'outils nous permettent de les éviter dans la STL. Après faut chercher dans Boost.

Pourquoi une telle "peur" des pointeurs, il suffit d'être attentif. Peut tu résumer les opérations avec les pointeurs qui peuvent aboutir à des catastrophes ?

Merci d'avance..

[Jedai]

Pourquoi une telle "peur" des pointeurs, il suffit d'être attentif. Peut tu résumer les opérations avec les pointeurs qui peuvent aboutir à des catastrophes ?

Merci d'avance..

C'est une question sérieuse ?? Parce qu'à peu près toutes les opérations avec des pointeurs "nus" peuvent résulter en des catastrophes, que ce soit l'allocation, la désallocation, l'arithmétique de pointeur, l'indexation... Ca me semble bien justifier une certaine "prudence" vis à vis des pointeurs (même s'il s'agit d'outils très puissants et efficaces par ailleurs), et l'emploi d'abstractions qui réduisent ou suppriment les risques qu'ils présentent (même au prix d'une petite diminution des performances).

--
Jedaï

[HanLee]

Salut à tous et à toutes



Pourquoi une telle "peur" des pointeurs, il suffit d'être attentif. Peut tu résumer les opérations avec les pointeurs qui peuvent aboutir à des catastrophes ?

Merci d'avance..

Oui, comme Jedai dit, un pointeur brut, c'est un peu comme accéder à la liberté totale, dans un monde dangereux sans être guidé par quelqu'un, en l'occurence le compilateur.

Oui il suffit d'être attentif. Mais toute charge cognitive dissipe de la puissance, tu te fatigues plus vite. Sans parler du risque d'erreur.

Quand tu peux faire des trucs sans réfléchir, de manière sécurisée, c'est préférable de le faire.

Après, ça veut pas dire que toute utilisation de pointeurs est déconseillée.

Il y a des cas d'utilisations qui on pourrait dire sont des formes canoniques d'utilisations des pointeurs, où utiliser des pointeurs n'est pas vraiment à risque parce que l'habitude nous pousse à toujours écrire le même code :
- utiliser un pointeur comme pour passer un objet par référence
- paire d'itérateurs <=> paire de pointeurs
- boucle for pour parcourir un tableau
- chaîne C-style
- C++ : allocation-désallocation mémoire pour un unique pointeur * dans un bloc (en C, gérer les erreurs c'est assez chiant).

* Pour plus de pointeurs, il faut prendre en compte les exceptions.

Ca c'est OK. Quand tu es dans un environnement où le flot d'exécution est tel que les allocations-désallocations mémoire ne sont pas "déterministes", ou bien pas "synchronisés", plutôt enchevêtrés, à vue d'oeil, là on augmente la prise de risque.

[koala01]

A vrai dire, les pointeurs, en C++, j'admets qu'il faut y faire super attention, principalement à cause du principe des quatre grands.

Ainsi, mon prof de C++ nous a sorti une "superbe" classe du genre de

Code C++ :

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
class Centrale
{
    public:
        Centrale()
        {
             std::cout<<"combien de turobgenerateurs dans la centrale ?";
             cin >>nbgen;
             pgen=new *TurboGen[bgen];
        }
        ~Centrale()
        {
            for(int i=0;i<pgen;i++)
                delete pgen[i];//car les turbo génératrices sont créées de manière
                              //dynamique
            delete[] pgen;
        }
    /* je passe sur les autres méthodes ;) */
}

L'astuce, c'est que, dans les méthodes que j'ai passées, il n'y a rien concernant le constructeur par copie ni l'opérateur d'affectation.

Evidemment, je n'y ai réagi que, bien à mon aise, installé dans le train pour rentrer

Mais, la semaine prochaine, je vais quand même lui indiquer que sa centrale, elle a un sérieux avant gout de Tchernobyl... car, si on essaye d'assigner une centrale à un autre, on court à la catastrophe

Alors, oui, les pointeurs sont dangereux à utiliser, oui, il nécessitent de réfléchir un minimum à ce que l'on fait, et, oui, cela nécessite de penser en permanence à nos "quatre grands".

Mais, ceci dit, si on reste un peu attentif et que l'on respecte certaines règles, cela devient un vrai plaisir de travailler avec

[triozen]

bonjour,

Je profite de ce sujet pour connaitre s'il y a des personnes qui ont travaillé sur la métrologie du logiciel. C'est à dire évaluer à partir de critères si le code est maintenable . Exemple : definir un nbre max de paramètres d'appel d'une fonction, le nombre max ou min dans une classe, % de commentaire ...
Je travaille dans un grand groupe qui sous traite la réalisation d'un logiciel à une société X et la maintenance est donnée à la société Y. Evidemment, la société Y explique que la maintenance de l'application sera chere car elle est mal codée.
l'idée serait de définir un ensemble de critères qui définit un niveau de maintenabilité. toutes applications en dessous d'un seuil seraient rejettées.
@++

[berceker united]

bonjour,

Je profite de ce sujet pour connaitre s'il y a des personnes qui ont travaillé sur la métrologie du logiciel. C'est à dire évaluer à partir de critères si le code est maintenable . Exemple : definir un nbre max de paramètres d'appel d'une fonction, le nombre max ou min dans une classe, % de commentaire ...
Je travaille dans un grand groupe qui sous traite la réalisation d'un logiciel à une société X et la maintenance est donnée à la société Y. Evidemment, la société Y explique que la maintenance de l'application sera chere car elle est mal codée.
l'idée serait de définir un ensemble de critères qui définit un niveau de maintenabilité. toutes applications en dessous d'un seuil seraient rejettées.
@++

Je me demande si ce n'est pas un argument commercial. Je pense que vous devez faire un du code par une société Z afin de vraiment prouver que c'est mal codé et sous quel critère.