Convention/doc arborescence d'un projet

Bonjour (ou bonsoir), je me pose une question au niveau des convention d'arborescence d'un projet:
en fouillant dans quelque Library j'ai remarqué que les tests unitaires étaient souvent dans un dossier "test" à la racine de la librairie, cependant d'une librairie à une autre tout change...

un coup un fichier .py -> un seul test
des fois un fichier .py -> tous les tests
ou même encore un fichier .py par fonctionnalité du programme, avec plusieurs tests par .py

Donc ma question est : existe t'il une convention ou une doc là dessus, pas seulement sur les tests unitaires mais tous ce qui est en rapport avec l'arborescence, par exemple les exceptions personnalisés ou y met où? dans le code qui utilise ses exceptions? dans un dossier à pars avec d'autre exceptions ?

Salut,

N'ayant aucun recul sur les tests unitaires, sachant que j'en fait (rarement) jamais, je n'en vois pas l'utilité dans mes simples scripts, je pense que cela est comme le développeur le sent, et surtout de la complexité du code et de l'envergure d'un projet, d'une librairie, module.

Faut cesser de vouloir respecter à la lettre des normes de conventions partout, chacun fait comme il l'entend, comme la pep python, personnellement je m'en tamponne totalement le coquillard, je fais de la façon avec laquelle je suis à l'aise, qui reste lisible et compréhensible.

Quant à la structuration de l'arborescence d'un projet, c'est pareil, on fait de la façon avec laquelle on se sent la plus à l'aise, certains vont préférer faire un truc sauce java, un fichier une classe (pour ma part cela rend le tout imbitable et difficilement lisible), d'autres vont préférer regrouper les fonctionnalités de codes ayant de gros rapports, bref il y a autant de façon de coder que de développeurs.

Les exceptions, c'est pareil que tout autre code, si c'est une exception uniquement utilisée dans un unique module et dont tu sais définitivement que tu n'en auras jamais besoin ailleurs, tu peux la fourrer dans le module en question, mais rien n'empêche de regrouper tes exceptions dans un module dédié, encore une fois fais de la façon avec laquelle tu te sens le plus à l'aise.

Mon opinion là-dessus, est celle d'un amateur, les professionnels ont sans doute un autre (d'autres) avis que le mien, mais c'est ce qui fait la beauté de ce monde (ce qu'il en reste), les divergences, les singularités, les variétés, etc.

Merci de ta réponse , justement j'ai du mal à me faire mon propre avis avec le peu de pratique que j'ai (juste un projet de 1000lignes à mon actif) et je compte étoffer se projet, je voudrait juste avoir un temps d'avance sur le futur foutoir que je vais faire ^^

Bah je ne saurais te conseiller sur la méthode parfaite ou recommandée à adopter quand on débute, c'est pas mon métier...

Mais pour se forger, rien de tel que de lire divers tutoriels et code source construits différemment et ainsi voir ce qu'on aime ou on aime pas dans telles façons de procéder(avantages, défauts), cela viendra irrémédiablement au fil du temps.
Pour moi le plus important lorsqu'on débute est de s'en tenir à faire de petits projets et surtout de les terminer (peu importe la manière), et ensuite lorsqu'on a un tant soit peu acquis de la bouteille, revenir plus tard dessus pour les améliorer (les recommencer) selon les nouvelles choses qu'on a découvertes avec l'expérience acquise.

De toute façon, je pense qu'on se casse souvent les dents lorsqu'on débute que ce soit sur la structure d'un projet que du script en lui-même, et même bien plus tard :aie:

Bon c'est encore un avis qui n'engage que moi, les pros sont pas très causant, ou alors ils sont en vacances :mrgreen:

Citation:

---

Envoyé par flapili

Justement j'ai du mal à me faire mon propre avis avec le peu de pratique que j'ai (juste un projet de 1000lignes à mon actif) et je compte étoffer se projet, je voudrait juste avoir un temps d'avance sur le futur foutoir que je vais faire ^^

---

Citation:

---

Envoyé par bistouille

Bon c'est encore un avis qui n'engage que moi, les pros sont pas très causant, ou alors ils sont en vacances :mrgreen:

---

Il n'est pas facile de répondre à ce genre de sujet en quelques lignes. D'autant qu'il existe une rubrique entière sur DVP qui traite ces sujets application lifecycle management.

Pour faire bref, l'organisation n'apporte pas grand chose aux fonctionnalités d'un programme. Par contre, sans organisation, on écrira assez facilement des programmes de quelques dizaines de lignes mais on va piétiner pour écrire plusieurs centaines voire milliers de lignes.

Après est-ce qu'il y a des règles à suivre? Probablement mais elles vont dépendre du type d'application et des individus qui les définissent. Beaucoup de règles relèvent du bon sens et d'autres sont plutôt comme le code de la route i.e. entre plusieurs solutions (rouler à gauche ou à droite), il faut faire un choix et s'appliquer à le respecter pour que çà fonctionne.

- W

Ou voilà, c'est un peu ce que j'essayais de dire, mais tu l'as bien mieux formulé que moi.