# Le club des professionnels en informatique > La taverne du Club : Humour et divers > Humour Informatique >  Quelle est la rgle de codage la plus trange que vous avez t forc de suivre ?

## Hinault Romaric

*Quelle est la rgle de codage la plus trange que vous avez t forc de suivre ?*
*Fates-nous part de vos anecdotes*

Dans toute quipe de dveloppement, des rgles et des standards de conception sont adopts tout le long du cycle de dveloppement du produit.

En dehors des bonnes pratiques et des patrons de conceptions ou tout autre standard permettant de coder proprement, certaines quipes disposent dautres rgles de codage qui doivent tre obligatoirement appliques par les dveloppeurs.

Si lon trouve certaines rgles assez utiles pour avoir un produit de qualit, dautres par contre sont tranges, drles  ou pire, nont pratiquement aucun sens.

Dans un post sur le sujet sur le forum US stackoverflow, voici quelques rgles drles qui y sont recenses : l'interdiction dutiliser des retours multiples ; lobligation de faire prcder les noms des tables de la base de donnes des caractres  tbl ,  limposition dun nombre despaces pour lindentation ou encore lutilisation de linversion de lindentation. Par exemple :



```

```

et



```

```


*Et vous ?*

 ::fleche::   Quelles rgles de codage tranges avez-vous d suivre ?

----------


## Kaamo

> limposition dun nombre despaces pour lindentation


En quoi cette rgle serait farfelue ? Si un tel utilise 3 espaces, un autre 2, etc ... on ne s'y retrouve plus. Je trouve a plutt important de spcifier le nombre d'espaces pour l'indentation.
Surtout que selon le vcu du dveloppeur, l'indentation diffre fortement (je pense au style GNU, diffrent de celui du C, ou Java etc).

----------


## LooserBoy

> Quelles rgles de codage tranges avez-vous d suivre ?


- Les prfixages tb pour les tables, ps(i/u/d/s) pour les procs, tr(i/u/d) pour les triggers,... le tout sur des bdds comme SqlServer ou Oracle...
- Indenter le code seulement avec des espaces, surtout pas de tabulations...  ::calim2::  Chacun indentant au niveau o a lui plait (2/3/4 espaces selon les cas...)
- Convention de nommage donnant des nom de variables longs comme des jours sans internet avec rien  faire...
- Dcouper  outrance les classes dans de multiples dll (presque 1dll = 1 classe)  :8O: 

Heu... Je pense avoir fait le tour...

----------


## LooserBoy

> En quoi cette rgle serait farfelue ? Si un tel utilise 3 espaces, un autre 2, etc ... on ne s'y retrouve plus. Je trouve a plutt important de spcifier le nombre d'espaces pour l'indentation.
> Surtout que selon le vcu du dveloppeur, l'indentation diffre fortement (je pense au style GNU, diffrent de celui du C, ou Java etc).


Pourquoi ne pas utiliser la tabulation et choisir comment l'diteur va la reprsenter  l'cran?
Ce ne serait pas mieux?  ::mrgreen::

----------


## CARNIBAL

L'obligation de dvelopper sans bug ... non je plaisante ! ::aie::

----------


## fregolo52

Heureusement que des langages comme python vite ce genre de drive.

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

----------


## saccoche

> En quoi cette rgle serait farfelue ? Si un tel utilise 3 espaces, un autre 2, etc ... on ne s'y retrouve plus. Je trouve a plutt important de spcifier le nombre d'espaces pour l'indentation.
> Surtout que selon le vcu du dveloppeur, l'indentation diffre fortement (je pense au style GNU, diffrent de celui du C, ou Java etc).


Je confirme que les merges sont ingrables sans ce genre de cas.

----------


## Freem

D'un autre ct, les espaces... bon, si vraiment a gne un dev, il utilise un outil pour les mettre  sa sauce, puis un outil pour les mettre  la sauce de l'quipe, et basta...

(D'ailleurs, je me demande si cette procdure n'est pas automatisable avec git, faudra que je cherche, un jour)

Dans mon cas, je dirais, dvelopper en franais. Ce n'est pas bizarre en soit, mais je suis tellement rd  taper des noms anglais que je dois rflchir 2 minutes avant de trouver un nom franais assez court et reprsentatif. Pire que le scrabble...

Sinon, l'inversion de tab, c'est... moche  ::D: 

PS: pour ceux qui aiment python pour son indentation force: personnellement, c'est justement le genre de trucs que je n'apprcierais pas. Il arrive que mettre 2 instructions sur la mme ligne soit pertinent au regard de la lisibilit et rende le tout plus simple  lire.
Bon, aprs, question de style, bien sr, et puis, a a l'avantage d'imposer aux dbutants de bonnes habitudes.

----------


## Melem

> l'interdiction dutiliser des retours multiples


En gnral, je suis plutt pour cette interdiction. Notamment en langage C. Comapez les codes suivants :


```

```



```

```


Dans la deuxime version, avec retours multiples, type1_delete est appele  deux endroits diffrents. Il y a donc une mauvaise factorisation du code. Et plus on a des allocations, plus les rptitions seront nombreuses. Et ce nombre augmente aussi avec le nombre de points de retour dans la fonction. Car il faut faire le nettoyage avant chaque return. En gnral. En clair, il vaut mieux bannir les retours multiples. L'exception est peut-tre lorsqu'on implmente un algo dj bien connu. Dans les autres cas, je recommande l'utilisation d'un seul retour.




> limposition dun nombre despaces pour lindentation


Ici aussi je suis pour. Il faut soit imposer un nombre d'espaces, soit imposer l'utilisation de tabulation, mais il ne faut jamais mlanger les deux en tous cas. Pour avoir un max de compatibilit avec les divers diteurs et afficheurs de texte, il vaut mieux prfrer la premire.




> lutilisation de linversion de lindentation


Ca c'est fort ! Je n'en ai jamais entendu parl et je ne saisis pas l'intrt.

Sinon, pour les rgles de codage bizarres que l'on a m'a dj imposes, l'else if de la sorte :


```

```

Tout le monde met else et if sur la mme ligne quand mme  ::lol:: .

----------


## neopium

> Pourquoi ne pas utiliser la tabulation et choisir comment l'diteur va la reprsenter  l'cran?
> Ce ne serait pas mieux?


Parce que les tabulations ne sont pas encodes de la mme manire d'une plate-forme  une autre et que si vous avez des dveloppeurs sous Mac, d'autres sous Linux et d'autres sous Windows, c'est vite la galre.

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 diffrents

----------


## Barsy

> Pourquoi ne pas utiliser la tabulation et choisir comment l'diteur va la reprsenter  l'cran?
> Ce ne serait pas mieux?


Parce qu'il est certains cas o il faut que l'indentation se fasse au niveau d'un caractre de la ligne du dessus. Par exemple a :



```

```

Ici la deuxime ligne doit tre aligns sur la parenthse ouvrante de la premire ligne. C'est impossible  faire si on utilise des tabulations.

Beaucoup d'IDE remplacent par dfaut les tabulations par des espaces.




> Dcouper  outrance les classes dans de multiples dll (presque 1dll = 1 classe)


j'ai vu un projet un peu dans le mme genre, mais au lieu d'y avoir une DLL par classe, les classes taient dcoupes en 3 DLL : une DLL avec les attributs/accesseurs des classes, une avec les mthodes et la troisime avec les interfaces. a rend impossible l'utilisation de "private", tout doit tre "public". Et  lire c'est bordlique, la classe AVoiture contient les attributs, la classe MVoiture les mthodes avec en attribut un lment de type AVoiture.

Bref, pourquoi faire simple quand on peut se casser le cul ?  ::aie::

----------


## Kaamo

> Pourquoi ne pas utiliser la tabulation et choisir comment l'diteur va la reprsenter  l'cran?
> Ce ne serait pas mieux?


Le problme c'est que chaque environnement va interprter le "caractre TAB" de diffrentes faons.

"TAB" est bien trop volatile et a volu diffremment 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 crent trop d'espace vide  ::D:  ).

C'est pourquoi  on a impos une configuration de l'IDE pour chaque nouveau dveloppeur qui rejoint notre projet : 
- Expand Tabs to Spaces
- Number of Spaces by Indent : 2

Et comme l'a mentionn saccoche (edit : et les autres), c'est pour que les merges ne deviennent pas un truc ingrable et que le code soit interoprable qu'importe le systme/IDE utilis

----------


## Lynix

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

----------


## Uther

> Heureusement que des langages comme python vite ce genre de drive.


Pour tomber dans la drive inverse  ::(: 




> D'un autre ct, les espaces... bon, si vraiment a gne un dev, il utilise un outil pour les mettre  sa sauce, puis un outil pour les mettre  la sauce de l'quipe, et basta...


Certes mais le reformateur de code automatique, a peux aussi faire des horreurs parfois.




> Dans mon cas, je dirais, dvelopper en franais. Ce n'est pas bizarre en soit, mais je suis tellement rd  taper des noms anglais que je dois rflchir 2 minutes avant de trouver un nom franais assez court et reprsentatif. Pire que le scrabble...


Je dirais que le plus gros problme c'est que a finis presque systmatiquement par tourner au Franglais. Du coup on ne sait plus si on a un Bouton ou un Button, un statut ou un status, ...




> Parce que les tabulations ne sont pas encodes de la mme manire d'une plate-forme  une autre et que si vous avez des dveloppeurs sous Mac, d'autres sous Linux et d'autres sous Windows, c'est vite la galre.


Les tabulation sont heureusement encode pareil, quelque soit l'OS.




> Parce qu'il est certains cas o il faut que l'indentation se fasse au niveau d'un caractre de la ligne du dessus. Par exemple a :
> 
> 
> 
> ```
> 
> ```
> 
> Ici la deuxime ligne doit tre aligns sur la parenthse ouvrante de la premire ligne. C'est impossible  faire si on utilise des tabulations.


Dans ce cas l il faudrait idalement utiliser,  la fois les tabulations et les espaces :


```

```

Dans le meilleurs des mondes, les tabulations devraient marquer l'indentation, les espaces l'alignement. Ainsi tout le monde pourrait choisir la taille de ses tabulation,  sa guise.
Le problme c'est que comme chacun fait sa sauce, au final on fini par aller au plus simple, c'est espaces partout

----------


## loufab

Composer des requtes dans le code alors qu'elles n'ont rien de dynamiques. 
Composer des requtes dans le code alors qu'elles supportent aisment des fonctions natives.

Ceux qui pratique MS ACCESS comprendront...  ::aie::

----------


## Darkzinus

> En quoi cette rgle serait farfelue ? Si un tel utilise 3 espaces, un autre 2, etc ... on ne s'y retrouve plus. Je trouve a plutt important de spcifier le nombre d'espaces pour l'indentation.
> Surtout que selon le vcu du dveloppeur, l'indentation diffre fortement (je pense au style GNU, diffrent de celui du C, ou Java etc).


Tout  fait d'accord ! Une standardisation permet de lire bien plus aisment le code. En cobol typiquement, je pense mme que c'est indispensable par exemple (gnralement une indentation de 3).

----------


## Bluedeep

La rgle la plus trange ?

Pour ma part, et sans hsiter, il y a de cela sept ou huit ans, un projet chez un client o le DBA ne voulait pas de procdure stockes .... ::mouarf::   :8O:

----------


## CinePhil

> l'interdiction dutiliser des retours multiples ;


Euh... c'est quoi des "retours multiples" ?




> lobligation de faire prcder les noms des tables de la base de donnes des caractres  tbl


Prfixer une table avec "tbl" n'apporte rien. Par contre, prfixer les tables comme le prconise SQLPro apporte une information (mon standard adapt de celui de SQLPro) :
- te_ pour les tables issues des entits types du MCD ;
- tj_ pour les tables de jointure, donc les tables issues des associations du MCD ;
- th_ pour les tables issues d'un hritage ;
- tr_ pour les tables de rfrence (pays, type, famille, civilit...).




> limposition dun nombre despaces pour lindentation


a ce n'est pas idiot du tout mais il vaut mieux carrment utiliser la tabulation pour indenter, tant que le langage utilis n'impose pas autre chose.
La variabilit de la taille des tabulations d'un systme  l'autre est un faux problme.
Chez moi, la tabulation vaut 4 caractres. Dans les balises CODE sur DVP, elles valent 8 caractres. L'alignement est respect dans les deux cas.
Ce qu'il faut  tout prix viter, c'est des indentations de taille variable  l'aide d'espaces dans le mme programme. On finit par ne plus savoir  quel bloc appartient telle ligne et c'est l'horreur  dboguer. Et je ne parle pas de ceux qui codent au kilomtre sans indentation du tout !  ::calim2:: 




> lutilisation de linversion de lindentation


Jamais vu a ! Quel est le dictateur tordu qui impose cette connerie ?  :8O: 

Il parat qu'il existe un standard de nommage dans les BDD de l'tat (ou de mon ministre, je ne sais pas exactement) et je le trouve imbuvable, au vu d'une des BDD codes de la sorte dont j'ai  m'occuper de temps en temps !
Comme les BDD que je cre sont uniquement  usage interne et que je suis le seul DBA, j'applique mon standard.

----------


## SylvainPV

Les retours multiples, c'est comme son nom l'indique lorsqu'une fonction a plusieurs instructions return  l'intrieur de structures conditionnelles.

Sinon la rgle de codage la plus trange que j'ai eu ft de ne pas dpasser 80 caractres  chaque ligne (espaces d'indentation compris !). Parfois on t obligs de passer un argument de fonction par ligne, mme s'il n'y en avait qu'un seul  ::roll::

----------


## NevilClavain

limposition dun nombre despaces pour lindentation c'est pas si dbile que a, parce que mettre un caractre TAB a peut potentiellement foutre un bordel monstre quand on trimbale les sources d'un diteur  l'autre (cas des applis multi-plateforme)

