Discussion :

[NevilClavain]

A priori tous les IDE permettent le paramétrage du nombre d'espace "écran" associés à un caractère "tab", non ?

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

[andry.aime]

En java, l'utilisation de retour multiple est déconseillée par le "Code Convention". D'ailleurs, ça me rappelle un bug, au lieu d'utiliser un "break" pour quitter une boucle, le développeur à utiliser un return qui lui a éjecté de la fonction qui retourne un void .

Pour le Code Style, on a l'habitude de créer un Template dans eclipse et on le partage pour tous les développeurs.

Quelles règles de codage étranges avez-vous dû suivre ?

On ne nous a pas laissé un tag auto-fermante pour déclarer des beans ou des propriétés des beans dans un fichier de configuration de spring.
Utiliser

Code xml :

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

1
2
3
4
5
<bean id="id1" class="com.package.class1">
</bean>
<bean id="id2" class="com.package.class2">
	<property name="id1" ref="id1"></property>
</bean>

à la place de

Code xml :

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

1
2
3
4
<bean id="id1" class="com.package.class1" />
<bean id="id2" class="com.package.class2">
	<property name="id1" ref="id1" />
</bean>

[BenoitM]

Perso je trouve plus lisible des return au début et au milieu que de s'amuser a vérifier si ma fonction fait encore quelque chose.

[abriotde]

Pour l'indentation, il y a bien plus inteligent et souple : la tabulation. Ainsi en changeant le nombre d'espace d'une tabulation, chacun adapte le formatage. Deplus, à taper c'est plus rapide (ne serais-ce que pour éffacer 3*3=9 espaces= 3 tabulation ).
Dans les codes indenté par des espaces vous remarquerez qu'ils sont toujours mal indenté car à un moment on à rajouté des espaces au pif. Je travaille beaucoup en directement en prod sous VIM qui ne rajoute pas automatiquement les espaces mais qui permet d'indenter rapidement le code en tabulation.

[SurferIX]

Pour l'indentation, il y a bien plus inteligent et souple : la tabulation. Ainsi en changeant le nombre d'espace d'une tabulation, chacun adapte le formatage. Deplus, à taper c'est plus rapide (ne serais-ce que pour éffacer 3*3=9 espaces= 3 tabulation ). Dans les codes indenté par des espaces vous remarquerez qu'ils sont toujours mal indenté car à un moment on à rajouté des espaces au pif.

C'est exactement l'inverse en pratique : un dev a appuyé trois fois sur tab et la parenthèse se situe pile poil aligné avec le code du dessus et l'autre dev qui affichera le même code avec une tabulation de 2 au lieu de 4 verra une le code décalé et par conséquent beaucoup moins lisible. Alors qu'avec des espaces, dans tous les cas, on l'a mis à un endroit, et sur tous les ordis, ça apparaît au même endroit.

Je travaille beaucoup en directement en prod sous VIM qui ne rajoute pas automatiquement les espaces mais qui permet d'indenter rapidement le code en tabulation.

Pareil. Dan mon .vimrc :

set expandtab
set tabstop=4
set shiftwidth=4

Comme ça en appuyant sur tab ça fait ce que tu décris (= une fois sur tab), ça décale de 4 et en plus au lieu d'un caractère tabulation ce sont des espaces !

[pyros]

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

Je suis partir au bout de 3 mois et la boite à coulé 6 mois après...

Sinon dans le genre règle pas vraiment stupide mais un peu lourdingue, obligation de toujours mettre un else après un if. On se retrouve alors avec ça un peu partout:

Code :

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

1
2
3
4
5
6
7
8
9
if ( toto )
{
  [...]
}
else
{
  // NOTHING
}

[NevilClavain]

Sinon dans le genre règle pas vraiment stupide mais un peu lourdingue, obligation de toujours mettre un else après un if. On se retrouve alors avec ça un peu partout:

Code :

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

1
2
3
4
5
6
7
8
9
if ( toto )
{
  [...]
}
else
{
  // NOTHING
}

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

[Uther]

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

Au contraire, tout l’intérêt d'indenter proprement avec des tabulation, c'est qu'on peut changer ça à n'importe quel moment sans que ça ait le moindre impact.
Tout le monde peut régler la taille des tabulation à la valeur qu'il souhaite personnellement sans impacter les autres.

[Katyucha]

L'obligation de commencer mes requêtes SQL... Même pour 2 lignes, je crois que ce fut un moment de solitude...

[azias]

Que tout le monde utilise la même indentation me parait indispensable, préfixé les noms des variables par leur type très utile, surtout quand on utilise un EDI à peu près potable (avec autocomplétion donc) pour se retrouver rapidement dans la jungle des variables. En revanche l'inversion de l'indentation, c'est vrai que c'est un peu étrange, j'imagine que c'est pour que le code

Dans les conventions auxquelles j'ai du, celle à laquelle j'ai eu le plus de mal à me faire est que les noms de variables, de fonctions, de classes... et les commentaires doivent être en français.

J'ai beau parlé assez mal a anglais, quand il s'agit de coder, il me faut toujours plusieurs minutes de réflexions pour trouver un nom en français alors que le nom en anglais est souvent rapide à trouver (sans doute, outre l'habitude, du fait que l'intégralité des docs d'API que j'ai devant les yeux en permanence sont en anglais).

