Pour l’organisation du code, le seul argument que je donnerai, c’est la simplicité de merge lors de la collaboration avec plusieurs personnes. En effet, si plusieurs développeurs travaillent sur des parties différentes, il y a de grandes chances qu’ils ne touchent pas les mêmes fichiers, donc, que le merge soit trivial. Pour un gros fichier, ça peut être plus problématique.
Je vois un autre avantage, ça oblige a structurer le code... je n’ai pas vu le code, je n’ai donc aucun commentaire dessus, je parle en général. Un seul gros fichiers, tu ajoutes juste une fonction, avec pleins de fichiers, il faut réfléchir dans quel composant le mettre. En cas d’erreur, il faut déplacer le code d’un fichier à l’autre, ce qui n’est pas le cas pour G'mic.
[^] # Re: color2gray et organisation du code
Posté par Anthony Jaguenaud . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 5.
Pour l’organisation du code, le seul argument que je donnerai, c’est la simplicité de merge lors de la collaboration avec plusieurs personnes. En effet, si plusieurs développeurs travaillent sur des parties différentes, il y a de grandes chances qu’ils ne touchent pas les mêmes fichiers, donc, que le merge soit trivial. Pour un gros fichier, ça peut être plus problématique.
Je vois un autre avantage, ça oblige a structurer le code... je n’ai pas vu le code, je n’ai donc aucun commentaire dessus, je parle en général. Un seul gros fichiers, tu ajoutes juste une fonction, avec pleins de fichiers, il faut réfléchir dans quel composant le mettre. En cas d’erreur, il faut déplacer le code d’un fichier à l’autre, ce qui n’est pas le cas pour G'mic.