Discussion :

[Freem]

Parce que les tabulations ne sont pas encodées de la même manière d'une plate-forme à une autre et que si vous avez des développeurs sous Mac, d'autres sous Linux et d'autres sous Windows, c'est vite la galère.

Idem pour le nombre d'espaces, si vous versionnez vos code sous SVN ou Git, c'est l'enfer si chacun utilise un nombre d'espaces différents

Toi, tu confonds avec le retour à la ligne: \n, \r, \r\n selon l'OS. A noter que les éditeurs de texte dignes de ce nom gèrent ça sans souci...

Le problème c'est que chaque environnement va interpréter le "caractère TAB" de différentes façons.

"TAB" est bien trop volatile et a évolué différemment selon l'histoire. Est-ce qu'un TAB c'est une colonne multiple de 8 ? (UNIX) Est-ce qu'un TAB c'est une colonne multiple de 4 ? (Win, Mac) Est-ce qu'un TAB c'est une colonne multiple de 2 ? (Ceux qui pensent que 4 créent trop d'espace vide ).

Euh... Je sais pas pour mac, mais sous windows, par défaut, c'est 8, comme sous linux (je ne sais pas unix). D'ailleurs, m'est avis que c'est standard, hérité de l'époque ou ASCII régnait en maître.

Après, que quelqu'un règle son IDE pour les interpréter comme 2,3, 4, 6 ou 8 espaces, peu importe, puisque les autres verront leurs propres réglages sur leur écran. C'est là tout l'intérêt de la tabulation, justement, la souplesse.

Sinon la règle de codage la plus étrange que j'ai eu fût de ne pas dépasser 80 caractères à chaque ligne (espaces d'indentation compris !). Parfois on été obligés de passer un argument de fonction par ligne, même s'il n'y en avait qu'un seul

Certains ont parlé de vim (en fait, des TTY, parce que vim avec un émulateur de terminal supporte un nombre de caractères dynamique) mais il y a aussi le cas des gens ayant de petits écrans.
Bon, au boulot, ce n'est généralement pas le cas, mais il m'arrive souvent de programmer dans le train, et la, je n'ai pas d'écran large.
Autre point, même avec un écran large, en cours de débogage, la taille de l'écran se réduit drastiquement. Des lignes trop longues imposent de devoir scroller horizontalement, et toutes les souris n'ont pas cette possibilité. Sans compter que devoir tourner la tête de droite à gauche pour lire du code, c'est pénible (bon, j'exagère).
Malheureusement, et sans vouloir troller, certains langages "tout objet" favorisent l'écriture de lignes de code longues comme le bras...

l’imposition d’un nombre d’espaces pour l’indentation c'est pas si débile que ça, parce que mettre un caractère TAB ça peut potentiellement foutre un bordel monstre quand on trimbale les sources d'un éditeur à l'autre (cas des applis multi-plateforme)

Ben... non, si ta tabulation reste un caractère \t et pas une série d'espaces, ça ne pose aucun souci, le \t étant interprété de façon unique par un éditeur de texte avec une configuration donnée...

ha oui par contre la règle qui consiste à nommer les variables en fonction de leurs type (float, bool, int, gnagnagna); j'ai toujours trouvé ça complètement con. Ça n'apporte strictement rien, à part faire des noms de variables à coucher dehors.

Pour les langages non typés, c'est utile.
Genre, PHP, perl, shell, *basic...

J'ai également oublié l'interdiction du mot-clé "break" car "ce n'est pas une façon propre de sortir de la boucle"

Il y a aussi continue qui est généralement bannis.
Et ce n'est pas faux, que "ce n'est pas propre". En fait, ça peut potentiellement aboutir à du code spaghetti dans une boucle, plus il y a de break, et moins on peut lire facilement la totalité de la condition de sortie.

Je ne trouve pas ça stupide de l'interdire. Personnellement, je le fait aussi. Lorsque j'ai une méthode qui retourne une valeur, par exemple un int, je commence ma méthode par "int result" et je la termine par "return result". Et je ne mets pas d'autres "return" au milieu.

Ça permet d'éviter d'avoir des fonctions avec des "return" planqués, des fonctions avec du code mort situé après un "return". Personnellement, c'est le genre de règle que j'applique constamment.

Et d'ailleurs, selon les langages, le return multiple empêche des optimisations de la part du compilateur. C++ est un exemple.