----------


## NevilClavain

ha oui par contre la rgle qui consiste  nommer les variables en fonction de leurs type (float, bool, int, gnagnagna); j'ai toujours trouv a compltement con. a n'apporte strictement rien,  part faire des noms de variables  coucher dehors.

----------


## Lynix

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

----------


## Barsy

> Les retours multiples, c'est comme son nom l'indique lorsqu'une fonction a plusieurs instructions return  l'intrieur de structures conditionnelles.


Je ne trouve pas a stupide de l'interdire. Personnellement, je le fait aussi. Lorsque j'ai une mthode qui retourne une valeur, par exemple un int, je commence ma mthode 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" planqus, des fonctions avec du code mort situ aprs un "return". Personnellement, c'est le genre de rgle que j'applique constamment.




> Sinon la rgle de codage la plus trange que j'ai eu ft de ne pas dpasser 80 caractres  chaque ligne (espaces d'indentation compris !). Parfois on t obligs de passer un argument de fonction par ligne, mme s'il n'y en avait qu'un seul


a non plus ce n'est pas forcment idiot. Combien de fois on voit du code avec des lignes de 500 caractres qui imposent un scroll horizontal. Aprs, il faut adapter la taille des lignes en fonction des crans des dveloppeurs. 80 caractres c'est court, sur mon dernier projet on avait imposer 200 caractres maximum.

C'est ainsi qu'on se rend compte que des rgles qui semblent tranges  certains peuvent aller de soit pour d'autres. Par exemple le prfixage des variables, je ne l'ai jamais fait, mais je peux comprendre la raison qui poussent certains  l'appliquer.
De mme, dans un autre topic (il y a fort longtemps), quelqu'un se plaignait qu'on lui impose d'crire "if (monBoolen == true)" au lieu de juste "if (monBoolen)" (et normalement il faut crire "if (true == monBoolen)"). Pour a aussi je peux comprendre qu'il y en ait qui l'impose.

Bref, les rgles de codage, je pense que peut importe qu'elles semblent stupide ou non, le principal c'est que tout le monde utilise les mmes.

----------


## Bluedeep

> ha oui par contre la rgle qui consiste  nommer les variables en fonction de leurs type (float, bool, int, gnagnagna); j'ai toujours trouv a compltement con. a n'apporte strictement rien,  part faire des noms de variables  coucher dehors.


Notation hongroise dans sa variante "System"; on a dj dbattu de cela; a n'a en effet aucun sens avec  les langages OO. La notation hongroise en variante "Apps" peut nanmoins se justifier dans certains cas.

----------


## Bluedeep

> limposition dun nombre despaces pour lindentation c'est pas si dbile que a, parce que mettre un caractre TAB a peut potentiellement foutre un bordel monstre quand on trimbale les sources d'un diteur  l'autre (cas des applis multi-plateforme)


A priori tous les IDE permettent le paramtrage du nombre d'espace "cran" associs  un caractre "tab", non ?

----------


## Gugelhupf

Deuxime page et aucune rfrence  Jenkins pour l'intgration continue et les conventions d'criture  ::aie::

----------


## air-dex

> En gnral, je suis plutt pour cette interdiction. Notamment en langage C. Comapez les codes suivants :
> 
> 
> ```
> 
> ```
> 
> 
> 
> ...


Il y a aussi la lisibilit du code  prendre en compte. Et dans ce cas la deuxime version est bien plus indique. Et puis l'exemple ne prend pas en exemple les niveaux d'indentation de now_do_useful_stuff();  prendre en compte. Si t'as envie de te retrouver avec du code de now_do_useful_stuff(); en quasi alignement  droite sur ton IDE, c'est ton problme  ::aie:: . En attendant je prfre personnellement garder mon code lisible,  gauche dans l'IDE et lutter contre cette "programmation boomerang" *** en ayant des retours multiples.





> Sinon, pour les rgles de codage bizarres que l'on a m'a dj imposes, l'else if de la sorte :
> 
> 
> ```
> 
> ```
> 
> Tout le monde met else et if sur la mme ligne quand mme .


 la limite, dans du code pas nettoy ou pas optimis, ceci peut-tre acceptable :


```

```

Mais pas en dehors.


*** : "_programmation boomerang_" est une rfrence au niveau d'indentation croissant puis dcroissant du code d aux boucles, formant ainsi une ligne (brise) dont la forme voque celle d'un boomerang. Le premier code de Melem permet de voir cela.

----------


## nickyla

> ha oui par contre la rgle qui consiste  nommer les variables en fonction de leurs type (float, bool, int, gnagnagna); j'ai toujours trouv a compltement con. a n'apporte strictement rien,  part faire des noms de variables  coucher dehors.


Oui d'accord de manire gnrale,sauf si t'as la malheureuse exprience de dvelopper avec un langage non typ style PHP orient objet (par exemple), il y a des cas, si tu n'explicite le type dans le nom de la variable, si tu relis ton code quelques semaines  plus tard, tu peux perdre pas mal de temps avant d'tre  l'aise avec ton module ou mme une simple classe

----------


## andry.aime

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

Pour le Code Style, on a l'habitude de crer un Template dans eclipse et on le partage pour tous les dveloppeurs.




> Quelles rgles de codage tranges avez-vous d suivre ?


On ne nous a pas laiss un tag auto-fermante pour dclarer des beans ou des proprits des beans dans un fichier de configuration de spring.
Utiliser


```

```

 la place de


```

```


 ::mrgreen::

----------


## BenoitM

Perso je trouve plus lisible des return au dbut et  au milieu que de s'amuser a vrifier 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.

----------


## grunk

> Sinon la rgle de codage la plus trange que j'ai eu ft de ne pas dpasser 80 caractres  chaque ligne (espaces d'indentation compris !). Parfois on t obligs de passer un argument de fonction par ligne, mme s'il n'y en avait qu'un seul


C'est un hritage historique des cartes perfores d'IBM qui avaient 80 colonnes.

Ensuite y se trouve que les vrais barbus sont bien connus pour encore coder sous vi sur un cran de 14 pouces , du coup les 80 caractres on encore du sens.  ::mrgreen:: 

Plus qu'un nombre de caractres je pense qu'il faut absolument viter le scroll horizontal et si possible viter de devoir dplacer son regard de gauche  droite sans cesse pour lire un code.

----------


## abriotde

> la limite, dans du code pas nettoy ou pas optimis, ceci peut-tre acceptable :
> 
> 
> ```
> 
> ```
> 
> Mais pas en dehors.




```

```

Avoir un seul return en fin clarifie parfois le code. Dans notre cas ou se sont juste de petits tests de conditions initial ce n'est pas justifier. Mais il faut viter de multiplier ces return partout. Une solution : une variable que l'on ajoute comme ici. On vite le code boomerang.

----------


## _skip

> Je ne trouve pas a stupide de l'interdire. Personnellement, je le fait aussi. Lorsque j'ai une mthode qui retourne une valeur, par exemple un int, je commence ma mthode 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" planqus, des fonctions avec du code mort situ aprs un "return". Personnellement, c'est le genre de rgle que j'applique constamment.


Comme quoi les points de vue peuvent changer d'une personne  l'autre.

Perso je dclare les variables au moment o cela devient ncessaire en rgle gnral. Par consquent, en aucun cas je ne dclare une return value en dbut de la fonction en comptant sur le code qui suit pour la "garnir" convenablement. Sauf si la construction l'impose.

Pour ce qui est des retours multiples, je trouve ceci tout  fait acceptable :



```

```

ou ceci :



```

```

Pourquoi? 
Parce que cela dcrit suffisamment bien le comportement de la fonction. Je ne parle pas de planter 36 return au milieu d'une ribambelle de if( else if() ).
L'important c'est que le travail de la mthode soit le plus lisible possible  la relecture, et pour a il est parfois plus simple de l'imaginer comme une autoroute sur laquelle tu prends la premire sortie si tu vois le bon panneau (o si tu ralises que t'es pas sur le bon chemin)..

----------


## pyros

Fraichement embauch sur un produit cod par des gnrations 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 rpondu que la seul rgle  suivre tait de ne pas utiliser de convention de codage car "a frustre le dveloppeur et lui fait perdre son temps. Tu dbute et moi j'ai 20 ans d'exprience alors crois moi quand je te dis que a sert  rien !".
Rsultat, un code illisible mlangeant a peu prs tout ce qu'on peu trouver...

Je suis partir au bout de 3 mois et la boite  coul 6 mois aprs...

Sinon dans le genre rgle pas vraiment stupide mais un peu lourdingue, obligation de toujours mettre un else aprs un if. On se retrouve alors avec a un peu partout:


```

```

----------


## NevilClavain

> A priori tous les IDE permettent le paramtrage du nombre d'espace "cran" associs  un caractre "tab", non ?


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

----------


## NevilClavain

> Sinon dans le genre rgle pas vraiment stupide mais un peu lourdingue, obligation de toujours mettre un else aprs un if. On se retrouve alors avec a un peu partout:
> 
> 
> ```
> 
> ```


L'ide derrire cette rgle 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 prcis, a peut te faire gagner un temps prcieux de recherche. Juste mettre un commentaire NOTHING effectivement c'est lourdingue et surtout a sert  rien... :;):

----------


## el_slapper

une rgle parmi les plus tranges que j'ai eu est la suivante : en cobol, pas de GO TO, _sauf GO TO FIN-DE-PARAGRAPHE en cas d'erreur_. Une espce de break, quoi.

L'ide sous-jacente est de retirer un niveau d'indentation : 


```

```

au lieu de 



```

```

a a son utilit, surtout si _blablabla..._ est fort verbeuse. Mais on peut toujours faire autrement, par exemple en grant un sous-paragraphe qui ne fait que blablabla. A l'poque, j'avais appri, mais j'en suis revenu. Mme si je le tolre dsormais chez les autres.


Dans les langages modernes, le return multiple peut avoir son utilit, mais quand il passe entre de mauvaises mains, provoque assez vite des horreurs. Mon exprience, c'est qu'un code de production prnne finit _toujours_ par passer entre de mauvaises mains.

Enfin, je dirais que mieux vaut un mauvais standard appliqu par tous, qu'un mlange de bons standards incompatibles entre eux.

----------


## Uther

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


Au contraire, tout lintrt 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 rgler la taille des tabulation  la valeur qu'il souhaite personnellement sans impacter les autres.

----------


## Katyucha

L'obligation de commencer mes requtes SQL... Mme pour 2 lignes, je crois que ce fut un moment de solitude...

----------


## Freem

> Parce que les tabulations ne sont pas encodes de la mme manire d'une plate-forme  une autre et que si vous avez des dveloppeurs sous Mac, d'autres sous Linux et d'autres sous Windows, c'est vite la galre.
> 
> 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 diffrents


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 grent a sans souci...




> Le problme c'est que chaque environnement va interprter le "caractre TAB" de diffrentes faons.
> 
> "TAB" est bien trop volatile et a volu diffremment 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 crent trop d'espace vide  ).


Euh... Je sais pas pour mac, mais sous windows, par dfaut, c'est 8, comme sous linux (je ne sais pas unix). D'ailleurs, m'est avis que c'est standard, hrit de l'poque ou ASCII rgnait en matre.

Aprs, que quelqu'un rgle son IDE pour les interprter comme 2,3, 4, 6 ou 8 espaces, peu importe, puisque les autres verront leurs propres rglages sur leur cran. C'est l tout l'intrt de la tabulation, justement, la souplesse.




> Sinon la rgle de codage la plus trange que j'ai eu ft de ne pas dpasser 80 caractres  chaque ligne (espaces d'indentation compris !). Parfois on t obligs de passer un argument de fonction par ligne, mme 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 caractres dynamique) mais il y a aussi le cas des gens ayant de petits crans.
Bon, au boulot, ce n'est gnralement pas le cas, mais il m'arrive souvent de programmer dans le train, et la, je n'ai pas d'cran large.
Autre point, mme avec un cran large, en cours de dbogage, la taille de l'cran se rduit 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 tte de droite  gauche pour lire du code, c'est pnible (bon, j'exagre).
Malheureusement, et sans vouloir troller, certains langages "tout objet" favorisent l'criture de lignes de code longues comme le bras...




> limposition dun nombre despaces pour lindentation c'est pas si dbile que a, parce que mettre un caractre 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 caractre \t et pas une srie d'espaces, a ne pose aucun souci, le \t tant interprt de faon unique par un diteur de texte avec une configuration donne...




> ha oui par contre la rgle qui consiste  nommer les variables en fonction de leurs type (float, bool, int, gnagnagna); j'ai toujours trouv a compltement con. a n'apporte strictement rien,  part faire des noms de variables  coucher dehors.


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




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


Il y a aussi continue qui est gnralement 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 mthode qui retourne une valeur, par exemple un int, je commence ma mthode 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" planqus, des fonctions avec du code mort situ aprs un "return". Personnellement, c'est le genre de rgle que j'applique constamment.


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

Bon, aprs, honntement, 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 problme de lisibilit  :;):

----------


## Bluedeep

> Parce que les tabulations ne sont pas encodes de la mme manire d'une plate-forme  une autre et que si vous avez des dveloppeurs sous Mac, d'autres sous Linux et d'autres sous Windows, c'est vite la galre.


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

----------


## azias

