Discussion :

[sosolal]

J'ai rassemblé quelques idées pour que les codes soit plus lisibles dans un texte qui devrait plaire aux codeurs qui en ont marre de rien comprendre aux codes des autres :

I/ Variables
1. Nommage
-Les noms de variables doivent être clairs (myVar : mauvais, userName : bon)
-Les noms de variables sont en anglais, même si le programme est écrit pas un francophone (nomUtilisateur : mauvais, userName : bon). Le seul moment où vous pourrez le faire et quand vous êtes sur que votre code ne sera jamais lu par un anglophone.
-Les noms de variables commençent par une minuscule (UserName : mauvais, userName : bon)
-Si il y a différents mots :
-Chaque mot commence par une majuscule, sauf le premier mot (username : mauvais, userName : bon)
-Les mots sont collées entre eux (user_Name : mauvais, userName : bon)
2. Déclaration
-On utilise la méthode héritée du C dans tous les cas à part le cas spécial en dessous (int life(42) : mauvais, int life = 42 : bon)
-Si il s'agit d'une conversion entre différents types, on utilise la nouvelle méthode C++ (int number = string : mauvais, int number(string) : bon) (int number = "13" : mauvais, int number(13.3) : bon)
3. Constantes
-On utilise les constantes dès qu'une variable ne changera pas pendant l'éxécution (double pi = 3.14 : mauvais, double const pi = 3.14 : bon)
-On n'utilise PAS les constantes si une variable pourra changer au cours de l'éxécution (int const playersNumber = 2 : mauvais, int playersNumber = 2 : bon)
4. Contenu
-Tout devrait être en anglais (même si le programeur est francophone) ET devrait être traduisible (via gettext ou Qt Linguist, par exemple). Le seul moment où vous pourrez déroger à cette règle est quand vous êtes sur que votre code ne sera jamais lu par un anglophone.

