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

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 détail... bref, elles sont bien plus parlante et détaillées qu'un "-1"
- Elles font partie des règles générales. On a créé les exceptions pour gérer les erreurs, utiliser un autre système va rendre la tache plus difficile pour les autres développeurs.
- elle peuvent passer très 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 préférable de se servir des exceptions si on les as à notre disposition.

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

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

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

Oh non tu te trompes, j'écris du code comme ça très souvent et je vis certainement dans un monde très 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 ).

Après que se passe-t-il si jamais je commence à avoir besoin de return partout? Ben je refactore, genre je délègue les cas particuliers à de nouvelles méthodes. En fait il est rare que je dépasse le 2 niveaux d'indentation dans une méthode et si je dois scroller ou analyer les parenthèses 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 méthode elle fait peut être trop de choses".

Donc j'utilise volontiers un return en cours de fonction afin de bien documenter la réflexion, pré-condition non remplie? -> hop tu dégages d'ici. L'objet en cours est une pomme? -> hop délègue à la méthode 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 à représenter la logique de ton traitement en utilisant des return *par exemple* de sous-méthodes.

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

Le problème quand tu bosse sur des vrai programmes, c'est qu'ils sont amené à évolué d'une façon que tu ne peux pas prévoir (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 même pour la partie non-métier qui ne dépend pas de ton client, ton code évoluera si il est utilisé, donc y'a des chances qu'une fonction soit réutilisé à un autre endroit de ton code même si au départ ça ne devait pas être le cas.

Pour l'argument du "Si on découpe 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 méthode m'ouvre le bon fichier à l'endroit où est définis la fonction.

Découper 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 début 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 vérifier 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 à débugger souvent. Tu check les entrés sorties des fonctions et tu vois où ça merde. Une fois que t'as trouvé la fonction qui pose problème 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 problèmes avant de te pencher réellement sur le problème en lui même.

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 !

Pour tomber dans la dérive inverse

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

Je dirais que le plus gros problème c'est que ça finis presque systématiquement par tourner au Franglais. Du coup on ne sait plus si on a un Bouton ou un Button, un statut ou un status, ...

Les tabulation sont heureusement encodée pareil, quelque soit l'OS.

Dans ce cas là il faudrait idéalement 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 problème c'est que comme chacun fait sa sauce, au final on fini par aller au plus simple, c'est espaces partout

Oui d'accord de manière générale,sauf si t'as la malheureuse expérience de développer 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 même une simple classe

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.