Que tout le monde utilise la mme indentation me parait indispensable, prfix les noms des variables par leur type trs utile, surtout quand on utilise un EDI  peu prs potable (avec autocompltion 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 franais.

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

A l'oppos, la convention la moins utilise mais que j'ai trouve la plus utile dans mon exprience passe (en fait une convention qui m'a t impose ds mes premires d'tude) est de ne pas hsiter  utiliser des noms de variables descriptifs (donc assez long). a semble navoir aucun intrt sur le moment, mais quand on reprend le code (la plupart du temps crit par d'autres, quand ce n'est pas par des intrimaires de passage) plusieurs mois aprs, on se rend compte  quel point a facilite les choses.

----------


## BenoitM

> prfix les noms des variables par leur type trs utile, surtout quand on utilise un EDI  peu prs potable (avec autocompltion donc) pour se retrouver rapidement dans *la jungle des variables*.


Si tu as une jungle de variable il y a peut-tre un problme ailleurs  ::mrgreen::

----------


## Darkzinus

> Si tu as une jungle de variable il y a peut-tre un problme ailleurs


Dans du COBOL typiquement, le nombre de variables peut vite devenir trs important (et a peut vite avoir un ct "jungle") mme pour des programmes relativement simples. Ds 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 trs important (et a peut vite avoir un ct "jungle") mme pour des programmes relativement simples. Ds 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'espce, l'usage de la notaion hongroise Sys n'est pas  ou peu critiqu dans le cadre des languages non objet. En revanche, c'est trs critiqu dans le contexte des langage OO.

----------


## el_slapper

> Dans du COBOL typiquement, le nombre de variables peut vite devenir trs important (et a peut vite avoir un ct "jungle") mme pour des programmes relativement simples. Ds 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'intrieur d'un module donn. Ca l'est moins pour d'autres langages plus isols. Mme dans un langage assez vieux comme le VBA, on a en gnral 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 diffrent de procdure en procdure, de fonction en fonction.

En bref : ce qui est intelligent dans un environnement prcis peut devenir catastrophique dans un autre. Et il faut se mfier des rgles absolues : elles sont gnralement 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'intrieur d'un module donn. Ca l'est moins pour d'autres langages plus isols. Mme dans un langage assez vieux comme le VBA, on a en gnral 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 diffrent de procdure en procdure, de fonction en fonction.
> 
> En bref : ce qui est intelligent dans un environnement prcis peut devenir catastrophique dans un autre. Et il faut se mfier des rgles absolues : elles sont gnralement toutes issues d'un contexte, et  prendre avec des pincettes hors dudit contexte.


Tout  fait d'accord, cela dpend effectivement des langages. Au final on en revient toujours  la question du codage "intelligent". Et globalement, les normes de codage pour un site, mme si elles peuvent sembler contraignantes permettent un thorie de garantir une certaine homognit. En thorie, dis-je, car rien n'empche de coder malgr tout n'importe comment sans se soucier de la maintenant derrire.

----------


## BenoitM

> Dans du COBOL typiquement, le nombre de variables peut vite devenir trs important (et a peut vite avoir un ct "jungle") mme pour des programmes relativement simples. Ds 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 problme encore plus graveuh  ::aie::

----------


## Darkzinus

> Mais si tu fais du COBOL, tu as un problme encore plus graveuh


Non aucun, j'ai plaisir  travailler sous l'diteur ISPF  ::mrgreen::

----------


## MorganGeek

> 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 acheve abruptement. Moi qui esprais enfin un lment de rponse sur cette trange rgle aprs 3 pages  :;): 

Des ides sur la question ?

----------


## shadowmoon

> Des ides sur la question ?


De mmoire, le pourquoi de cette rgle (indentation inverse) a dj t mentionn : viter, dans le cas de if, for, while ou autres blocs du mme genre, et plus ou moins imbriqus les uns dans les autres, d'avoir un effet "boomerang" : le code se dcale de plus en plus vers la droite jusqu' une "pointe", puis se dcale dans l'autre sens formant alors, visuellement un > gant.

Cet effet peut nuire  la lecture du code en imposant un scrolling horizontal, des plus dplaisant.

----------


## MorganGeek

Merci de la rponse trs claire !  ::zoubi::

----------


## 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 dbut des procdure stockes" (super si on est plusieurs sur le mme module)
Bon celui la j'ai russit  le faire changer par on met le module au dbut et plus les initiales

----------


## 4sStylZ

Pour moi les normes de nommages sont fondamentales.




> Des ides sur la question ?


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

Bref, de mon ct, j'apprcie ces diffrents trucs : 

*Les normes de nommages claires et net* , quelle quelles soient tant quelles sont pertinentes en fonction du langage et du fonctionnel.
En RPG-IV et Cobol, j'aime bien prendre 2 caractres 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 mme 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 crer une norme au dbut de projet et la diffuser.

Mais videmment, il faut tre qualifi pour cela! Car on sait tous que chaque dveloppeur  des petites prfrences 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 trs simplistes, et gnralement 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 paramtr de sorte  pouvoir indenter avec des tabulations gnrant des espaces, et c'est pour moi plus intressant, sans amener  avoir une indentation prave.

Si quelqu'un dcale l'indentation, c'est que son IDE est mal paramtr, ou alors il commet selon moi une erreur.

Maintenant si je prfre les espaces multiples aux tabs, c'est simplement que j'ai eu quelques problmes en copiant mon code sur des IDE de lge de pierre, pour des besoins spcifiques, qui eux ont flingu mon indentation et aussi quon ma expliqu que les indentations pouvait tre mal digr par des changements de plateformes,  tort ou  raison je nai pas creus le sujet.

Je suis partisan de donner une limite de caractre sur une seule ligne, et de limiter au maximum le nombre d'instructions sur une seule ligne, l'exception que je tolre est pour une srie dinstruction trs courte et claire.

80 caracs max ont l'avantage de permettre d'ouvrir deux fichiers cte  cte 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 bote en question ?  ::roll:: 




> Sinon j'ai eu aussi le : "Tu mets tes initiales au dbut des procdures stockes" (super si on est plusieurs sur le mme module)
> Bon celui la j'ai russit  le faire changer par on met le module au dbut et plus les initiales


Dans le nom de la procdure stocke ?  :8O: 
a sert  quoi ? Et s'il y un Jean Dupont et un Jules Durand ?  ::roll:: 

Par contre, mettre un minimum d'infos en commentaire au dbut de la procdure, 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 prfre 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 gn de ne pas connatre 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 paramtre attendu :


```

```

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 gne pas, tant qu'il est justifi par le fait que c'est d  une seule instruction ou un seul morceau d'instruction cohrent.
Exemples :


```

```

La premire ligne fait plus de 80 caractres mais elle est inscable. Par contre, la balise peut tre dcoupe en autant de lignes qu'il y a de paramtres plus une pour le caractre de fermeture sur le principe de l'indentation (toujours avec tabulation !).

----------


## Deaf

Je l'ai jamais recroise depuis que je bosse, mais pendant mes tudes un prof imposait une rgle plutt "sympa" pour le C:




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


Bah oui, comme a, les point-virgules sont tous aligns!  ::calim2::

----------


## GLDavid

Bonjour,

Voici la rgle stupide de notre dpartement: 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 socit pharmaceutique. Nous travaillons donc sur des composs chimiques et utilisons donc des outils pour calculer diverses proprits chimiques. Des outils tels PipelinePilot ou autres reposent sur la librairie Java CDK. Il n'y a pas mieux que a.
Mais avec cette rgle, on a juste oublier quelque chose d'important: il n'y a pas d'quivalent en C#. Du coup, on rinvente la roue avec tout son lot de vrification.

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

Voil un bel exemple de mconnaissance de l'cosystme d'un framework.

@++

----------


## Rayek

> 12 ans plus tard, le SQL est toujours bien vivant. Et la bote en question ?


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




> Dans le nom de la procdure stocke ? 
> a sert  quoi ? Et s'il y un Jean Dupont et un Jules Durand ?


a a t ma premire remarque quand je suis arriv dans la boite




> Par contre, mettre un minimum d'infos en commentaire au dbut de la procdure, a me semble en effet une bonne chose, comme pour tout programme d'ailleurs !


On a mis un cartouche au dbut avec date, nom, commentaires  ::mrgreen::

----------


## CinePhil

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


J'imagine le bordel le jour o ils enregistrent un nom finissant par TXT !  ::roll:: 
Des fois qu'on ait de la visite extra-terrestre le 21 dcembre...  ::mrgreen::

----------


## rt15

Presque toutes les normes de codage peuvent paratre trs logique  quelqu'un et trs trange  quelqu'un d'autres. Il faut dire aussi que les raisons pour l'existence de certaines de ces normes peuvent tre valables dans un certains contextes et beaucoup plus discutable dans d'autres (Cas de la notation hongroise ci-dessus).

On rencontre mme des gens contre des rgles trs reconnues comme "goto c'est le mal". ::roll::  Genre moi.


(image de xkcd)

3 fois le mme programme, qui copie le contenu d'un fichier vers un autre fichier :

Sans goto, traitement normal en premier :


```

```


Sans goto, traitement d'erreur en premier :


```

```



Avec goto :


```

```


Franchement, avec la premire solution, il est trs difficile de vrifier que les ressources sont fermes correctement. Et la deuxime me semble moins lisible que la troisime, mais c'est un peu subjectif peut tre.

Et pour rappel, Linux est bourr de goto...

----------


## Barsy

> Pour ce qui est des retours multiples, je trouve ceci tout  fait acceptable :
> 
> 
> 
> ```
> 
> ```
> 
> ou ceci :
> ...


Mais les codes que tu prsentes ci-dessus, c'est dans le meilleur des mondes. Dans la ralit, il n'est pas rare de tomber sur des codes avec des mthodes bourres de return et mme au mileu des boucles.

C'est comme pour le code  base de goto ci-dessus. C'est facile tous les label sont  la fin de la mthode. C'est rarement le rsultat que l'on obtient lorsque l'on autorise l'utilisation de goto dans un code...

----------


## sciencesmaths

```

```

----------


## el_slapper

> (.../...)C'est comme pour le code  base de goto ci-dessus. C'est facile tous les label sont  la fin de la mthode. C'est rarement le rsultat que l'on obtient lorsque l'on autorise l'utilisation de goto dans un code...


+1

Linus peut se permettre le GOTO, il a le niveau pour. Les rgles "standard" sont ddies aux programmeurs "standard" qui commettent pas mal d'horreurs. Je ne suis pas forcment toujours au dessus du standard, d'ailleurs, donc j'essaie de respecter les rgles - autant que je peux.

----------


## ManusDei

Il ne s'agit pas d'une rgle, mais d'une convention. Et comme toutes les conventions, elle est parfois contre productive (mme si a peut tre trs rare).

----------


## _skip

> Mais les codes que tu prsentes ci-dessus, c'est dans le meilleur des mondes. Dans la ralit, il n'est pas rare de tomber sur des codes avec des mthodes bourres de return et mme au mileu des boucles.
> 
> C'est comme pour le code  base de goto ci-dessus. C'est facile tous les label sont  la fin de la mthode. C'est rarement le rsultat que l'on obtient lorsque l'on autorise l'utilisation de goto dans un code...


Oh non tu te trompes, j'cris du code comme a trs souvent et je vis certainement dans un monde trs exigent s'il en est. Et il y a pire que a : j'accepte aussi de sortir d'une boucle par un return (le salaud  ::aie:: ).

Aprs que se passe-t-il si jamais je commence  avoir besoin de return partout? Ben je refactore, genre je dlgue les cas particuliers  de nouvelles mthodes. En fait il est rare que je dpasse le 2 niveaux d'indentation dans une mthode et si je dois scroller ou analyer les parenthses pour comprendre le flux de mon traitement il y a une petite voix qui me dit "t'es peut tre en train de faire de la merde", "ta mthode elle fait peut tre trop de choses".

Donc j'utilise volontiers un return en cours de fonction afin de bien documenter la rflexion, pr-condition non remplie? -> hop tu dgages d'ici. L'objet en cours est une pomme? -> hop dlgue  la mthode des pommes. Si tu te mets bien dans la peau d'une personne qui lit ton code naturellement de haut en bas, t'arrives bien  reprsenter la logique de ton traitement en utilisant des return *par exemple* de sous-mthodes.

----------


## Traroth2

> En quoi cette rgle serait farfelue ? Si un tel utilise 3 espaces, un autre 2, etc ... on ne s'y retrouve plus. Je trouve a plutt important de spcifier le nombre d'espaces pour l'indentation.
> Surtout que selon le vcu du dveloppeur, l'indentation diffre fortement (je pense au style GNU, diffrent de celui du C, ou Java etc).


Dans certaines quipes, on distingue mme les espaces des tabulations.

----------


## Traroth2

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


Ah ouais, quand mme...

----------


## Barsy

> Oh non tu te trompes, j'cris du code comme a trs souvent et je vis certainement dans un monde trs exigent s'il en est. Et il y a pire que a : j'accepte aussi de sortir d'une boucle par un return (le salaud ).
> 
> Aprs que se passe-t-il si jamais je commence  avoir besoin de return partout? Ben je refactore, genre je dlgue les cas particuliers  de nouvelles mthodes. En fait il est rare que je dpasse le 2 niveaux d'indentation dans une mthode et si je dois scroller ou analyer les parenthses pour comprendre le flux de mon traitement il y a une petite voix qui me dit "t'es peut tre en train de faire de la merde", "ta mthode elle fait peut tre trop de choses".
> 
> Donc j'utilise volontiers un return en cours de fonction afin de bien documenter la rflexion, pr-condition non remplie? -> hop tu dgages d'ici. L'objet en cours est une pomme? -> hop dlgue  la mthode des pommes. Si tu te mets bien dans la peau d'une personne qui lit ton code naturellement de haut en bas, t'arrives bien  reprsenter la logique de ton traitement en utilisant des return *par exemple* de sous-mthodes.


Je ne parlais pas de toi. Je parlais de tous ceux qui vont pondre un code pourri parce qu'on leur aura accord le droit de dvelopper de cette faon.