A l'opposé, la convention la moins utilisée mais que j'ai trouvée la plus utile dans mon expérience passée (en fait une convention qui m'a été imposée dès mes premières d'étude) est de ne pas hésiter à utiliser des noms de variables descriptifs (donc assez long). Ça semble n’avoir aucun intérêt sur le moment, mais quand on reprend le code (la plupart du temps écrit par d'autres, quand ce n'est pas par des intérimaires de passage) plusieurs mois après, on se rend compte à quel point ça facilite les choses.

[BenoitM]

préfixé les noms des variables par leur type très utile, surtout quand on utilise un EDI à peu près potable (avec autocomplétion donc) pour se retrouver rapidement dans la jungle des variables.

Si tu as une jungle de variable il y a peut-être un problème ailleurs

[Darkzinus]

Si tu as une jungle de variable il y a peut-être un problème ailleurs

Dans du COBOL typiquement, le nombre de variables peut vite devenir très important (et ça peut vite avoir un côté "jungle") même pour des programmes relativement simples. Dès lors, il est judicieux de bien les nommer (si possible avec du fonctionnel) et éviter les variables de type I, J, K dans des tableaux à trois dimensions afin de faciliter la maintenance.

[Bluedeep]

Dans du COBOL typiquement, le nombre de variables peut vite devenir très important (et ça peut vite avoir un côté "jungle") même pour des programmes relativement simples. Dès lors, il est judicieux de bien les nommer (si possible avec du fonctionnel) et éviter les variables de type I, J, K dans des tableaux à trois dimensions afin de faciliter la maintenance.

En l'espèce, l'usage de la notaion hongroise Sys n'est pas ou peu critiqué dans le cadre des languages non objet. En revanche, c'est très critiqué dans le contexte des langage OO.

[el_slapper]

Dans du COBOL typiquement, le nombre de variables peut vite devenir très important (et ça peut vite avoir un côté "jungle") même pour des programmes relativement simples. Dès lors, il est judicieux de bien les nommer (si possible avec du fonctionnel) et éviter les variables de type I, J, K dans des tableaux à trois dimensions afin de faciliter la maintenance.

C'est totalement vrai pour du COBOL qui n'a que des variables globales à l'intérieur d'un module donné. Ca l'est moins pour d'autres langages plus isolés. Même dans un langage assez vieux comme le VBA, on a en général suffisement de possibilité d'encapsulation pour ne pas avoir de confusion. Tout au long du programme COBOL, I aura une et une seule valeur, et c'est pour ça qu'il faut éviter. Par contre, dans ma macro VBA, I sera différent de procédure en procédure, de fonction en fonction.

En bref : ce qui est intelligent dans un environnement précis peut devenir catastrophique dans un autre. Et il faut se méfier des règles absolues : elles sont généralement toutes issues d'un contexte, et à prendre avec des pincettes hors dudit contexte.

[Darkzinus]

C'est totalement vrai pour du COBOL qui n'a que des variables globales à l'intérieur d'un module donné. Ca l'est moins pour d'autres langages plus isolés. Même dans un langage assez vieux comme le VBA, on a en général suffisement de possibilité d'encapsulation pour ne pas avoir de confusion. Tout au long du programme COBOL, I aura une et une seule valeur, et c'est pour ça qu'il faut éviter. Par contre, dans ma macro VBA, I sera différent de procédure en procédure, de fonction en fonction.

En bref : ce qui est intelligent dans un environnement précis peut devenir catastrophique dans un autre. Et il faut se méfier des règles absolues : elles sont généralement toutes issues d'un contexte, et à prendre avec des pincettes hors dudit contexte.

Tout à fait d'accord, cela dépend effectivement des langages. Au final on en revient toujours à la question du codage "intelligent". Et globalement, les normes de codage pour un site, même si elles peuvent sembler contraignantes permettent un théorie de garantir une certaine homogénéité. En théorie, dis-je, car rien n'empêche de coder malgré tout n'importe comment sans se soucier de la maintenant derrière.

[BenoitM]

Dans du COBOL typiquement, le nombre de variables peut vite devenir très important (et ça peut vite avoir un côté "jungle") même pour des programmes relativement simples. Dès lors, il est judicieux de bien les nommer (si possible avec du fonctionnel) et éviter les variables de type I, J, K dans des tableaux à trois dimensions afin de faciliter la maintenance.

Mais si tu fais du COBOL, tu as un problème encore plus graveuh

[Darkzinus]

Mais si tu fais du COBOL, tu as un problème encore plus graveuh

Non aucun, j'ai plaisir à travailler sous l'éditeur ISPF

[Invité]

En revanche l'inversion de l'indentation, c'est vrai que c'est un peu étrange, j'imagine que c'est pour que le code

Arf ta phrase s'est achevée abruptement. Moi qui espérais enfin un élément de réponse sur cette étrange règle après 3 pages

Des idées sur la question ?

[shadowmoon]

Des idées sur la question ?

De mémoire, le pourquoi de cette règle (indentation inversée) a déjà été mentionné : éviter, dans le cas de if, for, while ou autres blocs du même genre, et plus ou moins imbriqués les uns dans les autres, d'avoir un effet "boomerang" : le code se décale de plus en plus vers la droite jusqu'à une "pointe", puis se décale dans l'autre sens formant alors, visuellement un > géant.

Cet effet peut nuire à la lecture du code en imposant un scrolling horizontal, des plus déplaisant.

[Invité]

Merci de la réponse très claire !