Discussion :

[BenoitM]

En C# aussi, mais dans un seul cas, les booléens :

Code :

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

1
2
3
4
5
6
bool b = false;
if(b=true)
{
Console.WriteLine("Etonnant non ?");
}

avec un warning il est vrai.

bien la preuve qu'il faut écrire

Code :

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

if(b) ...

et non

Code :

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

if(true == b) ...

ou

Code :

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

if(b == true)...

[SurferIX]

En C# aussi, mais dans un seul cas, les booléens... avec un warning il est vrai.

Tu as raison : j'ai oublié de préciser qu'il est possible (si je ne me trompe pas) d'activer une option qui affiche un warning pour les assignations lors des "if".

[gb_68]

Pour le "Single Entry, Single Exit" (alias "pas de return multiples") je dirais que ça dépend des circonstances: Contexte d'utilisation, outils disponibles dans le langage (notamment, présence ou non de destructeurs ou ramasse-miettes) et présence de ressources allouées.

Exactement, pour moi le problème c'est quand on tente d'appliquer bêtement une convention de codage potentiellement bénéfique et bien adaptée à un langage (voire couple langage/IDE) à un autre où elle n'est plus utile, voire contre-productive, sans se poser les bonnes questions (quelles raisons ont poussé à définir cette règle ? sont elles encore d’actualités ?).

[rt15]