Heureusement qu'il y a des gens qui rflchissent quand ils codent, mais plus je fais ce mtier, plus j'ai l'impression qu'ils sont rares. Parfois, je me dis aussi que c'est un problme li  la prestation, les dveloppeurs savent qu'ils ne vont pas rester longtemps sur le projet alors ils ne s'investissent pas trop pour faire un travail correct, ce sera le prochain presta qui ptira des dfauts... Et qui  sont tour fera de la merde, pourquoi se casser le cul  faire du code propre alors que celui dont on hrite est calamiteux, c'est souvent mme impossible...

----------


## Squisqui

part pour la gestion d'erreurs, je n'ai personnellement jamais eu recours  goto.

Concernant l'indentation, si la boite contraint ses dveloppeurs  utiliser des polices monospaces en utilisant l'indentation prsent par Uther en dbut de topic (indentation par des tabulations et alignement pas des espaces). Chacun pourrait y aller  sa sauce avec son diteur sans que l'autre ait besoin d'utiliser un outil pour remettre en forme le code.

Chez pas mal de dbutants, je remarque souvent une non-indentation du premier niveau soit :


```

```

Malgr qu'on crive au final que trs trs peu sur la premire colonne, elle permet tout de mme de reprer rapidement le dbut et la fin d'une fonction.

Je fais parti des sauvages qui indentent avec 8 espaces et qui essaient de faire des lignes de 80 colonnes maximum...
Ainsi je compte pas mes indentations, je vois tout de suite quand il y en a plus de 3 ou 4 et me demande si j'cris de la merde. Les 80 colonnes se retrouvent de toute faon bouffes parce qu'il n'y a qu'en Math qu'on dclare systmatiquement des noms de variable et de fonction  une lettre qui ne veulent rien dire... Au final, c'est surtout pour qu'une ligne tienne sur une ligne de l'cran je laisse de la place  cot de l'diteur pour voir d'autres choses sur mon cran 5/4  ::aie::

----------


## Katyucha

> Bonjour,
> 
> Voici la rgle stupide de notre dpartement: programmer obligatoirement en C#.
> 
> @++


J'ai l'impression qu'on bosse dans la mme boite... mme si je sais que c'est faux  ::D: 
Les boites o le langage est impos, cela me fait rire... Qu'on essaye de prioris le plus maitris => OK. Mais chaque langage a un domaine de prdilection


PS personnel : coucou GLDavid !! ca fait un bail !

----------


## CinePhil

> Je ne rponds ni aux messages prives, ni aux messages plein de fautes...


Et  ceux qui font des fautes dans leur signature ?  ::mrgreen::

----------


## Katyucha

> Et  ceux qui font des fautes dans leur signature ?


Cette faute est historique, je crois qu'elle date depuis le passage de ce forum en vBulletin 

FIN du HS  ::D:

----------


## Troudhyl

> De mme, dans un autre topic (il y a fort longtemps), quelqu'un se plaignait qu'on lui impose d'crire "if (monBoolen == true)" au lieu de juste "if (monBoolen)" (et normalement il faut crire "if (true == monBoolen)").


Pourquoi ? Je ne connais pas cette "rgle" mais je l'observe souvent...
Comme rgle casse-pied j'allais justement citer le fait de prciser tout le temps == true ou == false au lieu de ne rien mettre ou juste '!'. Pareil pour les tests de pointeurs, rajouter != 0 ou != NULL, c'est lourd...
En Qt, les nom de fonction contiennent le verbe. Par exemple : string.isEmpty(). Donc if (string.isEmpty()) est dj une phrase. Mais on m'impose d'crire if (string.isEmpty() == true), ce qui demande plus de concentration pour le lire.

----------


## Mdinoc

Pour le "Single Entry, Single Exit" (alias "pas de return multiples") je dirais que a dpend des circonstances: Contexte d'utilisation, outils disponibles dans le langage (notamment, prsence ou non de destructeurs ou ramasse-miettes) et prsence de ressources alloues.

Je ne vois aucun problme pour mettre des return  sur la validation des paramtres en dbut de fonction:  ce stade la fonction n'est pas cens avoir allou ou ouvert quoi que ce soit. Ensuite, des fonctions qui ne font aucune allocation, comme une fonction de recherche dans une liste, peuvent tirer parti d'un return ds que l'objet recherch est trouv.

En gros, je dirais que le return au beau milieu d'une fonction est  bannir ds qu'il doit tre accompagn d'un nettoyage:


```

```


 noter que dans certains cas dans des langages comme le C, il peut tre avantageusement remplac par un goto: Si toutes les variables sont correctement initialises lors de leur dclaration, un "goto cleanup" peut rendre une fonction plus lisible qu'un code "boomerang".
Bien sr, en C++ on utilisera des destructeurs  la place.




> Comme rgle casse-pied j'allais justement citer le fait de prciser tout le temps == true ou == false au lieu de ne rien mettre ou juste '!'. Pareil pour les tests de pointeurs, rajouter "!= 0" ou "!= NULL", c'est lourd...


Autant pour les boolens je suis d'accord, autant pour les pointeurs j'ai fini par changer d'avis aprs quelques annes.  prsent j'apprcie les langages o les if n'acceptent que le type boolen (sauf quand il s'agit de faire des tests de flags sur des enums, mais .Net 4.0 3.5 4.0 a rsolu ce problme-l).

----------


## 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 parenthse se situe pile poil align avec le code du dessus et l'autre dev qui affichera le mme code avec une tabulation de 2 au lieu de 4 verra une le code dcal et par consquent beaucoup moins lisible. Alors qu'avec des espaces, dans tous les cas, on l'a mis  un endroit, et sur tous les ordis, a apparat au mme 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 dcris (= une fois sur tab), a dcale de 4 et en plus au lieu d'un caractre tabulation ce sont des espaces !

 ::ccool::

----------


## LooserBoy

> Pourquoi ? Je ne connais pas cette "rgle" mais je l'observe souvent...
> Comme rgle casse-pied j'allais justement citer le fait de prciser tout le temps == true ou == false au lieu de ne rien mettre ou juste '!'. Pareil pour les tests de pointeurs, rajouter "!= 0" ou "!= NULL", c'est lourd...


Selon le langage et/ou le compilateur initialement utilis lors de la mise en place des rgles de codage en entreprise, la syntaxe "If(monBooleen)" nexistait pas forcment.

Mon premier poste de dv avait des rgles de codage (langages C++ puis .Net 1.1) qui dataient de mathusalem, utilisaient la notation hongroise et exigeaient qu'on explicite les tests de boolens avec un ordre dans le test ( "If(true == monBooleen)" ), entre autres,...

Comme a a dj t dit, les rgles de codage sont discutables car tablies dans un contexte particulier. Elles peuvent mme devenir obsoltes mais tre conserves pour des raisons videntes d'homognit du code...

----------


## SurferIX

> Pourquoi ? Je ne connais pas cette "rgle" mais je l'observe souvent...


C'est bien simple : sans vouloir remettre en cause ton exprience, cela vient des dveloppeurs C (et je crois que le problme persiste mme en Php) lorsqu'on fait les comparaisons :



```

```

est un code qui ne gnre pas d'erreur, alors que le dveloppeur voulait comparer. Et ce genre de problme a souvent gnr des heures - inutiles - de dbogague pour arriver  ce code :



```

```

La conclusion pratique : on met les constantes en premier :



```

```

Ainsi, en faisant a, on ne peut pas crire ce code, qui gnre une erreur de compilation :



```

```

 ::aie:: 

Conclusion : tous les dveloppeurs qui veulent imposer cette pratique montrent principalement une chose : ils ont de longues heures de vol et de dboguage derrire eux !  ::mrgreen:: 

Ensuite un autre problme surgit souvent : code classique (mme vu en cole d'ingnieur par un prof  ::cry:: ) :



```

```

Code qu'il faut absolument proscrire tout simplement parce que la valeur de retour peut tre un succs = lecture ok, mais peut renvoyer "0" (= un entier) et donc ce code considre que a n'a pas fonctionn, alors que *si*.

Le code "propre" et "fiable" est :

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



```

```

Mme chose en Php : comparaison ternaire pour tre sr du type :



```

```

----------


## Bluedeep

> C'est bien simple : sans vouloir remettre en cause ton exprience, cela vient des dveloppeurs C (et je crois que le problme persiste mme en Php) lorsqu'on fait les comparaisons :


En C# aussi, mais dans un seul cas, les boolens :



```

```

avec un warning il est vrai.

----------


## Troudhyl

@SurferIX : Merci de l'explication, effectivement a se tient  :;):  Mais bon du coup on perd en lisibilit, je prfre mettre des espaces autour du  == comme a le signe important saute aux yeux.

----------


## BenoitM

> En C# aussi, mais dans un seul cas, les boolens :
> 
> 
> 
> ```
> 
> ```
> 
> avec un warning il est vrai.


bien la preuve qu'il faut crire 


```
if(b) ...
```

et non 

```
if(true == b) ...
```

ou 

```
if(b == true)...
```

----------


## SurferIX

> En C# aussi, mais dans un seul cas, les boolens... avec un warning il est vrai.


Tu as raison : j'ai oubli de prciser 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 dpend des circonstances: Contexte d'utilisation, outils disponibles dans le langage (notamment, prsence ou non de destructeurs ou ramasse-miettes) et prsence de ressources alloues.


Exactement, pour moi le problme c'est quand on tente d'appliquer btement une convention de codage potentiellement bnfique et bien adapte  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  dfinir cette rgle ? sont elles encore dactualits ?).

----------


## rt15

