Quelle est votre hygiène de programmation ? comment vous codez ?

Vous priviligez les performances plutôt que la qualité ?

Ou votre style est plutôt de faire un code souple et flexible ?

Ou peut-être préférez-vous la robustesse d'un code ?

Ici j'aimerais qu'on se donne des astuces et qu'on blablate sur le Workflow.

Personnellement je préfère la souplesse d'un code plutôt que ça robustesse. Et vous ?

sa robustesse*

Par souplesse j'entend fléxibilité

« Par souplesse j'entend fléxibilité »

Je ne demande pas un dictionnaire des synonymes mais bien une définition un peu plus détaillée, juste au cas où. Si tu as des exemples précis de situations où tu as dû faire un choix entre "souplesse/flexibilité" et "robustesse", je suis prenneur.

Généralement je résous le probleme dans un coin comme un cochon, ensuite je l'intègre dans mon projet en moins cochon.

Régulièrement je privilégie la simplicité de l'algo sur la perf par soucis de rapidité de codage et de débug - j'optimiserai "plus tard" (si j'ai des soucis de perf) -

J'ai écris pas mal de code "on the fly" ce qui peut donner des méthodes qui sont pas forcément à leurs place, donnant lieu à des classes trop grosses par manque de séparation des tâches... mais j'essaye de m'améliorer un peu en ce moment. Le problème typique : j'écris une classe qui fait des appels à une API (une vingtaine de méthodes).
Après un an à ajouter des méthodes je dois en avoir 40+ et la classe est juste horrible, alors que j'aurais pu séparer mes méthodes par classes et par fonctionnalités.

je sais que ça parait être une bible du mauvais codeur mais c'est pour souligner aussi le pourquoi il faut essayer de faire propre (ce que j'essaye de faire ATM) mais c'est aussi en étant confronté aux erreurs classiques qu'on apprends à mieux coder :]

Du coup je pense en effet que le meilleur moyen d'avoir un projet souple et robuste à la fois c'est d'avoir une séparation assez fine des tâches qu'un programme doit réaliser.
De mon expérience, ça donne des classes assez légère auxquelles on peut ajouter plus de fonctionnalité facilement car chaque module est bien séparé (moins d'effet de bords quand tu touche au code), et tu peux changer la manière de travailler de chaque module sans changer d'un poil le comportement de l'app

De mon côté : souplesse et robustesse.

Déjà, je me prends la tête le plus possible pour avoir des nommages cohérents, et compréhensible par tous.
Pas de nom contextualisé, ou rarement, et ceux-ci sont toujours documenté.
Le moins de commentaire possible, aussi, partant du principe qu'un code doit se documenter lui-même. Bien entendu, pour chaque portion sortant de l'ordinaire (utilisation d'un algo en particulier, bizarrerie de code...) un commentaire est rajouté pour expliquer la raison (je me suis déjà piégé moi-même de ce côté-là, j'essaie d'éviter).
De ce côté-là, j'adore la phrase "développez comme si la personne qui reprendra votre code est un psychopathe qui connaît votre adresse".

Ensuite, niveau architecture : une classe doit avoir un nombre limité de responsabilité. Si elle commence à faire le café... il faut revoir le découpage, et limiter le couplage. Idem pour les méthodes.
Bien sûr, quand le tout est possible.

Dès que j'ai deux blocs de code ou deux méthodes qui font exactement la même chose dans un contexte similaire, je tente de factoriser et d'externaliser. J'évite au maximum les duplications de code car je suis feignant (je n'ai pas envie de devoir passer sur chacune des classes pour la correction ou l'évolution) et que, puisque le code est centralisé, cela me permet de facilement corriger ou faire évoluer.

Avec un couplage faible et une architecture hiérarchisée, je peux ensuite répondre plus facilement et plus rapidement aux changements de dernière minute de l'application, ou aux urgences.

Le tout, en faisant en sorte de ne prendre en compte que les cas minimaux de succès, pour que chaque autre situation soit géré et passe automatiquement en erreur, en faisant le moins planter, et si ça plante, remonter l'erreur obligatoirement avec les informations de contact du client en plus de l'erreur (histoire de pouvoir le contacter au cas où il aurait 50 crash dans la journée, pour se renseigner, et faire un geste commercial ensuite).

En bref : le plus possible la factorisation, éviter le couplage, une classe = certaines responsabilités, une méthode = UNE responsabilité, code self-documented, gestion de code minimale.

Par contre, il me manque tout un pan sur les tests unitaires, ce qui rend les refactoring moins sûr.

Globalement j'ecris du code pour deux raisons. Soit pour tirer des performances. Soit pour analyser des resultats.

Si le but est de tirer des performances, ce qui m'importe est les perfromances et pas la lisibilite. Si je peux avoir les deux c'est bien, sinon tant pis pour la lisibilite. La en general tous les coups sont permis, hypothese sur le type de machine, utilisation d'instruction vectoriel, eventuellement de l'inline assembly. Ces fonctions haute performance sont typiquement encapsule proprement pour etre utile a d'autre et bien document, mais le code de la fonction en elle meme, RAF tant que ca va vite. En general, il y a un papier scientifique a cote qui explique les grande ligne de comment ca marche.

Si le but est d'analyser des resultats, la en general c'est du code qui ne va pas vivre tres longtemps (generalement moins de 2 mois). Et du coup l'important est la reutilisabilite le temps que je finisse d'analyser ce que j'ai a analyser. Donc en general, c'est du script degeu un peu modulaire et tres peu documente.

En terme d'outils, j'utilise la panoplie complete du developpeur unix. J'ecris assez de script pour faire mes test en une ou deux commandes: compiler le code, faire des test unitaire simple, deployer le code sur un cluster, lancer les tests necessaire, aggreger les resultats, plotter toutes les courbes qui vont bien.