Ensuite un autre problème surgit souvent : code classique (même vu en école d'ingénieur par un prof ) :

Code :

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

1
2
3
if (f=fopen("monfichier", "r")) {
   ...
}

Code qu'il faut absolument proscrire tout simplement parce que la valeur de retour peut être un succès = lecture ok, mais peut renvoyer "0" (= un entier) et donc ce code considère que ça n'a pas fonctionné, alors que si.

Le code "propre" et "fiable" est :

f=fopen("monfichier", "r");

Code :

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

1
2
3
if (f>=0) {
   ...
}

Heu... C'est de l'humour j'espère. Ou alors c'est pas du C.

S'il réussissent intégralement fopen, fdopen et freopen renvoient un pointeur sur un fichier, de type FILE. Sinon, ils renvoient NULL et errno contient le code d'erreur.

Donc si le retour de fopen (Pointeur convertit en entier) est 0, souci, si le retour de fopen est différent de 0 tout va bien. Et le pointeur ne sera d'ailleurs probablement jamais négatif. En 32 bits, un pointeur est généralement considéré comme un unsigned int dans les comparaison. Donc (pointer >= 0) renvoie toujours vrai sur de nombreux compilos.

Pour moi le code de ton prof est valide, et le tien non. Merci de confirmer ou contester ça.

[edit]

Code de test :

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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
#include <stdio.h>

FILE* openInvalidFile()
{
  return NULL;
}

FILE* openValidFile()
{
  return (FILE*)-12;
}

int main()
{
  FILE* f;

  if (f = openValidFile())
    printf("Fichier valide ouvert %d\n", f);
  else
    puts("Echec de l'ouverture d'un fichier valide");

  if (f = openInvalidFile())
    printf("Fichier invalide ouvert %d\n", f);
  else
    puts("Echec de l'ouverture d'un fichier invalide");

  f = openValidFile();
  if (f >= 0)
    printf("Fichier valide ouvert %d\n", f);
  else
    puts("Echec de l'ouverture d'un fichier valide");
 
  f = openValidFile();
  if (f >= 0)
    printf("Fichier invalide ouvert %d\n", f);
  else
    puts("Echec de l'ouverture d'un fichier invalide");

  return 1;
}

Résultat :
Fichier valide ouvert -12
Echec de l'ouverture d'un fichier invalide
Fichier valide ouvert -12
Fichier invalide ouvert -12

[Bovino]

Quelle est la règle de codage la plus étrange que vous avez été forcé de suivre ?

Ne pas avoir le droit de créer de nouvelle base de donnée pour des activités différentes !

Imaginons par exemple que nous ayons créé une base correspondant à des recettes de cuisine, avec les champs "ingrédients", "durée" et "opérations".
On décide ensuite de créer un planning d'entrainement sportif, du coup, dans ce cas, "ingrédients" correspond à "type d'exercice", "durée" à "lieu" et "opérations" à "équipement". Seulement, comme il manque un champ pour "durée de l'exercice", alors on va utiliser le champ "ingrédients" en séparant la valeur "type d'exercice" et "durée de l'exercice" par un délimiteur arbitraire...

Tout cela est parfaitement résumé dans cet article...

[Uther]

Ensuite un autre problème surgit souvent : code classique (même vu en école d'ingénieur par un prof ) :

Code :

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

1
2
3
if (f=fopen("monfichier", "r")) {
   ...
}

Code qu'il faut absolument proscrire tout simplement parce que la valeur de retour peut être un succès = lecture ok, mais peut renvoyer "0" (= un entier) et donc ce code considère que ça n'a pas fonctionné, alors que si.

Le code "propre" et "fiable" est :

f=fopen("monfichier", "r");

Code :

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

1
2
3
if (f>=0) {
   ...
}

Non seulement :
- le code que tu accuses d'être faux est tout à fait correct : fopen ne retourne NULL(soit 0) qu'en cas d'erreur. Si tu ne me crois pas, il suffit de consulter le man
- la solution que tu proposes est incorrecte. Ton code ne gèrera pas les erreurs.

[Glob]

> en Java, mettre des getters/setters sur des DTO, et interdire la moindre "intelligence" dans ces getters/setters.

Où est l'intérêt de ce genre de chose, alors qu'il suffit de laisser les attributs public?

[Barsy]

bien la preuve qu'il faut écrire

Code :

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

if(b) ...

et non

Code :

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

if(true == b) ...

ou

Code :

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

if(b == true)...

Enfin, dans tout les cas il faut écrire

Code :

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

if (maConstante == maVariable)

et non l'inverse. Peut importe qu'il s'agisse de booléen, d'entiers ou autre. Et très souvent les développeurs écrivent l'inverse.

Après, pour ce qui est de préciser à chaque fois "true" ou "false" quand on compare un booléen, chacun est juge, tant qu'il respecte la règle fixée sur le projet bien évidemment.

Sinon, pour rester sur les booléens, voici une règle qui m'a semblé intéressante sur un précédent projet : Les booléens doivent toujours être écrits pour que la valeur "true" reflète un résultat positif. Par exemple, un booléen peut s'appeler "isConnected" mais pas "isNotConnected".
Et c'est vrai qu'on tombe souvent sur des booléen négatifs dans les projets. Après, je ne pense pas que ce soit vital comme règle, mais ça peut faciliter la lecture du code je pense.

[Bluedeep]

Les booléens doivent toujours être écrits pour que la valeur "true" reflète un résultat positif. Par exemple, un booléen peut s'appeler "isConnected" mais pas "isNotConnected".

Donc utiliser IsNotDisconnected c'est pas bon ?

[Troudhyl]

Enfin, dans tout les cas il faut écrire

Code :

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

if (maConstante == maVariable)

et non l'inverse. Peut importe qu'il s'agisse de booléen, d'entiers ou autre. Et très souvent les développeurs écrivent l'inverse.

Effectivement, à moins d'être Yoda, je trouve qu'il est plus facile de lire d'abord l'élément sur lequel porte la comparaison (sujet)...

[Bluedeep]

Effectivement, à moins d'être Yoda, je trouve qu'il est plus facile de lire d'abord l'élément sur lequel porte la comparaison (sujet)...

Vers la gauche depuis la droite il suffit de lire , m'enfin
D'être Yoda, point besoin il n'est.

[Laurent.B]

Moui, encore faut il avoir le réflexe de le faire AU DEBUT du projet, pas quand on en est à 100000 lignes/150 fichiers sources

Sur certains outils tels qu'Eclipse, cela ne pose aucun problème de formater tout un projet après coup mais oui, il vaut mieux prévoir cela au début.

L'idée derrière cette règle c'est de mettre au moins une trace dans le else (ne serait-ce qu'un std::cout) pour voir quand tu tombes dans ce cas précis, ça peut te faire gagner un temps précieux de recherche. Juste mettre un commentaire NOTHING effectivement c'est lourdingue et surtout ça sert à rien...

La première idée de cette règle me semblerait plutôt de bien montrer que tu as pensé à l'alternative (dans certains domaines ça peut être une question vitale ou extrêmement importante). NOTHING n'est effectivement pas très explicite donc personnellement, quand je l'applique, je m'efforce de mettre un commentaire utile.

Fraichement embauché sur un produit codé par des générations de stagiaires, j'ai voulu mettre en place des conventions de codage et un semblant d'architecture pour harmoniser tout ça. Le chef de projet m'a répondu que la seul règle à suivre était de ne pas utiliser de convention de codage car "ça frustre le développeur et lui fait perdre son temps. Tu débute et moi j'ai 20 ans d'expérience alors crois moi quand je te dis que ça sert à rien !".
Résultat, un code illisible mélangeant a peu près tout ce qu'on peu trouver...

Celle-là je la mettrai dans le top 10 moi

Je suis habitué au K&R et que je vois du Whitesmiths, j'ai un peu de mal.
Article wikipédia sur les indentations du code.

Effectivement, les accolades me paraissent vraiment incongrues placées comme ça...
Merci pour le lien wikipedia

Actuellement en fac d'info et ma prof de C interdit l'utilisation du else if car elle ne trouve pas ça clair...

Est-elle ou a-t-elle été développeuse sur des projets dans sa vie, ou c'est juste purement arbitraire de sa part ?

Pour ma part, et sans hésiter, il y a de cela sept ou huit ans, un projet chez un client où le DBA ne voulait pas de procédure stockées ....

Bon si ce n'est pas ironique, alors il faudra peut-être un jour que tu te penches sérieusement sur le sujet et peut-être comprendras-tu les raisons de cette phobie des procédures stockées. Il y en a plusieurs...

Par exemple : string.isEmpty(). Donc if (string.isEmpty()) est déjà une phrase. Mais on m'impose d'écrire if (string.isEmpty() == true), ce qui demande plus de concentration pour le lire.

Certes, la raison doit probablement être qu'il ne faut pas déroger à la règle d'indiquer le booléen que l'on teste mais dans ce cas précis, ça me semble effectivement très moyen, je compatis .

Sinon, en Java, qu'est-ce vous pensez de l'utilisation d'un label avec un break pour sortir d'une boucle ?

Code java :

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
    protected boolean isContainingMainFile(File[] files)
    {
        boolean isInList = false;
 
        String documentFileName = projectName + ".xml";
 
        found: for (File file : files)
        {
            if (documentFileName.equals(file.getName()))
            {
                isInList = true;
                break found;
            }
        }
 
        return isInList;
    }

C'est loin d'être clair lorsque l'on rencontre cette notation la première fois mais en ce qui me concerne, je considère que c'est une bonne pratique. C'est encore plus évident lorsque l'on a deux boucles imbriquées et que l'on veut pourvoir en sortir d'un seul coup.
Quand j'utilise celle-ci, certaines personnes parviennent à comprendre son intérêt quand je leur explique et d'autres s'en offusquent (bêtement)... CheckStyle, PMD, et les autres ne s'en offusquent pas eux ^^

[Laurent.B]

> en Java, mettre des getters/setters sur des DTO, et interdire la moindre "intelligence" dans ces getters/setters.

Où est l'intérêt de ce genre de chose, alors qu'il suffit de laisser les attributs public?

Oui, ça paraît moyen au premier abord mais la raison est que cela permet de la généricité dans les traitements de ce genre d'objets, notamment par réflexion ou même AOP. Le tout est de ne pas saisir à la main les getters/setters... Ca reste lourd, on est d'accord, faudra faire quelque chose un jour pour rendre cela plus efficace.

[Bluedeep]

Heureusement que des langages comme python évite ce genre de dérive.

Je suis habitué au K&R et que je vois du Whitesmiths, j'ai un peu de mal.
Article wikipédia sur les indentations du code.

Pour ma part, je trouve le K&R totalement incongru.

C'est une mode apparue au début des années 80, liée historiquement aux contraintes de l'éditeur des systèmes Unix de l'époque, qui a eu le bon gout de disparaitre au début des 90' et que j'ai vu avec stupeur réapparaitre principalement chez les codeurs Javascript à la fin des 90' alors que la majorité des dev. C++ et Java ( et C# après) utilisaient le Allman (que pour ma part j'impose sur tous les développement - le refactoring d'aspect de VS permettant de ramener le code des égarés à la raison ).

[NevilClavain]

Sur certains outils tels qu'Eclipse, cela ne pose aucun problème de formater tout un projet après coup mais oui, il vaut mieux prévoir cela au début.

Haa ? j'ignorais qu'Eclipse permettait cela, merci pour l'info

[Loceka]

Les choix du type de parenthésage sont aussi trollifère que les choix d'indentation (voire plus), mais personnellement je préfère le parenthésage à la "Java" (proche du K&R apparement).
Le parenthésage type Allman je trouve que c'est de la perte de place et du coup de lisibilité (on n'embrace pas tout le code d'un seul coup d'oeil) :

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
int main(int argc, char *argv[]) {
    ...
    while (x == y) {
        something();
        somethingelse();
 
        if (some_error) {
            /* the curly braces around this code block could be omitted */
            do_correct();
        } else {
            continue_as_usual();
        }
    }
 
    finalthing();
    ...
}

vs

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
int main(int argc, char *argv[])
{
    ...
    while (x == y)
    {
        something();
        somethingelse();
 
        if (some_error)
        {
            /* the curly braces around this code block could be omitted */
            do_correct();
        }
        else
        {
            continue_as_usual();
        }
    }
 
    finalthing();
    ...
}

[Bluedeep]

Les choix du type de parenthésage sont aussi trollifère que les choix d'indentation (voire plus), mais personnellement je préfère le parenthésage à la "Java" (proche du K&R apparement).
Le parenthésage type Allman je trouve que c'est de la perte de place et du coup de lisibilité (on n'embrace pas tout le code d'un seul coup d'oeil)

C'est en effet trollifère car pour ma part j'ai l'opinion exactement inverse sur la lisibilité

Si le fait de embracer (c'est de l'anglais, mais il semble que le verbe existait en vieux français) le code d'un seul coup d'oeil (ou si on était payé à l'économie de lignes) était un argument recevable, les déclarations de variables devraient avoir cette forme :

Code :

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

int aVariable; string anotherVariable; double etcVariable;

[Glob]

Oui, ça paraît moyen au premier abord mais la raison est que cela permet de la généricité dans les traitements de ce genre d'objets, notamment par réflexion ou même AOP. Le tout est de ne pas saisir à la main les getters/setters... Ca reste lourd, on est d'accord, faudra faire quelque chose un jour pour rendre cela plus efficace.

La réflexion fonctionne tout aussi bien sur des champs public que sur des méthodes. De plus, même si la génération des accessors peut être facilitée dans des IDE modernes comme Eclipse, ça reste lourd à la maintenance pour une plus-value qui reste chimérique.

A+

[Laurent.B]

Le parenthésage type Allman je trouve que c'est de la perte de place et du coup de lisibilité (on n'embrace pas tout le code d'un seul coup d'oeil)

Moi qui ai beaucoup de mal à lire les blocs condensés, que j'appelle en général des "pâtés" , je préfère donc de loin le code aéré et peu importe si celui-ci provoque ce que certains voient comme de la perte de place.
En fait, pour ce qui est de permettre d'avoir une vision globale et rapide de l'action d'une méthode ou fonction, tout dépend de ce qu'elle contient et de la manière dont c'est formalisé. Le code condensé avait bien plus de légitimité lorsque les écrans avaient encore des dimensions très restreintes. Quoi qu'il en soit et en ce qui me concerne, je pense qu'effectivement ce genre de débat est plutôt vain, tout simplement parce que tout le monde n'a pas la même façon de percevoir et analyser un code.

Donc, toujours selon moi, mettre une accolade en fin de ligne à côté plutôt absurde mais avec le temps je m'en suis accommodé. Pour pallier cela, j'ajoute systématiquement une ligne vide après l'accolade ouvrante. C'est donc un format hybride que je pratique et le fait que l'accolade soit à la fin des lignes ne m'embête pas, signe que ce n'est pas tant l'accolade le problème mais bien les textes trop condensés.

Ensuite, je suis tout à fait d'accord avec le fait que si une méthode est trop longue, cela pose des problèmes pour analyser rapidement l'algorithme de celle-ci. C'est pourquoi, au lieu d'incriminer les accolades ouvrantes en début de ligne ou les lignes vides, il faut attacher davantage d'importance à la formalisation de celle-ci. Cela veut dire, faire en sorte que tout ce qui est un tant soit peu compliqué à lire ou tout ce qui prend beaucoup de lignes (ex : remplissage d'un bean avec plein d'attributs par exemple), soit relégué dans des méthodes explicites de par leur nom.
Voilà, donc normalement en définissant des règles qui imposent un nombre de lignes relativement restreint par méthode/fonction, on peut se permettre d'avoir un code aéré, qui selon moi demeure beaucoup plus lisible.

Bref, on n'arrivera jamais à satisfaire tout le monde, donc on aura sans doute fait un progrès, lorsque les éditeurs de code permettront de présenter efficacement le code selon les goûts du développeur, sans impact sur les fichiers physiques et qu'il soit ensuite très facile de basculer d'un type de présentation à un autre.

Un autre progrès me semblerait intéressant, ce serait de guider en permanence la saisie du code, de manière à ce que le développeur n'ait pas à s'en préoccuper (ça se fait dans certains éditeurs depuis un bail me semble-t-il). Egalement, ces éditeurs pourraient se rapprocher de ce qu'est un éditeur de texte tel que Word/OO, c'est-à-dire en permettant de la mise en forme plus poussée. Par exemple, en ayant des marges verticales à intervalle adaptatif selon le contexte, comme faire une séparation plus prononcée entre la signature d'une méthode et le contenu de celle-ci (personnellement, je ne mettrais plus de ligne vide).
Tout ceci a un coût c'est sûr mais je verrais cela comme une bonne chose pour couper court à ce genre de débat, source de frustrations et pertes de temps

[Uther]

Pour ce qui est du troll éternel Allman vs K&R, je dirait qu'il n'a vraiment pas lieu d'être. Non seulement la différence n'est au final pas vraiment importante, mais en plus ils peuvent se mélanger sans que ça pose vraiment de problème de lisibilité tant que l'indentation reste propre.

Personnellement j’utilise le K&R, qui a l'avantage d'être plus concis, sauf dans des cas particuliers ou le Allman apporte vraiment un plus de lisibilité comme

Code :

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

1
2
3
4
5
6
if( condition longue
    && complexe
    && sur plusieurs lignes)
{
    code
}

où il est utile pour bien séparer la condition du corps du bloc.

La réflexion fonctionne tout aussi bien sur des champs public que sur des méthodes. De plus, même si la génération des accessors peut être facilitée dans des IDE modernes comme Eclipse, ça reste lourd à la maintenance pour une plus-value qui reste chimérique.

Le problème des getter/setter n'a rien a voir avec l'introspection, ou la lisibilité, c'est même plutôt une plaie à ce niveau.

Ils sont là car ils servent d'interface aux javabean. Un bean se doit d'offrir une encapsulation forte. Grâce au getter/setter les beans ont un contrôle complet sur leur propriétés qu'il peuvent restreindre (read/write only), vérifier, générer à la voler, ... etc
Certes c'est lourd de faire un getter/setter quand on ne fait qu'une opération d'écriture/lecture de variable (Sun/Oracle devrait vraiment se pencher sur une syntaxe spéciale pour les propriétés). Mais ça permet de pouvoir faire évoluer l'opération dans le futur pour par exemple ajouter un contrôle sur un setter, ce qui n'est pas possible avec un accès direct à un champ.