> Ensuite un autre problme surgit souvent : code classique (mme vu en cole d'ingnieur par un prof ) :
> 
> 
> 
> ```
> 
> ```
> 
> Code qu'il faut absolument proscrire tout simplement parce que la valeur de retour peut tre un succs = lecture ok, mais peut renvoyer "0" (= un entier) et donc ce code considre que a n'a pas fonctionn, alors que *si*.
> ...


Heu... C'est de l'humour j'espre. Ou alors c'est pas du C. :8O: 



> S'il russissent intgralement 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 diffrent de 0 tout va bien. Et le pointeur ne sera d'ailleurs probablement jamais ngatif. En 32 bits, un pointeur est gnralement considr 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 :



```

```

Rsultat :
Fichier valide ouvert -12
Echec de l'ouverture d'un fichier invalide
Fichier valide ouvert -12
Fichier invalide ouvert -12

----------


## Bovino

> Quelle est la rgle de codage la plus trange que vous avez t forc de suivre ?


Ne pas avoir le droit de crer de nouvelle base de donne pour des activits diffrentes !  ::cry:: 

Imaginons par exemple que nous ayons cr une base correspondant  des recettes de cuisine, avec les champs "ingrdients", "dure" et "oprations".
On dcide ensuite de crer un planning d'entrainement sportif, du coup, dans ce cas, "ingrdients" correspond  "type d'exercice", "dure"  "lieu" et "oprations"  "quipement". Seulement, comme il manque un champ pour "dure de l'exercice", alors on va utiliser le champ "ingrdients" en sparant la valeur "type d'exercice" et "dure de l'exercice" par un dlimiteur arbitraire...  ::calim2:: 

Tout cela est parfaitement rsum dans cet article...

----------


## Uther

> Ensuite un autre problme surgit souvent : code classique (mme vu en cole d'ingnieur par un prof ) :
> 
> 
> 
> ```
> 
> ```
> 
> Code qu'il faut absolument proscrire tout simplement parce que la valeur de retour peut tre un succs = lecture ok, mais peut renvoyer "0" (= un entier) et donc ce code considre que a n'a pas fonctionn, alors que *si*.
> ...


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 grera 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'intrt de ce genre de chose, alors qu'il suffit de laisser les attributs public?

----------


## Barsy

> bien la preuve qu'il faut crire 
> 
> 
> ```
> if(b) ...
> ```
> 
> et non 
> 
> ...


Enfin, dans tout les cas il faut crire 

```
if (maConstante == maVariable)
```

 et non l'inverse. Peut importe qu'il s'agisse de boolen, d'entiers ou autre. Et trs souvent les dveloppeurs crivent l'inverse.

Aprs, pour ce qui est de prciser  chaque fois "true" ou "false" quand on compare un boolen, chacun est juge, tant qu'il respecte la rgle fixe sur le projet bien videmment.

Sinon, pour rester sur les boolens, voici une rgle qui m'a sembl intressante sur un prcdent projet : Les boolens doivent toujours tre crits pour que la valeur "true" reflte un rsultat positif. Par exemple, un boolen peut s'appeler "isConnected" mais pas "isNotConnected".
Et c'est vrai qu'on tombe souvent sur des boolen ngatifs dans les projets. Aprs, je ne pense pas que ce soit vital comme rgle, mais a peut faciliter la lecture du code je pense.

----------


## Bluedeep

> Les boolens doivent toujours tre crits pour que la valeur "true" reflte un rsultat positif. Par exemple, un boolen peut s'appeler "isConnected" mais pas "isNotConnected".


Donc utiliser IsNotDisconnected c'est pas bon ?  ::aie::

----------


## Troudhyl

> Enfin, dans tout les cas il faut crire 
> 
> ```
> if (maConstante == maVariable)
> ```
> 
>  et non l'inverse. Peut importe qu'il s'agisse de boolen, d'entiers ou autre. Et trs souvent les dveloppeurs crivent l'inverse.


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

----------


## Bluedeep

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


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

----------


## Laurent.B

> Moui, encore faut il avoir le rflexe 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 problme de formater tout un projet aprs coup mais oui, il vaut mieux prvoir cela au dbut.




> L'ide derrire cette rgle 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 prcis, a peut te faire gagner un temps prcieux de recherche. Juste mettre un commentaire NOTHING effectivement c'est lourdingue et surtout a sert  rien...


La premire ide de cette rgle me semblerait plutt de bien montrer que tu as pens  l'alternative (dans certains domaines a peut tre une question vitale ou extrmement importante). NOTHING n'est effectivement pas trs explicite donc personnellement, quand je l'applique, je m'efforce de mettre un commentaire utile.




> Fraichement embauch sur un produit cod par des gnrations 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 rpondu que la seul rgle  suivre tait de ne pas utiliser de convention de codage car "a frustre le dveloppeur et lui fait perdre son temps. Tu dbute et moi j'ai 20 ans d'exprience alors crois moi quand je te dis que a sert  rien !".
> Rsultat, un code illisible mlangeant a peu prs 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 wikipdia sur les indentations du code.


Effectivement, les accolades me paraissent vraiment incongrues places 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 dveloppeuse sur des projets dans sa vie, ou c'est juste purement arbitraire de sa part ?  ::): 




> Pour ma part, et sans hsiter, il y a de cela sept ou huit ans, un projet chez un client o le DBA ne voulait pas de procdure stockes ....


Bon si ce n'est pas ironique, alors il faudra peut-tre un jour que tu te penches srieusement sur le sujet et peut-tre comprendras-tu les raisons de cette phobie des procdures stockes. Il y en a plusieurs...




> Par exemple : string.isEmpty(). Donc if (string.isEmpty()) est dj 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 droger  la rgle d'indiquer le boolen que l'on teste mais dans ce cas prcis, a me semble effectivement trs 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 ?


```

```

C'est loin d'tre clair lorsque l'on rencontre cette notation la premire fois mais en ce qui me concerne, je considre que c'est une bonne pratique. C'est encore plus vident lorsque l'on a deux boucles imbriques et que l'on veut pourvoir en sortir d'un seul coup.
Quand j'utilise celle-ci, certaines personnes parviennent  comprendre son intrt quand je leur explique et d'autres s'en offusquent (btement)... 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'intrt de ce genre de chose, alors qu'il suffit de laisser les attributs public?


Oui, a parat moyen au premier abord mais la raison est que cela permet de la gnricit dans les traitements de ce genre d'objets, notamment par rflexion ou mme 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 drive.
> 
> Je suis habitu au K&R et que je vois du Whitesmiths, j'ai un peu de mal. 
> Article wikipdia sur les indentations du code.


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

C'est une mode apparue au dbut des annes 80, lie historiquement aux contraintes de l'diteur des systmes Unix de l'poque, qui a eu le bon gout de disparaitre au dbut des 90' et que j'ai vu avec stupeur rapparaitre principalement chez les codeurs Javascript  la fin des 90' alors que la majorit des dev. C++ et Java ( et C# aprs) utilisaient le Allman (que pour ma part j'impose sur tous les dveloppement - le refactoring d'aspect de VS permettant de ramener le code des gars  la raison  ::mouarf:: ).

----------


## NevilClavain

> Sur certains outils tels qu'Eclipse, cela ne pose aucun problme de formater tout un projet aprs coup mais oui, il vaut mieux prvoir cela au dbut.


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

----------


## Loceka

Les choix du type de parenthsage sont aussi trollifre que les choix d'indentation (voire plus), mais personnellement je prfre le parenthsage  la "Java" (proche du K&R apparement).
Le parenthsage 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) :



```

```

vs



```

```

----------


## Bluedeep

> Les choix du type de parenthsage sont aussi trollifre que les choix d'indentation (voire plus), mais personnellement je prfre le parenthsage  la "Java" (proche du K&R apparement).
> Le parenthsage 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 trollifre car pour ma part j'ai l'opinion exactement inverse sur la lisibilit  ::mrgreen:: 

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



```
int aVariable; string anotherVariable; double etcVariable;
```

----------


## Glob

> Oui, a parat moyen au premier abord mais la raison est que cela permet de la gnricit dans les traitements de ce genre d'objets, notamment par rflexion ou mme 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 rflexion fonctionne tout aussi bien sur des champs public que sur des mthodes. De plus, mme si la gnration des accessors peut tre facilite dans des IDE modernes comme Eclipse, a reste lourd  la maintenance pour une plus-value qui reste chimrique.

A+

----------


## Laurent.B

> Le parenthsage 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 condenss, que j'appelle en gnral des "pts"  :;): , je prfre donc de loin le code ar 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 mthode ou fonction, tout dpend de ce qu'elle contient et de la manire dont c'est formalis. Le code condens avait bien plus de lgitimit lorsque les crans avaient encore des dimensions trs restreintes. Quoi qu'il en soit et en ce qui me concerne, je pense qu'effectivement ce genre de dbat est plutt vain, tout simplement parce que *tout le monde n'a pas la mme faon de percevoir et analyser un code*.

Donc, toujours selon moi, mettre une accolade en fin de ligne  ct plutt absurde mais avec le temps je m'en suis accommod. Pour pallier cela, j'ajoute systmatiquement une ligne vide aprs 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'embte pas, signe que ce n'est pas tant l'accolade le problme mais bien les textes trop condenss.

Ensuite, je suis tout  fait d'accord avec le fait que si une mthode est trop longue, cela pose des problmes pour analyser rapidement l'algorithme de celle-ci. C'est pourquoi, au lieu d'incriminer les accolades ouvrantes en dbut 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 relgu dans des mthodes explicites de par leur nom.
Voil, donc normalement en dfinissant des rgles qui imposent un nombre de lignes relativement restreint par mthode/fonction, on peut se permettre d'avoir un code ar, qui selon moi demeure beaucoup plus lisible.

Bref, on n'arrivera jamais  satisfaire tout le monde, donc on aura sans doute fait un progrs, lorsque les diteurs de code permettront de *prsenter efficacement le code selon les gots du dveloppeur, sans impact sur les fichiers physiques* et qu'il soit ensuite trs facile de basculer d'un type de prsentation  un autre.

Un autre progrs me semblerait intressant, ce serait de *guider en permanence la saisie du code*, de manire  ce que le dveloppeur n'ait pas  s'en proccuper (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 pousse. Par exemple, en ayant des *marges verticales  intervalle adaptatif* selon le contexte, comme faire une sparation plus prononce entre la signature d'une mthode et le contenu de celle-ci (personnellement, je ne mettrais plus de ligne vide).
Tout ceci a un cot c'est sr mais je verrais cela comme une bonne chose pour couper court  ce genre de dbat, 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 diffrence n'est au final pas vraiment importante, mais en plus ils peuvent se mlanger sans que a pose vraiment de problme de lisibilit tant que l'indentation reste propre.

Personnellement jutilise 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


```

```

o il est utile pour bien sparer la condition du corps du bloc.




> La rflexion fonctionne tout aussi bien sur des champs public que sur des mthodes. De plus, mme si la gnration des accessors peut tre facilite dans des IDE modernes comme Eclipse, a reste lourd  la maintenance pour une plus-value qui reste chimrique.


Le problme des getter/setter n'a rien a voir avec l'introspection, ou la lisibilit, c'est mme plutt une plaie  ce niveau.

Ils sont l car ils servent d'interface aux javabean. Un bean se doit d'offrir une encapsulation forte. Grce au getter/setter les beans ont un contrle complet sur leur proprits qu'il peuvent restreindre (read/write only), vrifier, gnrer  la voler, ... etc 
Certes c'est lourd de faire un getter/setter quand on ne fait qu'une opration d'criture/lecture de variable (Sun/Oracle devrait vraiment se pencher sur une syntaxe spciale pour les proprits). Mais a permet de pouvoir faire voluer l'opration dans le futur pour par exemple ajouter un contrle sur un setter, ce qui n'est pas possible avec un accs direct  un champ.

----------


## ManusDei

Je me dis que vous aurez peut-tre une solution pour un cas rencontr dans un stage o j'ai rien trouv d'autre qu'un GOTO.



```

```

Le if est au milieu du while, si vrai on part sur le code aprs le label.
Si on sort du while normalement, on excute la section c avant d'excuter la section d.

----------


## LooserBoy

> Je me dis que vous aurez peut-tre une solution pour un cas rencontr dans un stage o j'ai rien trouv d'autre qu'un GOTO.
> 
> 
> 
> ```
> 
> ```


Comme a?


```

```

----------


## Bluedeep

Ouais .... un flag de plus dans le corps de mthode n'aurait pas chang la face du monde, je ne vois pas  trop la ncessit du goto en l'espce.
(surtout avec un branchement depuis un point unique).

----------


## shadowmoon

> Comme a?
> 
> 
> ```
> 
> ```


Non ce n'est pas quivalent, car, avec cette version du code 

1) on ne sort pas de la boucle while au moment du if
2) les sections b et c sont quand mme excutes au lieu dtre ignores, "sautes"

Je peux me tromper, mais si j'ai bien compris, je pense qu'il faudrait plutt faire comme a



```

```

----------


## ManusDei

> 1) on ne sort pas de la boucle while au moment du if
> 2) les sections b et c sont quand mme excutes au lieu dtre ignores, "sautes"


Et la section d du code n'est pas excute aprs la section c si on sort du while normalement (sans passer par le GOTO).
Il y avait des variables communes dans les 4 sections, donc impossible de changer l'ordre dans lequel elles sont excutes.

@shadowmoon : Oui, en rajoutant une section d du code aprs la section c dans le if(not machin)

----------


## BenoitM

euh faut remplacer le goto par un break sinon vous n'aurez pas le mme comportement  non?

----------


## Troudhyl

```

```

Version avec le break :


```

```

(si la section a ne peut pas changer un_test)

----------


## rt15

> Je peux me tromper, mais si j'ai bien compris, je pense qu'il faudrait plutt faire comme a
> 
> 
> 
> ```
> 
> ```


Il manque aussi le break, et le code "section d" est dupliqu, ce qui est aussi souvent considr comme une trs mauvaise pratique car a gne le refactoring et la maintenance du code.

Il faut qu'on retourne tous  l'cole ! ::oops:: 

Enime proposition :



```

```

----------


## BenoitM

La solution de Troudhyl me semble correct
(j'avais la flamme d'crire le pseudo code  ::oops:: )

----------


## Lung

> (j'avais la fl*a*mme d'crire le pseudo code )


Te brle pas !

 ::mouarf::

----------


## Glob

> Le problme des getter/setter n'a rien a voir avec l'introspection, ou la lisibilit, c'est mme plutt une plaie  ce niveau.
> 
> Ils sont l car ils servent d'interface aux javabean. Un bean se doit d'offrir une encapsulation forte. Grce au getter/setter les beans ont un contrle complet sur leur proprits qu'il peuvent restreindre (read/write only), vrifier, gnrer  la voler, ... etc 
> Certes c'est lourd de faire un getter/setter quand on ne fait qu'une opration d'criture/lecture de variable (Sun/Oracle devrait vraiment se pencher sur une syntaxe spciale pour les proprits). Mais a permet de pouvoir faire voluer l'opration dans le futur pour par exemple ajouter un contrle sur un setter, ce qui n'est pas possible avec un accs direct  un champ.


Je parle de DTO, pas de javabeans. De simples containers dont l'quivalent en C serait le struct. Je ne vois toujours pas le moindre petit dbut de pertinence   y mettre des accessors.
cf Java Coding Conventions 10.1

----------


## Uther

Pour les DTO en effet a ne sert  rien. 

C'est un exemple typique de bonne pratique dans un cas particulier (objet offrant une forte encapsulation) qui a t enseigne par certains comme un dogme absolu, gnralement par fainantise d'expliquer le pourquoi du comment. 
Du coup des gens veulent les tendre  des domaines ou elles sont contreproductives.

----------


## Deaf

> Je parle de DTO, pas de javabeans. De simples containers dont l'quivalent en C serait le struct. Je ne vois toujours pas le moindre petit dbut de pertinence   y mettre des accessors.
> cf Java Coding Conventions 10.1


On peut imaginer une classe qui tend le DTO pour y ajouter une logique mtier, tout en restant utilisable comme un DTO par la plupart des autres classes.
Dans ce cas, si tu utilise directement les champs, tu peux zapper la logique mtier. Pour moi, les getters/setters permettent de laisser ce genre de portes ouvertes, mme si on en a pas besoin, a priori.

----------


## bilbonec

La pire rgle de codage est encore de n'en imposer aucune. 

C'est ce qui m'arrive dans ma mission actuelle o, aprs avoir dvelopp seul pendant quelques mois, un autre dveloppeur se met au freestyle : diffrentes indentations par fichiers, diffrentes faons de prsenter les {}, nommage compltement diffrent des mthodes / variables, etc. 

Et l, on se dit que dans les normes de codage ... il y a du bon !

----------


## Bluedeep

> La pire rgle de codage est encore de n'en imposer aucune. 
> 
> C'est ce qui m'arrive dans ma mission actuelle o, aprs avoir dvelopp seul pendant quelques mois, un autre dveloppeur se met au freestyle : diffrentes indentations par fichiers, diffrentes faons de prsenter les {}, nommage compltement diffrent des mthodes / variables, etc. !


Dans la mesure o tu es l depuis quelques mois, ce n'est quand mme pas difficile de lui imposer tes normes de codage. En bonne logique ta hirarchie devrait te soutenir (sauf su tu n'insistes pas, bien sur).

----------


## Rayek

> Et l, on se dit que dans les normes de codage ... il y a du bon !


Enfin bon, il y a des limites, dans la boite o je suis on a pass un fois 2 heures  discuter pour savoir o l'on met le *begin* dans un *case* ::aie::  (pour ma part j'tais plutt en mode on s'en fou tant que a reste lisible)

et a pinaillait entre



```

```


et



```

```

----------


## Freem

> 3 fois le mme programme, qui copie le contenu d'un fichier vers un autre fichier :
> 
> Sans goto, traitement normal en premier :
> 
> 
> ```
> 
> ```
> 
> ...



Refaisons les mmes codes proprement:

Sans goto, traitement normal en premier :