Bon, après, honnêtement, j'utilise personnellement le return multiple. Avec des fonctions dont la taille moyenne est de 15-20 lignes, je pense que ça ne pose pas trop de problème de lisibilité

[Bluedeep]

Parce que les tabulations ne sont pas encodées de la même manière d'une plate-forme à une autre et que si vous avez des développeurs sous Mac, d'autres sous Linux et d'autres sous Windows, c'est vite la galère.

La tabulation c'est le code 9 sous tous les systèmes utilisant de l'ASCII. Merci de ne pas raconter n'importe quoi. C'est la convention fin de ligne et retour début de ligne qui varie suivant les systèmes (LF ou CR+LF, le couple CR+LF étant la norme pour les imprimantes "lignes", certains systèmes l'utilisent aussi pour les écrans, d'autres considèrent que le saut de ligne doit obligatoirement s'accompagner du retour début de ligne).

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

[Rayek]

Dans une boite j'ai eu le droit à : "Pas de SQL c'est mort comme langage" (c'était en 1999-2000)

Sinon j'ai eu aussi le : "Tu mets tes initiales au début des procédure stockées" (super si on est plusieurs sur le même module)
Bon celui la j'ai réussit à le faire changer par on met le module au début et plus les initiales

[4sStylZ]

Pour moi les normes de nommages sont fondamentales.

Des idées sur la question ?

Ouais! Clairement, "C'est pour ce genre de personne qu'on a inventé la camisole de force."

Bref, de mon côté, j'apprécie ces différents trucs :

Les normes de nommages claires et net , quelle qu’elles soient tant qu’elles sont pertinentes en fonction du langage et du fonctionnel.
En RPG-IV et Cobol, j'aime bien prendre 2 caractères pour nommer les variables. Cela permet d'identifier les zones fichiers (entendez par là le nom des tables), d'identifier rapidement le type d'une variable.
En Php j'aime bien nommé mes variables avec un i, b, a, ou s selon le type. Je trouve ca clair et propre, et on s'y adapte vite.

Bon par contre, pour un compteur de boucle "i" ou même une variable "k" et "j" pour un algorithme de tri ou donner un nom du genre « iCompteurUn » serait hyper verbeux.

Pour moi on doit nettement créer une norme au début de projet et la diffuser.

Mais évidemment, il faut être qualifié pour cela! Car on sait tous que chaque développeur à des petites préférences qui rendent parfois un peu dingo...

J'évite dans toutes les boucles complexes les GOTO et BREAK pour éviter la programmation spaghetti, sauf dans de traitement très simplistes, et généralement je m'arrange pour avoir qu'une sortie "break".

Mais parfois il m'est arrivé de sortir ce genre d'instructions pour des trucs hyper-efficaces et clairs, et je ne regrette pas...

Mon IDE actuel est paramétré de sorte à pouvoir indenter avec des tabulations générant des espaces, et c'est pour moi plus intéressant, sans amener à avoir une indentation pérave.

Si quelqu'un décale l'indentation, c'est que son IDE est mal paramétré, ou alors il commet selon moi une erreur.

Maintenant si je préfère les espaces multiples aux tabs, c'est simplement que j'ai eu quelques problèmes en copiant mon code sur des IDE de l’âge de pierre, pour des besoins spécifiques, qui eux ont flingué mon indentation et aussi qu’on m’a expliqué que les indentations pouvait être mal digéré par des changements de plateformes, à tort ou à raison je n’ai pas creusé le sujet.

Je suis partisan de donner une limite de caractère sur une seule ligne, et de limiter au maximum le nombre d'instructions sur une seule ligne, l'exception que je tolère est pour une série d’instruction très courte et claire.

80 caracs max ont l'avantage de permettre d'ouvrir deux fichiers côte à côte dans un éditeurs sans avoir à scroller, tout en gardant ma colonne explorateur ouverte mais j'avoue que c'est parfois peu, et que cela oblige à couper des instructions pas si longue que cela.

C'est pour ça que je choisirais une limite de 100 ou 120 c'est surement mieux.

[CinePhil]

Dans une boite j'ai eu le droit à : "Pas de SQL c'est mort comme langage" (c'était en 1999-2000)

12 ans plus tard, le SQL est toujours bien vivant. Et la boîte en question ?

Sinon j'ai eu aussi le : "Tu mets tes initiales au début des procédures stockées" (super si on est plusieurs sur le même module)
Bon celui la j'ai réussit à le faire changer par on met le module au début et plus les initiales

Dans le nom de la procédure stockée ?
Ça sert à quoi ? Et s'il y un Jean Dupont et un Jules Durand ?

Par contre, mettre un minimum d'infos en commentaire au début de la procédure, ça me semble en effet une bonne chose, comme pour tout programme d'ailleurs !

En Php j'aime bien nommé mes variables avec un i, b, a, ou s selon le type. Je trouve ca clair et propre, et on s'y adapte vite.

integer, boolean, array, string ?
Mouais... question d'habitude sans doute mais je préfère encore avoir des noms de variables qui signifient quelque chose et dont le type devient en quelque sorte implicite. En tout cas, ça ne m'a jamais gêné de ne pas connaître le type de la variable en lisant son nom, surtout que PHP est non typé et qu'une variable peut potentiellement changer de type.

Par contre, dans les commentaires des fonctions, surtout en Javascript, j'aime bien indiquer quel est le type du paramètre attendu :

Code :

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

1
2
3
4
5
6
7
8
9
/**
 * maFonction
 * Son utilité
 * @param String param1 : sa définition
 * @param Integer param2 : sa définition
 * @return String : description ou @return nothing
 */
function maFonction(param1, param2)
{

Pour ce qui est de la longueur des lignes, du fait de l'indentation, ça devient rapidement insuffisant de se fixer une limite et le scrolling horizontal ne me gène pas, tant qu'il est justifié par le fait que c'est dû à une seule instruction ou un seul morceau d'instruction cohérent.
Exemples :

Code PHP :

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

1
2
3
<a href="<?php echo $base.'/ma-page/'.$param['le_parametre'].'-'.$un_autre_parametre.'.html'; ?>"
	class="maClasseCSS"
>

La première ligne fait plus de 80 caractères mais elle est insécable. Par contre, la balise peut être découpée en autant de lignes qu'il y a de paramètres plus une pour le caractère de fermeture sur le principe de l'indentation (toujours avec tabulation !).

[Deaf]

Je l'ai jamais recroisée depuis que je bosse, mais pendant mes études un prof imposait une règle plutôt "sympa" pour le C:

Mettre le point-virgule de fin d'instruction à la colonne 80

Bah oui, comme ça, les point-virgules sont tous alignés!

[GLDavid]

Bonjour,

Voici la règle stupide de notre département: programmer obligatoirement en C#.
Alors, vous allez me bondir dessus en me traitant de tous les noms. Vous auriez raison sauf que vous oubliez le contexte.
Je bosse dans une société pharmaceutique. Nous travaillons donc sur des composés chimiques et utilisons donc des outils pour calculer diverses propriétés chimiques. Des outils tels PipelinePilot ou autres reposent sur la librairie Java CDK. Il n'y a pas mieux que ça.
Mais avec cette règle, on a juste oublier quelque chose d'important: il n'y a pas d'équivalent en C#. Du coup, on réinvente la roue avec tout son lot de vérification.

Ma solution ? Du web service. Java s'occupe de la partie chemoinformatique et C# n'est qu'un client.

Voilà un bel exemple de méconnaissance de l'écosystème d'un framework.

@++

[Rayek]

12 ans plus tard, le SQL est toujours bien vivant. Et la boîte en question ?

Elle existe toujours et ils se sont mis au SQL (un pote y bosse) mais bon tu demandes un fichier csv avec séparateur, ils te filent un fichier du style
NOMTXTPRENOMTXTADRESSETXTCODEPOSTAL

Dans le nom de la procédure stockée ?
Ça sert à quoi ? Et s'il y un Jean Dupont et un Jules Durand ?

Ça a été ma première remarque quand je suis arrivé dans la boite

Par contre, mettre un minimum d'infos en commentaire au début de la procédure, ça me semble en effet une bonne chose, comme pour tout programme d'ailleurs !

On a mis un cartouche au début avec date, nom, commentaires

[CinePhil]

Elle existe toujours et ils se sont mis au SQL (un pote y bosse) mais bon tu demandes un fichier csv avec séparateur, ils te filent un fichier du style
NOMTXTPRENOMTXTADRESSETXTCODEPOSTAL

J'imagine le bordel le jour où ils enregistrent un nom finissant par TXT !
Des fois qu'on ait de la visite extra-terrestre le 21 décembre...