Parlant d'expérience ...
Le premier projet Open Source auquel j'ai contribué, j'étais plein de pisse et de vinaigre quand j'ai commencé aussi.
Ce que j'ai immédiatement fait, c'est de parcourir un tas de fichiers source et de commencer à styliser les choses selon mes préférences personnelles, de créer un énorme patch et de le soumettre.
Si vous travaillez avec quelqu'un qui est «bon» (comme moi), il rejettera immédiatement le patch. Principalement parce que, lorsque vous contribuez à un projet open source, vous êtes censé décomposer vos correctifs en morceaux de taille de bouchée qui répondent à un seul problème. 'Supprimé tous les gotos' n'est pas un bon exemple de commit atomique. Même si vous le divisez en commits plus petits et bien documentés, il peut tout de même être rejeté.
La raison en est, parce que le code est travaillé par plusieurs personnes (avec des styles différents) au fil du temps, il n'est pas vraiment possible d'accepter des modifications sur l'ensemble de la bibliothèque pour convenir au style d'un développeur. S'il était possible de changer de style pour le style, alors chaque projet open source ne progresserait jamais car le code serait constamment édité pour s'adapter aux différents styles de développement.
La refactorisation du code et l'ajout de fonctionnalités (ou la suppression de la déchirure obsolète) ont généralement priorité sur le «nettoyage» du code.
La partie la plus difficile et la plus gratifiante du travail sur un projet open source est, on vous demandera pourquoi vous proposez d'apporter les modifications que vous soumettez. Si vous pouvez donner une bonne raison, il y a de meilleures chances que votre patch soit envoyé.
Mon conseil est de faire quelques-unes de ces modifications sur un fichier source pour donner un avant-goût de ce que vous essayez de faire en premier. Si les changements sont bien justifiés et acceptés, demandez si d'autres changements comme celui-ci amélioreraient la qualité du projet. De cette façon, vous ne perdrez pas beaucoup d'efforts pour rien si vos correctifs sont rejetés à l'avenir.
Développer l'open source, c'est plus qu'écrire du code. Vous travaillez à construire une relation de confiance car les gardiens (les développeurs qui contrôlent l'accès push) feront ce qu'ils doivent pour protéger l'intégrité du projet. Lorsque vous soumettez plus de correctifs, le portier aura une meilleure idée de votre style et vous n'aurez pas à justifier autant vos modifications.
C'est un processus qui prend du temps mais c'est très enrichissant. Non seulement vous apprendrez beaucoup en étant capable de regarder et de critiquer le code de quelqu'un d'autre, mais vous serez critiqué sur votre propre style.
Avant de perdre beaucoup de temps à essayer de `` corriger l'injustice des erreurs du style de codage des autres '', demandez-vous ceci:
Les changements que vous proposez sont-ils basés sur l'ajout de valeur au projet ou sont-ils basés sur votre propre religion stylistique interne.
Il y a beaucoup de religion sur Stack Overflow (et les sites Stack Exchange associés). Je veux dire beaucoup . Les gens pensent et parlent sans cesse du style, comme si plus vous en parliez, plus vous vous rapprochiez du style de codage `` parfait, idéal, indestructible, infaillible ''. J'en parle beaucoup trop surtout parce que c'est amusant.
Dans le monde Open Source, le style n'est pas si important. La fonction est .
Remarque: Tous ces conseils supposent que votre contrôleur d'accès est un programmeur raisonnable et talentueux. Si tel est le cas, comptez-vous chanceux de ne pas être coincé avec l'un des b @ & # & es pleurnichards dont la seule préoccupation est de protéger leur «bébé». Ils n'existent dans la nature, alors ne soyez pas surpris si vous rencontrez un.
goto
n'est pas nécessairement un gâchis. Il existe de nombreux cas où son utilisation est parfaitement justifiée.