```

```


A noter qu'en fait, on peut amliorer le truc encore...
Par exemple, enlever des if:


```

```

L'astuce: les && permettent d'agir comme un if en fait. Astuce apprise grce au shell: si la premire condition est fausse, alors l'ensemble de la condition sera fausse, donc le compilateur intelligent ne prendra pas la peine de vrifier les autres conditions  ::): 




> Sans goto, traitement d'erreur en premier :


Ouai mais en fait, flemme de refaire la mme astuce que prcdemment.

Rsultat final: 19 lignes de gagnes (28.4% de taille de code en moins tout de mme, presque 1/3!), moins d'indentations, pas de goto et un code globalement plus clair.
Problme: cot d'appel  la fonction printError(int, char*)  chaque fois, qui peut tre rsolu via des macros, d'ailleurs. Ou le mot-cl inline en C++, mais j'ai tenu  respecter le langage C au maximum de mes souvenirs.

On peut amliorer encore plus le truc, en utilisant:
_ des constantes pour les messages d'erreur
_ une macro pour remplacer le if, qui prenne en paramtre le message d'erreur.





```

```



```

```

Sinon:


```

```

Les solutions, s'pas ce qui manque.

Ah oui, je viens de me rappeler une horreur, vue par un prof:



```

```

Arrgg!g!!!

----------


## Loceka

> L'astuce: les && permettent d'agir comme un if en fait. Astuce apprise grce au shell: si la premire condition est fausse, alors l'ensemble de la condition sera fausse, donc le compilateur intelligent ne prendra pas la peine de vrifier les autres conditions


C'est effectivement le principe de l'valuation paresseuse. Par contre, tant donn que c'est une optimisation du langage, tous les langages ne la pratiquent pas.

Par exemple en shell (/bin/sh), il me semble bien que la commande *test* (ou son quivalent *[ ... ]*) ne pratique pas l'valuation paresseuse (c'est d'ailleurs ce que confirme ce site).

----------


## Aurlien LEQUOY

> Ne pas avoir le droit de crer de nouvelle base de donne pour des activits diffrentes ! 
> 
> Imaginons par exemple que nous ayons cr une base correspondant  des recettes de cuisine, avec les champs "ingrdients", "dure" et "oprations".
> On dcide ensuite de crer un planning d'entrainement sportif, du coup, dans ce cas, "ingrdients" correspond  "type d'exercice", "dure"  "lieu" et "oprations"  "quipement". Seulement, comme il manque un champ pour "dure de l'exercice", alors on va utiliser le champ "ingrdients" en sparant la valeur "type d'exercice" et "dure de l'exercice" par un dlimiteur arbitraire... 
> 
> Tout cela est parfaitement rsum dans cet article...



tu travaillais chez doctissimo ? :p

----------


## Aurlien LEQUOY

> 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 grera pas les erreurs.



Tout a fait d'accords que ce soit en C ou en PHP

----------


## Joker-eph

> Parce qu'il est certains cas o il faut que l'indentation se fasse au niveau d'un caractre de la ligne du dessus. Par exemple a :
> 
> 
> 
> ```
> 
> ```
> 
> Ici la deuxime ligne doit tre aligns sur la parenthse ouvrante de la premire ligne. C'est impossible  faire si on utilise des tabulations.


Mouais... ici il suffit de mettre autant de tabulations que pour le "if" et de ne mettre des espaces que pour indenter relativement au if.




> Beaucoup d'IDE remplacent par dfaut les tabulations par des espaces.


Mauvais IDE, changer d'IDE  ::aie::

----------


## Klaim

Sacree thread. Ya des trucs qui m'ont bien fait rire (le coup du ; a la ligne 80 en particulier).

Concernant les retours multiples, voici ma philosophie concernant les breaks et continue, qui est liee (avec laquelle beaucoup de devs semblent etre d'accord: http://programmers.stackexchange.com...es/58253#58253)




> When used at the start of a block, as first checks made, they act like preconditions, so it's good.
> 
> When used in the middle of the block, with some code around, they act like hidden traps, so it's bad.


Pour moi c'est pareil pour les retours en milieu de fonction. En soit je trouve que c'est une tres mauvaise idee de les interdire parceque ca empeche tout ce qui est tests de preconditions.

Les fonctions, lorsquelles sont lues, le sont de haut en bas. Il est facile de reperer une return si il est proche du debut de la fonction et associe a un if et que le bloc du if est court.
C'est encore plus facile a lire si ca se repete parcequ'il y a plusieurs preconditions pour arriver au traitement final (je ne parle pas d'erreur ou d'assertions ici, c'est plus comme le pattern pipeline).

En revanche des que le return est planque au milieu d'un bout de code, ca peut etre tellement surprenant qu'en le survolant on ne le voit pas.

Donc en gros, c'est un peu se tirer une balle dans le pied (no pun intened) de s'interdire les retours multiples parceque ca encourage un style en arbre de condition qui est tres difficile a lire passe le 2nd niveau de profondeur. C'est un peu comme s'assurer qu'on ne pourra jamais avoir de code structure de maniere lisible.

Mettre les retours de maniere evidente, lisible et correcte est beacoup plus facile quand on a pas des barriere inutiles.

----------


## Bluedeep

> Mauvais IDE, changer d'IDE


Le paramtrer correctement est une solution moins radicale et plus facile  matre en oeuvre.

----------


## el_slapper

> Le paramtrer correctement est une solution moins radicale et plus facile  matre en oeuvre.


J'avais interprt a comme une caricature de Berthold Brecht : Puisque le peuple vote contre le Gouvernement, il faut dissoudre le peuple!

----------


## CinePhil

> J'avais interprt a comme une caricature de Berthold Brecht : Puisque le peuple vote contre le Gouvernement, il faut dissoudre le peuple!


C'est ce que le gouvernement fait actuellement : Il incite les plus aiss  se barrer du pays pour ne garder que la population plus encline  approuver ses dcisions.  ::aie::

----------


## Bluedeep

> C'est ce que le gouvernement fait actuellement : Il incite les plus aiss  se barrer du pays pour ne garder que la population plus encline  approuver ses dcisions.


En ralit, il voudrait mme aller plus loin et perfectionner le systme en bricolant le corps lectroral.

----------


## pseudocode

> [B][SIZE="4"]voici quelques rgles drles qui y sont recenses : l'interdiction dutiliser des retours multiples


Et donc l'obligation de tout encapsuler dans des if/then/else... et donc d'indenter tout le code qui suit.  ::calim2:: 




> lobligation de faire prcder les noms des tables de la base de donnes des caractres  tbl


Ce qu'il y a de bien avec le typage statique, c'est que c'est statique. Gnralement le type est prcis avant le nom de la variable... 
Ca ne sert a rien de le repter dans le nom.  ::P: 



```

```





> limposition dun nombre despaces pour lindentation ou encore lutilisation de linversion de lindentation.


astyle est votre ami.  :;): 





> Quelles rgles de codage tranges avez-vous d suivre ?


En cas de modif/correction, garder une copie de l'ancienne fonction entre commentaire. Une sorte de versionning intgr au code.



```

```

----------


## Klaim

> En cas de modif/correction, garder une copie de l'ancienne fonction entre commentaire. Une sorte de versionning intgr au code.
> 
> 
> 
> ```
> 
> ```



Le code etait it finalement mis dans un control de source, histoire d'ajouter un peu d'ironie?  ::aie::

----------


## tio

En PHP, dans une page, je dois rcuprer la liste des voitures pour les afficher en tableau.
J'ai une classe Voiture.
Je fais donc une mthode statique Voiture::getVoitures() qui fait une requte et me renvoie un tableau de Voiture.

Le responsable regarde mon code et me demande ce que veut dire ::
Je lui explique que c'est une mthode statique, il me rpond que a n'existe pas en PHP (on est en PHP5.3 ...), mais uniquement en Java voyons.
Il m'explique la mthode normale :
$maVoiture = new Voiture();
$tabVoitures = $mavoiture->RecupListVoiture();
qui renvoie un tableau de tableaux associatifs champ=>valeur
Apprciez aussi le franglais...

----------


## clampin

Moi j'ai eu un programme ou l'on devait nommer toutes les fonction comme suit, le premier mot en minuscule et deuxime mot, la premire lettre du second mot en majuscule et le reste en minuscule.... 

par exemple une fonction qui ouvre un fichier... 



```

```

----------


## Barsy

> Moi j'ai eu un programme ou l'on devait nommer toutes les fonction comme suit, le premier mot en minuscule et deuxime mot, la premire lettre du second mot en majuscule et le reste en minuscule.... 
> 
> par exemple une fonction qui ouvre un fichier... 
> 
> 
> 
> ```
> 
> ```


Tout ce qu'il y a de plus normal quoi...  ::aie::

----------


## CinePhil

> Moi j'ai eu un programme ou l'on devait nommer toutes les fonction comme suit, le premier mot en minuscule et deuxime mot, la premire lettre du second mot en majuscule et le reste en minuscule.... 
> 
> par exemple une fonction qui ouvre un fichier... 
> 
> 
> 
> ```
> 
> ```


Euh... c'est trs frquent a !
Je crois mme me souvenir que c'est un standard dans certains frameworks tels que Zend Framework ou Symfony ou JBoss Seam.
Ou bien une rgle du mme genre qui permet au framework de dcomposer le nom et de savoir comment le traiter si j'ai bien compris.

----------


## Bluedeep

> Moi j'ai eu un programme ou l'on devait nommer toutes les fonction comme suit, le premier mot en minuscule et deuxime mot, la premire lettre du second mot en majuscule et le reste en minuscule....


Cette convention trs habituelle s'appelle la lowerCamelCase; elle est trs frquente et ne saurait certainement pas rentrer dans la liste des rgles "bizarres".

----------


## Klaim

C'est aussi la version du camelCase standard de Java. Ce genre de regle n'influe pas des masses sur la sanite de celui qui lis, donc c'est pas vraiment un probleme.

Moi j'utilise beaucoup un mix de CamelCase pour les types, sous_lignes pour les fonctions et les noms de variables, et CamelCase_AvecUnderscore dans certains cas particuliers. 

Ca peut aliener certains, mais l'experience montre que mieu vaut savoir s'adapter a ce genre de regle qui peuvent etre differentes selon les projets.

----------


## LooserBoy

On vient de me mettre sur une volution de notre solution logicielle.
En mettant le nez dans le code, je me retrouve  lire du franglais particulirement approximatif posant des problmes de comprhension de l'utilit/fonction du mcanisme mis en oeuvre et mme parfois avec de la logique inverse.

Exemple:


```

```

Tout a pour dire que des donnes ont bien t modifies entre l'ouverture et la demande de fermeture de l'cran...  ::aie::

----------


## andry.aime

En parlant de camelCase, je me rappelle un dveloppeur qui nomme les variables et fonctions en respectant le camelCase mais qui est presque une phrase complte.

----------


## pseudocode

> En parlant de camelCase, je me rappelle un dveloppeur qui nomme les variables et fonctions en respectant le camelCase mais qui est presque une phrase complte.


Ah, j'ai connu a aussi...

JeCroisQueCeNomDeFonctionEstTrop(long aLire)

----------


## Caravane

Je trouve la limitation du nombre de lignes de code dans une mthode mal pens
parce qu'elle oblige le dveloppeur  clater tout un algorithme pour respecter la rgle !!!

----------


## rt15

clater un long algo est parfois une trs bonne chose. Cela permet souvent de diviser la complexit en petit bouts simples. Le code rsultant est souvent bien plus lisible.

Mais bon tout dpend de l'algo...

----------


## Klaim

> Je trouve la limitation du nombre de lignes de code dans une mthode mal pens
> parce qu'elle oblige le dveloppeur  clater tout un algorithme pour respecter la rgle !!!


C'est typique de confondre un effet de bord avec une source d'information.
Du code bien organise est souvent court dans les fonctions, parcequ'elles ne font qu'une chose a la fois, et c'est une generalite (il y a des fonctions qui doivent etre longues par design), donc on obtiens souvent des fonctions avec peu de lignes, qui tiennent dans un ecran.

Partir du principe que toutes les fonctions DOIVENT avoir un maximum d'un nombre de ligne est du coup pas tres logique puisque c'est pas parcequ'on a peu de ligne qu'on a une bonne organisation de code, c'est l'inverse.


(Je dis ca, j'ai pas une seule fonction longue dans mon code actuel d'un tres gros projet...)

----------


## rt15

> clater un long algo est parfois une trs bonne chose. Cela permet souvent de diviser la complexit en petit bouts simples. Le code rsultant est souvent bien plus lisible.
> 
> Mais bon tout dpend de l'algo...




```

```



```

```

----------


## CinePhil

Si les procdures manger et faire la sieste sont utilises plusieurs fois dans le logiciel, OK, a vaut le coup de dcouper. Sinon, un simple commentaire suffit pour rendre clair le programme sans avoir besoin d'aller chercher ventuellement dans quel fichier perdu est dfinie cette foutue fonction !


```

```

----------


## Barsy

> Si les procdures manger et faire la sieste sont utilises plusieurs fois dans le logiciel, OK, a vaut le coup de dcouper. Sinon, un simple commentaire suffit pour rendre clair le programme sans avoir besoin d'aller chercher ventuellement dans quel fichier perdu est dfinie cette foutue fonction !


Sauf que quand ton code commence  ressembler  



```

```

Je pense qu'il est ncessaire de le dcouper en plusieurs mthode, mme si celles-ci ne sont pas utilises plusieurs fois.

----------


## minnesota

quand le chef de projet fan de maitre Yoda dit  barsy 
de pseudo-coder *les yeux ferms sur le canap la sieste tu feras*, 

a donne 




> ```
> 
> ```


  ::aie:: 

En plus l vous autres, vos codes sont faux, avant d'autoriser  manger, il faut tester si l'individu n'est pas un Mogwa et s'il n'est pas minuit pass, mais encore, appeler l'horloge parlante pour tre sur qu'il n'est pas minuit pass  ::mouarf::

----------


## Barsy

> quand le chef de projet fan de maitre Yoda dit  barsy 
> de pseudo-coder *les yeux ferms sur le canap la sieste tu feras*, 
> 
> a donne 
> 
> 
> 
> En plus l vous autres, vos codes sont faux, avant d'autoriser  manger, il faut tester si l'individu n'est pas un Mogwa et s'il n'est pas minuit pass, mais encore, appeler l'horloge parlante pour tre sur qu'il n'est pas minuit pass


Je ne comprends pas ta remarque. Faire la sieste ncessite bien d'aller sur le canap et de fermer les yeux non ? Si tu rapproches un peu plus tes yeux de l'cran, tu remarqueras qu'il n'y a pas de "..." en dessous de "faire la sieste".  ::P:

----------


## ManusDei

> En plus l vous autres, vos codes sont faux, avant d'autoriser  manger, il faut tester si l'individu n'est pas un Mogwa et s'il n'est pas minuit pass, mais encore, appeler l'horloge parlante pour tre sur qu'il n'est pas minuit pass


On bosse pour le mme client, je crois  ::mouarf::

----------


## el_slapper

> (.../...)(Je dis ca, j'ai pas une seule fonction longue dans mon code actuel d'un tres gros projet...)


J'en ai une seule dans un projet de taille moyenne. Mais Barsy a raison : "a dpend". Je dirais que tant qu'on peut dcouper sans nuire  la lisibilit, il faut dcouper. Quand a devient de l'encapsulage de mouches, il faut arrter. Mon exemple classique(dont je suis coupable) :



```

```

Oui j'ai des procdures courtes. Et oui c'est une erreur. C'est rarement une erreur(la plupart du temps a simplifie la lecture), mais dans ce cas prcis, c'est vraiment une erreur(mme si j'ai un poil simplifi TraitementCase, et volontairement omis les dclaration de variables).

----------


## LooserBoy

> Quand a devient de *l'encapsulage de mouches*, il faut arrter.


Ouf, j'ai mal lu...  ::aie:: 

 ::dehors::

----------


## el_slapper

> Ouf, j'ai mal lu...


la formule tait volontairement glissante.....  ::oops::

----------


## raimbow

> Si les procdures manger et faire la sieste sont utilises plusieurs fois dans le logiciel, OK, a vaut le coup de dcouper. Sinon, un simple commentaire suffit pour rendre clair le programme sans avoir besoin d'aller chercher ventuellement dans quel fichier perdu est dfinie cette foutue fonction !


Le problme quand tu bosse sur des vrai programmes, c'est qu'ils sont amen  volu d'une faon que tu ne peux pas prvoir (en fonction des besoins future du client) donc c'est impossible (la plupart de temps) de dire avec certitude si une fonction sera ou non utilis plusieurs fois.

Et mme pour la partie non-mtier qui ne dpend pas de ton client, ton code voluera si il est utilis, donc y'a des chances qu'une fonction soit rutilis  un autre endroit de ton code mme si au dpart a ne devait pas tre le cas.


Pour l'argument du "Si on dcoupe trop c'est chiant de retrouv o sont les fonctions qui sont appel" je te conseil d'utiliser un vrai IDE. Sous eclipse par exemple CTRL + clic sur une mthode m'ouvre le bon fichier  l'endroit o est dfinis la fonction. 

Dcouper en fonction courte son programme permet galement d'optimiser plus facilement son code en limitant les risques de tout casser. Par exemple sur une grande fonction, une variable qu'on utilise au dbut peut aussi tre utilis  un autre endroit, parfois un peu obscure (genre l'index d'un tableau), et il faut parcourir tout le code pour vrifier que ce n'est pas le cas. Sur une fonction de 5/10 lignes on le voit tout de suite. 

C'est aussi plus facile  dbugger souvent. Tu check les entrs sorties des fonctions et tu vois o a merde. Une fois que t'as trouv la fonction qui pose problme t'as au max 15 lignes  analyser. Si c'est sur une fonction de 250 Lignes, tu va encore passer un bon moment  trouver les lignes qui posent problmes avant de te pencher rellement sur le problme en lui mme. 

Pareil pour les audits de performances, tu fais des bench sur chaque fonction et tu vois directement lesquelles ils faut optimiser, c'est bien plus simple !

----------


## minnesota

> Je ne comprends pas ta remarque. Faire la sieste ncessite bien d'aller sur le canap et de fermer les yeux non ? Si tu rapproches un peu plus tes yeux de l'cran, tu remarqueras qu'il n'y a pas de "..." en dessous de "faire la sieste".



Oui j'avais vu aprs coup, juste avant de poster  ::aie::  mais j'avais pas envie d'diter, et puis de toute faon c'est faut, parce que Gandalf  y dort les yeux ouverts  ::P:  hein ManusDei  ::mouarf::

----------


## leminipouce

> Je confirme que les merges sont ingrables sans ce genre de cas.


Il suffit de configurer ton outil pour qu'il ne prenne pas en compte les diffrences d'espaces dans les merges !

Pour moi le vrai problme c'est d'avoir des rgles htrognes. Quand je regarde du code, je dteste avoir  m'adapter au rgles de formatage de chacun des dveloppeurs. Ainsi, si je passe d'une classe  une autre, voir d'une mthode  une autre et que les rgles diffrent totalement, a rend le code bien plus obscur  mon got, bien moins facile  lire.

A titre de comparaison, avez-vous dj vu un livre, ou la police serait diffrente d'une page  l'autre, ou la mise en page varierait d'un chapitre ou paragraphe au suivant. C'est fatiguant  lire. Pour moi, il en va de mme pour le code : on doit pouvoir le lire comme si un seul dveloppeur l'avait crit.

----------


## Bluedeep

> Pour moi le vrai problme c'est d'avoir des rgles htrognes. Quand je regarde du code, je dteste avoir  m'adapter au rgles de formatage de chacun des dveloppeurs. Ainsi, si je passe d'une classe  une autre, voir d'une mthode  une autre et que les rgles diffrent totalement, a rend le code bien plus obscur  mon got, bien moins facile  lire.


Ca c'est surtout la marque d'un CP tech ou d'un "dev leader" qui fait pas son boulot.

----------


## Barsy

> Ca c'est surtout la marque d'un CP tech ou d'un "dev leader" qui fait pas son boulot.


Quand il y en a un...  ::roll::

----------


## andry.aime

> Il suffit de configurer ton outil pour qu'il ne prenne pas en compte les diffrences d'espaces dans les merges !
> 
> Pour moi le vrai problme c'est d'avoir des rgles htrognes. Quand je regarde du code, je dteste avoir  m'adapter au rgles de formatage de chacun des dveloppeurs. Ainsi, si je passe d'une classe  une autre, voir d'une mthode  une autre et que les rgles diffrent totalement, a rend le code bien plus obscur  mon got, bien moins facile  lire.


Nous on travaille sur Eclipse et on cre un Template pour le Code Style que l'on partage  tous les dveloppeurs pour viter ce genre de problme. Un simple "Clean up" permet de formater tous le projet  ::P: .

----------


## pmithrandir

> Nous on travaille sur Eclipse et on cre un Template pour le Code Style que l'on partage  tous les dveloppeurs pour viter ce genre de problme. Un simple "Clean up" permet de formater tous le projet .


En se dbrouillant bien, on peut mme le mettre en rgle de pre commit sur SVN pour viter de polluer le rfrentiel avec des contenus non formats.

----------


## leminipouce

> La rgle la plus trange ?
> 
> Pour ma part, et sans hsiter, il y a de cela sept ou huit ans, un projet chez un client o le DBA ne voulait pas de procdure stockes ....


Un visionnaire ?  :;):

----------


## leminipouce

> Nous on travaille sur Eclipse et on cre un Template pour le Code Style que l'on partage  tous les dveloppeurs pour viter ce genre de problme. Un simple "Clean up" permet de formater tous le projet .


Quand j'tais sous Eclipse, je maintenais galement ce genre de template. Avec en prime le partage de la conf. de sauvegarde qui formattait automatiquement le code. Comme a, impossible (_ moins d'aller changer le template mais l, il faut vraiment avoir envie de faire ch***_) de commiter sans avoir au pralable (_automatiquement_) format le code.