II/ Bonnes manières diverses
1. Indentation
-Deux à quatre espaces ou une tabulation pour les indentations
-La même façon d'indenter pour tout le programme
2. Position des accolades
-Elles sont chacunes sur une ligne qui leur est propre (pas d'accolades sur une ligne déja occupée par une instruction ou une indication du type de structure de contrôle.
3. Espaces de noms
-Tout programme (à part les headers, bien sûr) devrait utiliser l'espace de nom std par défaut (ligne using namespace std).
4. Licence
-Ceci est un ensemble de règles pour choisir la meilleure licence à utiliser pour un projet.
-Les programmes de plus de 100 lignes ou qui jouent un rôle important devrait être sous la licence GNU GPL, sauf si les deux règles ci-dessous disent qu'elles devraient être sous une autre licence.
-Les bibliothèques systèmes (dont l'utilisation est nécessaire pour créer des programmes sur un certain système) devraient être sous la licence GNU LGPL.
-Les bibliothèques qui n'ont aucun avantage sur leurs concurrents ne respectant pas ces règles devraient être sous la licence GNU LGPL.
-Les programmes et bibliothèques qui ne répondent à aucun critère ci-dessus devraient être sous Apache 2.0.
5. Disponibilité
-Le code doit être rendu disponible afin de facilite la modification.
-La compilation devrait utiliser les Autotools afin de faciliter la compilation.
6. Fonctionnalités (pas trop de rapport avec une convention pour rendre le code plus facile à lire et modifier, mais je vous recommande quand même fortement de les respecter)
-Pas de fonctionnalités malveillantes,de surveillance et autres mouchards.
-Pas d'harceliciel (une version gratuite qui vous harcèle en disant d'acheter la version payante).
-Pas de pubs (vous avez beaucoup d'autres manières de financer votre logiciel que de mettre des trucs chelous).

III/ Fonctions
1. Nommage
-Les fonctions doivent obéir aux mêmes règles de nommage que les variables
2. Arguments
-Les arguments étant des variables, elles doivent obéir aux mêmes règles de nommage et de constantes que les variables "classiques"
-Si l'argument est déclaré constant, il devrait être déclaré comme une référence (à part si il n'y a aucune chance que l'argument soit grand, dans ce cas-là ne pas le faire).

IV/ Classes
1. Nommage
-Les noms de classes doivent être clairs (MyClass : mauvais, User : bon)
-Les noms de variables sont en anglais, même si le programme est écrit par un francophone (Utilisateur : mauvais, User : bon) Le seul moment où vous pourrez le faire et quand vous êtes sur que votre code ne sera jamais lu par un francophone.
-Les noms de variables commençent par une majuscule (user : mauvais, User : bon)
-Si il y a différents mots :
-Chaque mot commence par une majuscule, sauf le premier mot (Userlist : mauvais, UserList : bon)
-Les mots sont collées entre eux (User_List : mauvais, UserList : bon)
2. Attributs
-Les attributs obéissent aux mêmes règles que les variables
-Les attributs externes (qui peuvent être utile à l'utilisateur) :
-Devrait êtres protégés si il a besoin de traitement particulier via un accesseur ou un mutateur (voir les règles pour les accesseurs et les mutateurs plus bas)
-Devrait êtres publics si il n'a pas besoin de traitement particulier (un bon exemple est la classe pair de la STL)
-Les attributs internes (qui ne servent qu'au fonctionnement interne de la classe)... bah ils sont privés!
3. Accesseurs et mutateurs
-Les accesseurs pour l'attribut myAttribute devrait s'appeler myAttribute()
-Pareil pour les mutateurs (vive la surchage des fonctions!)
4. Méthodes
-Les méthodes obéissent aux mêmes règles que les fonctions
-Les méthodes externes (qui peuvent être utile à l'utilisateur) :
-Ne devraient pas renvoyer void. Si votre méthode n'a pas besoin de valeur de retour, elle devrait renvoyer une référence vers l'objet (pour faire des séries d'instruction à la jQuery, pour ceux qui connaissent)
-Les méthodes internes (qui ne servent qu'au fonctionnement interne de la classe)... bah ils sont privés!
5. Instanciation
-Les objets sont des variables comme les autres, donc elles obéissent aux mêmes règles que les autres!

V/ GUI
1. Conteneurs et contenus
-Seuls les conteneurs devraient pouvoir contenir d'autres widgets (pas de boutons dans d'autres boutons).
2. Position
-Toutes les fenêtres devraient utiliser la position relative (les layouts), hormis les boîtes de dialogues et les petites fenêtres du style des fenêtres d'utilitaires (formatage, gravage, etc.)
-Les boîtes de dialogues "classiques" (messages d'erreurs, warnings, etc.) devrait êtres modales, hormis les fenêtres utilitaires (rechercher dans le texte, rechercher/remplacer dans le texte, insérer des caractères spéciaux, etc.).

[Iradrille]

-Tout programme devrait utiliser l'espace de nom std par défaut (ligne using namespace std).
-Les méthodes externes (qui peuvent être utile à l'utilisateur) :
-Ne devraient pas renvoyer void. Si votre méthode n'a pas besoin de valeur de retour, elle devrait renvoyer un pointeur vers l'objet (pour faire des séries d'instruction à la jQuery, pour ceux qui connaissent)
-Les objets sont quand même un peu spéciaux : c'est des super-variables, donc ils ont une règle en plus : on instancie des pointeurs, pas les objets en eux-mêmes (un peu comme quand on utilise Qt)

Du bon et du moins bon, mais ces 3 points sont juste des mauvaises pratiques. Encore heureux que peut de codes sources suivent ces "normes".

Quant aux exemples, ça ressemble plus à du troll qu'autre chose.

[sosolal]

Je vais m'expliquer un peu :
-Je suis d'accord de faire quelquechose du genre NomDeLaBiblio::NomDeLaClasse, en fait c'est juste pour éviter les std::cout et autre trucs super-faciles à lire (ironie).
-Je ne vois pas pourquoi utiliser systématiquement les pointeurs est une mauvaise idée, cela permet d'enchaîner facilement des instructions.

[Neckara]

Bonjour,

-Les mots sont collées entre eux (user_Name : mauvais, userName : bon)

Ne pas "coller" les mots entre eux est aussi une bonne façon de faire et peut, dans certaines circonstances être plus lisible.

Si il s'agit d'une conversion entre différents types, on utilise la nouvelle méthode C++ (int number = string : mauvais, int number(string) : bon) (int number = "13" : mauvais, int number("13") : bon)

L'exemple ne compilera jamais

-On n'utilise PAS les constantes si une variable pourra changer au cours de l'éxécution (int const playersNumber = 2 : mauvais, int playersNumber = 2 : bon)

Capitaine obvious ^^

-Tout devrait être en anglais (même si le programeur est francophone) ET devrait être traduisible (via gettext ou Qt Linguist, par exemple). Le seul moment où vous pourrez déroger à cette règle est quand vous êtes sur que votre code ne sera jamais lu par un francophone.

Je suis sûr que mon programme ne sera jamais lu par un français, je peux donc écrire mon programme en français \o/

-Tout programme devrait utiliser l'espace de nom std par défaut (ligne using namespace std).

Surtout pas !
On peut le faire à la rigueur dans des fichiers sources mais je préfère, personnellement les éviter pour qu'on sache toujours de quel espace de nom vient le symbole.
En revanche à ne jamais mettre dans un fichier d'en-tête.

-Les programmes de plus de 100 lignes ou qui jouent un rôle important devrait être sous la licence GNU GPL, sauf si les deux règles ci-dessous disent qu'elles devraient être sous une autre licence.
-Les bibliothèques systèmes (dont l'utilisation est nécessaire pour créer des programmes sur un certain système) devraient être sous la licence GNU LGPL.
-Les bibliothèques qui n'ont aucun avantage sur leurs concurrents ne respectant pas ces règles devraient être sous la licence GNU LGPL.
-Les programmes et bibliothèques qui ne répondent à aucun critère ci-dessus devraient être sous Apache 2.0.

N'importe quoi.

5. Disponibilité
-Le code doit être rendu disponible
-La compilation devrait utiliser les Autotools

N'importe quoi.
D'ailleurs cmake est aussi une option envisageable.

6. Fonctionnalités
-Pas de pubs (vous avez d'autres manières de financer votre logiciel que de mettredes trucs chelous)

N'importe quoi.

2. Arguments
-Les arguments étant des variables, elles doivent obéir aux mêmes règles de nommage et de constantes que les variables "classiques"
-Si l'argument est déclaré constant, il devrait être déclaré comme une référence

Passer par copie est assez intéressant pour les types primitifs et des petites classes/structs.

-Devrait êtres protégés si il a besoin de traitement particulier via un accesseur ou un mutateur (voir les règles pour les accesseurs et les mutateurs plus bas)

Rien à voir.

-Devrait êtres publics si il n'a pas besoin de traitement particulier (un bon exemple est la classe pair de la STL)

Pas assez précis.

3. Accesseurs et mutateurs
-Les accesseurs pour l'attribut myAttribute devrait s'appeler myAttribute()
-Pareil pour les mutateurs (vive la surchage des fonctions!)

Il ne faut plus les considérer comme de simples "accesseurs" mais comme une méthode fournissant un service.
Exemple : moveTo(x, y);

-Ne devraient pas renvoyer void. Si votre méthode n'a pas besoin de valeur de retour, elle devrait renvoyer un pointeur vers l'objet (pour faire des séries d'instruction à la jQuery, pour ceux qui connaissent)

N'importe quoi.

-Les objets sont quand même un peu spéciaux : c'est des super-variables, donc ils ont une règle en plus : on instancie des pointeurs, pas les objets en eux-mêmes (un peu comme quand on utilise Qt)

N'importe quoi.

[Bousk]

je me suis arrêté à int pi=3.14

[skeud]

Le rapport entre la lisibilité du code et la licence?

EDIT: après reflexion, m'est avis que ce post a sa place dans le bétisier ^^.

[sosolal]

"Ne pas "coller" les mots entre eux est aussi une bonne façon de faire et peut, dans certaines circonstances être plus lisible."
Beaucoup de programmeurs respectent cette convention de nommage. C'est d'ailleurs la convention de nommage la plus courante en C++.

"L'exemple ne compilera jamais"
Ah ouais merde. Modifié.

"Captaine Obvious"
Un petit rappel ne fait pas de mal.

"Je suis sûr que mon programme ne sera jamais lu par un français, je peux donc écrire mon programme en français \o/"
Les étourderies, franchement. Modifié.

"je préfère, personnellement les éviter pour qu'on sache toujours de quel espace de nom vient le symbole." Tu n'as jamais vu unde ces codes horribles où même un "Hello, world!" est illisible? Ça vient du fait qu'on utilise pas "using namespace std;"

"N'importe quoi. (pour les licences)"
C'est une convention pour aider les gens à modifier les codes, donc je trouve logique de mettre des règles pour aider à choisir la licence de logiciel libre la plus adaptée.

"N'importe quoi. (pour les autotools)"
D'ailleurs cmake est aussi une option envisageable."
Il est bien dans une convention d'uniformiser la méthode de compilation.

"N'importe quoi. (pour les pubs)"
Je vois pas en quoi c'est n'importe quoi, où alors tu n'as jamais vu l'ampleur des pubs dans les logiciels.

"Passer par copie est assez intéressant pour les types primitifs et des petites classes/structs."
On perd rien à le faire, à part un octet d'espace, on sait jamais peut-être qu'une "petite" classe pourrait contenir de gros arguments, une string avec toutes les archives de tout les messages du forum par exemple.

"Rien à voir."
Peux-tu développer parceque je ne comprends rien à ce que tu dis.

"Pas assez précis."
Le contexte montre bien que c'est si il n'a pas besoin d'accesseurs ou de mutateurs...

"Il ne faut plus les considérer comme de simples "accesseurs" mais comme une méthode fournissant un service.
Exemple : moveTo(x, y);"
Euh... Que veux-tu dire pas là???

"N'importe quoi. (pour les suites d'instructions)"
J'ai l'impression que tu fais exprès.

[Neckara]

"Ne pas "coller" les mots entre eux est aussi une bonne façon de faire et peut, dans certaines circonstances être plus lisible."
Beaucoup de programmeurs respectent cette convention de nommage. C'est d'ailleurs la convention de nommage la plus courante en C++.

Et ?
Ce n'est pas parce qu'elle est la plus courante qu'elle est la meilleure en toute circonstance.

"je préfère, personnellement les éviter pour qu'on sache toujours de quel espace de nom vient le symbole." Tu n'as jamais vu unde ces codes horribles où même un "Hello, world!" est illisible? Ça vient du fait qu'on utilise pas "using namespace std;"

Code :

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

std::cout << "Hello world !" << std::endl;

C'est illisible ?
De plus mettre des using namespace std dans tes fichiers d'en-tête est à éviter à tout prix !
Car tu ne sais pas qui inclura ton fichiers d'en-tête ainsi que les using namespace utilisés par les autres fichiers d'en-têtes.
Les namespace n'ont pas été inventés pour rien

"N'importe quoi. (pour les licences)"
C'est une convention pour aider les gens à modifier les codes, donc je trouve logique de mettre des règles pour aider à choisir la licence de logiciel libre la plus adaptée.

1) Cela n'a rien à voir avec la problématique que tu proposes.
2) Faire dans le logiciel libre ou open source est avant tout un choix de l'auteur.

"N'importe quoi. (pour les autotools)"
D'ailleurs cmake est aussi une option envisageable."
Il est bien dans une convention d'uniformiser la méthode de compilation.

Et en quoi autotools serait-il meilleur que tous les autres logiciels ? Pourquoi lui plutôt qu'un autre ?

"N'importe quoi. (pour les pubs)"
Je vois pas en quoi c'est n'importe quoi, où alors tu n'as jamais vu l'ampleur des pubs dans les logiciels.

1) L'exemple ne fait pas la règle
2) Il est tout à fait possible d'intégrer des publicités dans le respect des utilisateurs

"Passer par copie est assez intéressant pour les types primitifs et des petites classes/structs."
On perd rien à le faire, à part un octet d'espace.

????

"Rien à voir."
Peux-tu développer parceque je ne comprends rien à ce que tu dis.

Ce serait bien de connaître au minimum le C++ avant de proposer des règles de bonnes pratiques...

"Pas assez précis."
Le contexte montre bien ue c'est si il n'a pas besoin d'accesseurs ou de mutateurs...

On peut faire une classe sans accesseurs/mutateurs sans pour autant exposer publiquement ses attributs.

"Il ne faut plus les considérer comme de simples "accesseurs" mais comme une méthode fournissant un service.
Exemple : moveTo(x, y);"
Euh... Que veux-tu dire pas là???

Il faudrait que je t'explique des notions qui sont, pour le moment, un peu trop avancée pour toi (principe d'encapsulation, de couplage,etc.).
On en reparlera plus tard si tu le souhaite .

"N'importe quoi. (pour les suites d'instructions)"
J'ai l'impression que tu fais exprès.

Désolé, mais tu racontes vraiment n'importe quoi
Pourquoi ne pourrait-on pas allouer automatiquement un objet (comme une variable locale) ?

[skeud]

Je viens de relire le post, et un truc m'intrigue:

Dans ton cadre perso (juste là à gauche) c'est indiqué collégien. Quel est donc ton expérience dans la programmation?

Le sujet parle d'une charte pour aider à modifier un programme, après tu parles de lisibilité du code, il faudrait choisir.

D'ailleur une charte pour la modification d'un programme? Je vois pas trop le but ><.
Soit le programme est en open-source et donc tu peux le modifier, soit il ne l'est pas et donc tu ne peux pas le modifier, pas besoin de préciser une licence donc. Pareil pour les outils de compilation, il y en a plétore, et ils ont tous leurs avantage et leurs inconvénients.

Ensuite, comme pas mal de gens, je pense qu'un programme bien conçu et avec un code clair est facilement modifiable.
Et pour faire un code clair il existe plein de normes, et souvent, ces normes possèdent un tronc commun, tronc commun respecté par la plupart des développeurs.

Si un mec veut faire un code crade, tu peux être sur qu'il ne viendra pas lire ce post.

[gangsoleil]

"N'importe quoi. (pour les licences)"
C'est une convention pour aider les gens à modifier les codes, donc je trouve logique de mettre des règles pour aider à choisir la licence de logiciel libre la plus adaptée.

En quoi GPL ou LGPL est plus adaptee qu'une autre ? Pourquoi ne pas utiliser, si tu veux faire de l'open-source, les licences CeCill par exemple ? Et en quoi ces licences sont mieux que les licences de type BSD ? Sais-tu seulement que les licences GPL et LGPL ne sont pas compatibles avec d'autres licences, et donc que le fait de passer un bout de code sous ces licences peut tout simplement violer l'une des deux licences ?

Et par ailleurs, en entreprise, les developpeurs ne sont que tres rarement libre de choisir la licence a utiliser.

[shadowmoon]

En lisant cette discussion, une question m'est venue à l'esprit : sosolal ne serait-il pas le meilleur disciple, la réincarnation voir même le fils (spirituel) de "millénium lover" ?

[sosolal]

1. Un code illisible n'est pas modifiable, tu sais?
2. La GPL est mieux parce qu'elle est une licence copyleft. Si tu crées un logiciel libre, tu n'aimerais pas que quelqu'un te prenne le code et le mette dans un logiciel privateur dans lequel tu ne peux pas reprendre le code pour améliorer le logiciel initial?

[Momoth]

2. La GPL est mieux parce qu'elle est une licence copyleft. Si tu crées un logiciel libre, tu n'aimerais pas que quelqu'un te prenne le code et le mette dans un logiciel privateur dans lequel tu ne peux pas reprendre le code pour améliorer le logiciel initial?

Bonjour,

Comme dit plus haut, c'est avant tout un choix de l'auteur. Personnellement, si je choisis de faire un logiciel libre, c'est que je ne souhaites pas particulièrement me faire de l'argent avec. Si quelqu’un arrive a gagner un tant soit peu d'argent en reprenant une partie de mon code et en le vendant, je serais surtout content pour lui. Et je me sentirai flatté qu'il ai choisit mon code

[sosolal]

ce qui n'a rien à voir, au fait

[Rayek]

Lorsque l'on veux donner des leçons de formatage sur le code, il serait bien de suivre aussi les règles d'écritures de documents (Indentation, etc ...)

I/ Variables

1. Nommage

• Les noms de variables doivent être clairs (myVar : mauvais, userName : bon)
• Les noms de variables sont en anglais, même si le programme est écrit pas un francophone (nomUtilisateur : mauvais, userName : bon). Le seul moment où vous pourrez le faire et quand vous êtes sur que votre code ne sera jamais lu par un anglophone.
• Les noms de variables commençent par une minuscule (UserName : mauvais, userName : bon)
• Si il y a différents mots :

-Chaque mot commence par une majuscule, sauf le premier mot (username : mauvais, userName : bon)
-Les mots sont collées entre eux (user_Name : mauvais, userName : bon)

2. Déclaration

• On utilise la méthode héritée du C dans tous les cas à part le cas spécial en dessous (int life(42) : mauvais, int life = 42 : bon)
• Si il s'agit d'une conversion entre différents types, on utilise la nouvelle méthode C++ (int number = string : mauvais, int number(string) : bon) (int number = "13" : mauvais, int number(13.3) : bon)

3. Constantes

• On utilise les constantes dès qu'une variable ne changera pas pendant l'éxécution (double pi = 3.14 : mauvais, double const pi = 3.14 : bon)
• On n'utilise PAS les constantes si une variable pourra changer au cours de l'éxécution (int const playersNumber = 2 : mauvais, int playersNumber = 2 : bon)

4. Contenu

• Tout devrait être en anglais (même si le programeur est francophone) ET devrait être traduisible (via gettext ou Qt Linguist, par exemple). Le seul moment où vous pourrez déroger à cette règle est quand vous êtes sur que votre code ne sera jamais lu par un anglophone.

Sinon il n'y a toujours pas eu de réponse à la question de Skeud : Dans ton cadre perso (juste là à gauche) c'est indiqué collégien. Quel est donc ton expérience dans la programmation?

[FaridM]

Au moins ce sujet est dans la bonne catégorie du forum. Humour informatique

[el_slapper]

Pour rappel : nous sommes sur un forum de professionels (ou ex-pros, ou futurs pros, mais généralement de bon niveau). Donner des leçons sur des sujets aussi variables(parceque figure toi qu'en COBOL, par exemple, tes conseils sont inapplicables, et sans doute dans bien d'autre langages).

Celà explique la masse de votes négatifs que tu as reçu.

[sosolal]

parce que figure toi que c'est des règles pour le C++...

[transgohan]

parce que figure toi que c'est des règles pour le C++...

Bah il aurait été bon de l'indiquer.
Tous ceux qui passent sur ce forum ne sont pas forcement familier avec ce langage.

[tchize_]

J'ai rassemblé quelques idées pour que les codes soit plus lisibles dans un texte qui devrait plaire aux codeurs qui en ont marre de rien comprendre aux codes des autres

Ben faut pas. Base toi sur ce qui est réellement utilisé dans ton entreprise, parce que les conventions de codage, ça existe depuis avant que tu sois né et plein de gens on réfléchi à ce problème bien avant que tu aie des idées.

Mais bon, j'ai bien rit


Ha oui, et j'aurais énormément de mal à suivre un programme qui suivrait tes conventions puisqu'elles vont à l'encontre des recommandation d'oracle pour le java.