Et quand tu fais un merge, ou un simple diff avec ton VCS, c'est du bonheur. Tu te prends pas la tte et tu vois directement ce qui a t modifi et seulement a !




> En se dbrouillant bien, on peut mme le mettre en rgle de pre commit sur SVN pour viter de polluer le rfrentiel avec des contenus non formats.


Comment ? Je l'ai toujours fait au niveau des IDE, avec l'norme inconvnient que ds que tu as diffrents IDE, ils n'ont pas les mmes rgles de formatage --j'entends par l qu'on peut pas forcment les configurer rigoureusement pareil (_et de suite, a devient chiant !_) J'avoue que j'aimerais bien l'automatiser sur un commit (git ou SVN), mais je ne vois pas comment !

----------


## pseudocode

> Comment ? Je l'ai toujours fait au niveau des IDE, avec l'norme inconvnient que ds que tu as diffrents IDE, ils n'ont pas les mmes rgles de formatage --j'entends par l qu'on peut pas forcment les configurer rigoureusement pareil (_et de suite, a devient chiant !_) J'avoue que j'aimerais bien l'automatiser sur un commit (git ou SVN), mais je ne vois pas comment !


Pour SVN, il suffit de crer un script "hooks\post-commit.bat" qui appelle le JavaCodeFormatter de Eclipse.

----------


## SurferIX

> Comment ? Je l'ai toujours fait au niveau des IDE, avec l'norme inconvnient que ds que tu as diffrents IDE, ils n'ont pas les mmes rgles de formatage --j'entends par l qu'on peut pas forcment les configurer rigoureusement pareil


Sous vim j'ai fait des copier coller de mon rpertoire ".vim" et mon ".vimrc" a a toujours fonctionn sur tous les ordinateurs sur lesquels je les ai mis (toutes les distros + PC diffrents). C'est un peu du troll mais pas trop, parce que c'est une info  savoir : la copie de la config de vim fonctionne de manire transparente partout (avec, justement, les codes snippets, l'auto compltion les auto formatage (je tape date+TAB et hop le mot "date" est remplac par la date au format JJ/MM/AAAA) etc.).

----------


## Lynix

Les pires rgles sont celles que je subis en ce moment:

Pour des programmes C
-Pas de else if
-Pas de goto (Je rappelle que a peut tre utile pour la gestion d'erreur en C)
-Un seul return par fonction
-Pas de break pour sortir des boucles (Donc oui il faut une variable teste  chaque itration pour dcider de si on arrte la boucle).
-Pas de int, que des short

Le tout en mme temps  ::mrgreen:: 

Je deviens fou.

----------


## el_slapper

> Pour des programmes C
> -Pas de else if


est-ce qu'on peut faire un switch sur les boolens en C? Si on ne peut pas(en C# ou java, on ne peut pas, en cobol ou VBA on peut), alors c'est effectivement catastrophique. Sinon, c'est juste une question de style.




> -Pas de goto (Je rappelle que a peut tre utile pour la gestion d'erreur en C)


l'eternel dbat : mis dans de mauvaises mains, le goto a des consquences nuclaires. Il est parfois utile, mais avec toujours un risque lev. une interdiction comprhensible, bien que parfois lourdingue.

En Cobol, j'ai vu une variante de cette rgle : le seul goto autoris tait le "GO TO FIN-PARAGRAPHE", justement pour la gestion d'erreur(les grands esprits se rencontrent).




> -Un seul return par fonction


Pas de scandale  mon sens l-dessus. Lors des maintenances, a permet d'viter certains raccourcis non prvus.




> -Pas de break pour sortir des boucles (Donc oui il faut une variable teste  chaque itration pour dcider de si on arrte la boucle).


Mme chose que pour le goto - sauf que le danger(et donc l'intert de la rgle) est beaucoup plus discutable. A noter qu'en cobol je n'ai pas de break, donc je me farcis souvent un boolen de sortie de boucle. Je prfre largement l'_exit for_ du VBA. Emmerdant, pas catastrophique.




> -Pas de int, que des short


Urk??? Ils ont bu quoi??? Avant, je trouvais les rgles juste contraignantes(sauf peut-tre la premire), mais a, c'est clairement du dlire. Il arrive quand mme frquemment que fonctionellement on aie  grer des entiers  6 chiffres ou plus. Je mange des fichiers  5 millions d'enregs au petit djeuner - et 30 millions au diner. Comment je remplis le compteur de ma log si je suis limit  65535?????

Sur ce dernier point, clairement,  ::aie::  . ajout  l'interdiction des break, on a sans doute  faire  quelqu'un d'un peu trop thorique, qui cherche  gagner de la mmoire  tout prix, et  ne jamais interrompre le flux du programme.

----------


## Bluedeep

> est-ce qu'on peut faire un switch sur les boolens en C? Si on ne peut pas(en C# ou java, on ne peut pas, en cobol ou VBA on peut), alors c'est effectivement catastrophique. Sinon, c'est juste une question de style.


Il n'y a pas vraiment de boolen en C (au sens de type ne pouvant prendre que deux valeurs) mais tout ou presque peut tre test comme boolen.(non null ou non 0 => c'est vrai).

Et un switch sur variable bool fonctionne en C# , comme sur tout type ordinal.(en Java je n'en sais rien)

----------


## Mdinoc

Par contre, en C# on peut faire des switch sur des strings, alors qu'en C on a gnralement besoin de else if(strcmp(param, "--toto")==0)... (Ou bien on fait un switich sur une valeur de hachage ::aie:: )

----------


## el_slapper

> (.../...)
> Et un switch sur variable bool fonctionne en C# , comme sur tout type ordinal.(en Java je n'en sais rien)


hum, a fait un an que je n'ai pas mis les mains sur visual studio, mais je suis  peu prs sur que 


```

```

a ne marche pas, l ou en VBA on peut faire 


```

```

(et dsol pour le C# pourri, ca n'est pas ce que je maitrise le mieux. a doit se voir...).

Mais bon, tout a pour dire que suivant le langage, une rgle peut tre utile, inutile, gnante, ou catastrophique. Pas de _break_ cumul  pas de _Else If_(j'avais pas fait le rapprochement), c'est tout  fait digne de ce fil, car il devient impossible de grer des conditions fonctionnelles un peu recherches.

----------


## Bluedeep

> hum, a fait un an que je n'ai pas mis les mains sur visual studio, mais je suis  peu prs sur que 
> 
> 
> ```
> 
> ```
> 
> a ne marche pas,


Oui, mais a c'est pas l'usage d'un switch; cela ressemble plus au Case SQL dans la variante sans valeur de rfrence  :



```

```

En l'espce, un switch c'est :



```

```


Et avec variable de type bool et case sur true et false a marche trs bien. Les "case" ne pouvant se faire que sur des constantes (et je crois que c'est le cas aussi en C, mais a remonte trop loin; sauf qu'en C on ne peut travailler que sur des ordinaux, car le compilateur transforme cela en une "jump table" en gnral (souvenirs trs lointains d'assembleur x86  ::mrgreen:: ).

Bref, ne pas utiliser le "else if" est de toute manire sous-optimal dans la pluspart des cas.

----------


## pmithrandir

> -Un seul return par fonction
> -Pas de break pour sortir des boucles (Donc oui il faut une variable teste  chaque itration pour dcider de si on arrte la boucle).


Pour moi, c'est deux bonnes pratiques.

Le return unique permet d'identifier a coup sur l'unique point de sortie.(ca aide a dbugger plus vite)

Le break ne sert a rien, sauf si on ne sais pas faire la diffrence entre l'utilisation d'un while, d'un do while et d'un for.
Ce n'est pas parce que l'on itre une variable que l'on doit passer par un for.

Pour utiliser un for, il y a plusieurs conditions : 
 - Ne jamais changer la variable itre  l'intrieur de la boucle.
 - ne jamais interrompre la boucle
 - toujours aller du dbut  la fin de l'itration.


```
for (init i=0;i<50;i++)
```

aura toujours 50 itrations, pas une de moins, pas une de plus.

----------


## pseudocode

> Pour moi, c'est deux bonnes pratiques.
> 
> Le return unique permet d'identifier a coup sur l'unique point de sortie.(ca aide a dbugger plus vite)


hum... C'est clair que ca va plus vite pour trouver o mettre le point d'arrt dans l'IDE.  ::D: 

Mais, de mon point de vue, si on est oblig de mettre un point d'arrt sur ce "return", c'est que:
1. on s'est plant sur les conditions de sorties. 
2. le code est trop complexe pour trouver l'erreur sans le debuggeur.
3. qu'on aurait peut-tre mieux fait de faire des conditions moins complexes et mettre plusieurs return.  ::P: 

Pour moi, le return unique c'est une rgle qui a des avantages mais pas *forcment* une bonne pratique. Le return multiple a aussi ses avantages...


```

```

----------


## Mdinoc

Le "un seul return par fonction", je le trouve nuisible s'il s'applique aussi aux vrifications des paramtres: a encourage un "code boomerang" de if dans des if dans des if...

Une fois la validation termine par contre, je temps  y adhrer ds qu'une fonction alloue la moindre ressource (une fonction de recherche qui n'alloue aucune ressource tend  retourner ds que ce qu'on cherche est trouv, par contre).

----------


## Bluedeep

> Pour moi, le return unique c'est une rgle qui a des avantages mais pas *forcment* une bonne pratique. Le return multiple a aussi ses avantages...


Je suis d'accord mais je trouve que ton exemple n'est pas pertinent. Avec les langages actuels (Java, C#, ...) la pratique pour les conditions d'erreurs est plutt de lever une exception. (bon, c'est vrai aussi que l'exemple est en js ....).

----------


## el_slapper

@bluedeep : ton switch, si(et seulement si) ma variable est boolenne, il ne sert pas  grand chose : autant faire un bte if. Et, si on a besoin de plus d'un test, d'un else if.

Je ne connaissais pas le CASE SQL, mais c'est exactement de cel dont je voulais parler. C'est un outil puissant, qui permet de remplacer les _else if_. Si on a ni l'un ni l'autre, ni le break ni le goto pour faire autrement, a tourne  la torture.

Et soudain, grce  ce dbat(et toutes vos remarques fort pertinentes), je comprends mieux la complainte de ce pauvre Lynix : une seule rgle  la con, a se contourne. Quand tous les contournements sont interdits, il devient difficille de programmer.

----------


## BenoitM

> Je suis d'accord mais je trouve que ton exemple n'est pas pertinent. Avec les langages actuels (Java, C#, ...) la pratique pour les conditions d'erreurs est plutt de lever une exception. (bon, c'est vrai aussi que l'exemple est en js ....).


Me semble qu'on m'a toujours dit le contraire.
Les Exceptions sont lourd  trait 

puis bon quelle est la diffrence entre un return -1; et un throw new Exception? :p





> for (init i=0;i<50;i++)
> aura toujours 50 itrations, pas une de moins, pas une de plus.


Perso quand je fais une recherche j'utilise un for avec un break;
Et dans des codes complexes je trouve qu'il est parfois plus facile d'identifier des return et de break que des if en casquade


```

```

ou


```

```

Si on met uniquement un breakpoint sur le return on ne saura pas si l'element a t cre ou trouv dans la liste.

----------


## pmithrandir

> Me semble qu'on m'a toujours dit le contraire.
> Les Exceptions sont lourd  trait 
> 
> puis bon quelle est la diffrence entre un return -1; et un throw new Exception? :p


Les exceptions ont plusieurs avantages : 
 - elles sont rapides, en particulier lorsque l'exception est rare. Si c'est un comportement courant, on doit utiliser un if.(bref, on utilise pas les exceptions pour remplacer le if).
 - Elles ont un nom, un contenu, un dtail... bref, elles sont bien plus parlante et dtailles qu'un "-1"
 - Elles font partie des rgles gnrales. On a cr les exceptions pour grer les erreurs, utiliser un autre systme va rendre la tache plus difficile pour les autres dveloppeurs.
 - elle peuvent passer trs facilement d'un niveau  l'autre de programmation... elle ont cette capacit a traverser les couches bien pratique selon le besoin.
 - elles permettent de concentrer le code sur le besoin fonctionnel d'un cot, et les erreurs de l'autre(on les voit facilement)

Pour toutes ces raisons, au moins, je pense qu'il est largement prfrable de se servir des exceptions si on les as  notre disposition.

----------


## Grom61736

Convention : Tout doit tre pass dans l'URL.
On ne veut pas de variables de session ni de donnes qui transitent par POST.

Tout, tout dans l'URL mme les mots de passe...

----------


## bedomon

> Convention : Tout doit tre pass dans l'URL.
> On ne veut pas de variables de session ni de donnes qui transitent par POST.
> 
> Tout, tout dans l'URL mme les mots de passe...


HA moi j'ai eu exactement l'inverse et tout devait passer en post et on devais toujours rester sur www.toto.com, donc adieu les favoris pour l'utilisateur  ::aie:: 

Sinon une petite remarque sur les returns multiples, je pense que ceux qui sont pour n'ont pas eu  faire de test unitaire dessus...

----------


## Snack3r

Bonsoir

Quand  moi, a me drangeais qu'une if en Java n'accepte qu'une valeur boolean surtout si on a l'habitude en C de mettre des entiers au lieu d'une expression dans if ^_^

----------


## Mdinoc

> Bonsoir
> 
> Quand  moi, a me drangeais qu'une if en Java n'accepte qu'une valeur boolean surtout si on a l'habitude en C de mettre des entiers au lieu d'une expression dans if ^_^


En fait, j'tais comme a pendant mes premires annes de codage C et C++, mais j'ai fini par me rendre compte qu'crire du code _explicite_ et _lisible_ tait plus important qu'crire du code "compact" et "malin". Depuis, je fais explicitement toutes mes comparaisons ( commencer par celles  NULL), sauf pour les variables vraiment Boolennes (y compris les typedef int BOOL; et autres joyeusets pr-C99).

*Edit:* Cela va de pair avec le fait de garder  l'esprit que _strcmp() ne retourne pas un Boolen_.

----------


## pfeuh

Salut,




> crire du code _explicite_ et _lisible_ tait plus important qu'crire du code "compact" et "malin".


Et c'est mme plus important de mon point de vue que d'crire du code respectant des rgles. Les rgles sont faites pour tre de temps en temps brises. Si nous respections toutes les rgles, nous ne serions que des machines.  ::mrgreen:: 

A+

Pfeuh

----------


## MorganGeek

Je prfre un code un peu moche au dpart mais qui permet une application qui fonctionne que du code propre d'une application qui ne marche pas. Ensuite au fil du temps, le refactoring permet d'amliorer encore et encore le code. Mais quand on fait du prototypage ou autre pratique similaire, la beaut du code n'importe pas vraiment, le but est de prouver au plus vite que a fonctionne et ensuite d'amliorer, ajouter des briques petit  petit  ::):  ( mon sens)

----------


## Bebel

Il faut faire gaffe, j'ai dj vu du prototype (enfin maquette mais c'est pareil) se retrouver en production.

Bah quand la personne a dvelopp la maquette sans code optimis ou mise en forme (en pensant ne faire qu'une maquette) , quand tu dois le reprendre derrire tu souffres.

----------


## MorganGeek

> Il faut faire gaffe, j'ai dj vu du prototype (enfin maquette mais c'est pareil) se retrouver en production.
> 
> Bah quand la personne a dvelopp la maquette sans code optimis ou mise en forme (en pensant ne faire qu'une maquette) , quand tu dois le reprendre derrire tu souffres.


Oui c'est normal mais en effet il faut tre prudent, c'est cependant prfrable de livrer ce proto qui fonctionne bien que ne jamais livrer  ::P:

----------


## Robin56

> Ensuite au fil du temps, le refactoring permet d'amliorer encore et encore le code.


Le pouvoir du refactoring a ses limites. Quand on part sur de mauvaises bases, on ne peut pas tout miser sur le refactoring pour amliorer la chose. Ce n'est pas pour rien qu'il y a des architectes qui rflchissent  la structure des applications ds le dbut d'un projet.




> Je prfre un code un peu moche au dpart mais qui permet une application qui fonctionne que du code propre d'une application qui ne marche pas.


Entre une application qui marche pour ce qu'on lui dit de faire mais ne peut plus voluer sans tout casser et une application bien pense  qui il manque quelques boulons, je ne suis pas certains de faire le mme choix que toi.

Et comme Bebel le fait remarquer, faisons attention au symptme du prototype qui finit en production.

----------


## MorganGeek

> Le pouvoir du refactoring a ses limites. Quand on part sur de mauvaises bases, on ne peut pas tout miser sur le refactoring pour amliorer la chose. Ce n'est pas pour rien qu'il y a des architectes qui rflchissent  la structure des applications ds le dbut d'un projet.


En effet, mais ce n'est pas le cas partout, et dans ces situations o on ne peut compter sur une architecte, et o on a des dlais  respecter, on ne peut pas toujours passer ses journes  rcrire le code en le perfectionnant au niveau lisibilit alors qu'on a encore rien produit.




> Entre une application qui marche pour ce qu'on lui dit de faire mais ne peut plus voluer sans tout casser et une application bien pense  qui il manque quelques boulons, je ne suis pas certains de faire le mme choix que toi.
> 
> Et comme Bebel le fait remarquer, faisons attention au symptme du prototype qui finit en production.


Oui, enfin un bug peut aussi finir en prod  :;):  , il faut faire attention  tout, cependant on dvie du sujet, on parle des normes de codage et je parlais surtout du fait que vouloir s'attarder trop  perfectionner son code  l'infini peut finir par ne jamais livrer pas  temps car il y a toujours de quoi amliorer dans le code, il faut parfois poser des limites et se contenter de quelque chose qui fonctionne afin d'avancer.

----------


## transgohan

Pour les gros systmes complexes on se retrouve souvent  vendre un prototype en fait...
Quand on doit mettre deux  trois ans pour le faire et qu'aprs la prsentation au client pour dcrocher le march on apprend qu'au lieu des 6ans de dev on a en fait que 2ans pour le faire parce que les commerciaux croient dur comme fer que le projet est presque fini vu que le proto fonctionne...
Bah... Tu fais quoi ?
Tu leur dis que ce n'est pas possible et qu'on va devoir payer 4ans de dlai de retard ? Mme ton chef veut pas en entendre parler.  ::mouarf::

----------


## LooserBoy

Rencontr dernirement, un certain nombre de webservices dvelopps en C# avec comme obligation d'utiliser une architecture de type automate avec des tats/transitions alors que le process mtier est purement linaire. De mme pour les business objects qui sont derrire...
Le code est lisible, certes, mais les performances ne sont absolument pas l.
On nous dit que ce n'est qu'un pilote mais combien de pilotes se sont retrouvs en production dans cette boite o j'ai travaill 3 ans par le pass et o je suis retourn par rachat de la boite o je bossais...

Sans compter l'utilisation extrmement abondante de traces (logguer les infos, c'est bien mais on arrive  des limites absolument lysennes...) d'un outil sans aucune fiabilit et extrmement gourmand tant en ressources qu'en performances.

----------

