Conflits de styles Java au sein d'une équipe

Je fais partie d'une équipe de développement Java avec un délai de 6 semaines. Cela nécessite d'écrire beaucoup de code très très rapidement. Cependant, notre équipe de développement a différents styles de codage. Tout, des conventions de noms aux méthodes d'abstraction, diffère au sein de notre équipe. Quelqu'un connaît-il des documents qui dictent des "normes" pour java?

Pour clarifier, je me demandais s'il y avait une organisation qui dicterait une convention de dénomination appropriée pour les variables et les fonctions par exemple. C'est primordial car avec un délai aussi court, nous ne pouvons pas nous permettre de passer du temps à essayer de comprendre le code de chacun.

Il existe une telle organisation: Sun / Oracle elle-même. Le document s'appelle Conventions de code pour le langage de programmation Java et décrit la plupart des conventions dont vous avez besoin. Faites en sorte que tout le monde accepte de le lire et de suivre ses recommandations.

Je m'attache vraiment à la réponse d'Andres et je me concentre sur l'aspect formatage uniforme du code java.

Si vous utilisez Eclipse, vous pouvez définir son formateur Java pour qu'il se mette automatiquement au format Java. Le formateur Eclipse possède également d'autres paramètres utiles, tels que les caractères par ligne (c'est-à-dire le nombre de caractères par ligne avant de passer à une nouvelle ligne), et bien d'autres. La normalisation des caractères par ligne facilite la différenciation du code écrit par différents développeurs sans avoir beaucoup de différences uniquement à cause de l'espacement et des sauts de ligne.

Enfin, avec Eclipse, après avoir défini tous les paramètres souhaités, exportez votre formateur sous forme de fichier qui peut être importé par tous les membres de l'équipe. Donc, si vous utilisez Eclipse, je vous recommande vivement d'explorer pleinement toutes les options qu'il formatera automatiquement et de modifier le code pour vous, puis de partager les paramètres avec toute l'équipe.

Je suppose que les autres principaux IDE java (IntelliJ et Netbeans) ont une fonctionnalité similaire pour exporter les paramètres de format.

Ce [différents styles de codage] est primordial car avec un délai si court, nous ne pouvons pas nous permettre de passer du temps à essayer de comprendre le code des autres.

Réellement. Ce n'est pas primordial.

Après 30 ans en tant que consultant, j'ai lu beaucoup de code de nombreux clients. Il est important de noter que chaque client (et souvent au sein de l'organisation d'un client) a des styles différents.

Après avoir lu tant de styles, j'ai appris cela.

Le style n'a pas d'importance

Veuillez vous concentrer sur l'écriture de code qui fonctionne toujours et sur l'écriture de tests unitaires qui prouvent qu'il fonctionne toujours.

Après avoir expédié le code de travail, vous pouvez l'habiller si vous n'avez plus de bogues à corriger et d'améliorations à installer.

Ne vous inquiétez pas de choisir une norme universelle parfaite. Tout ce dont vous avez besoin est que votre équipe accepte une norme et s'y conforme. Composez le vôtre si vous le souhaitez, mais soyez cohérent.

La cohérence améliore la collaboration, la collaboration améliore le code.

Même si la cohérence réelle n'aide pas, le fait que votre équipe ait travaillé ensemble pour parvenir à un accord est une bonne chose. Leur incapacité à accepter quelque chose d'aussi simple que les conventions de codage indique qu'il peut y avoir de plus gros problèmes de travail d'équipe qui se cachent sous la surface.

Le Sun Java CC mentionné ci-dessus a non seulement 13 ans et certaines de ses règles sont obsolètes (comme 80 caractères par ligne), mais il ne définit pas non plus les conventions de dénomination, à l'exception des plus générales (boîtier chameau pour les classes, capitales de bloc) pour les variables finales statiques et similaires).

Vous devez définir vos propres normes pour différents types de classes, comme les DAO, les EJB, les entités, tout ce que vous utilisez. Sun Java CC est comme une classe de base abstraite destinée à être étendue :)

Comme mentionné par d'autres ici, vous pouvez rechercher en ligne l'un des rares «guides de style» populaires pour Java et persuader tous les membres de l'équipe de s'y tenir. Certains outils de vérification de code dans votre IDE préféré pourraient vous rappeler lorsque vous ne le faites pas.

Cependant, parfois la politique est impliquée. J'ai déjà été dans une situation où le développeur le plus expérimenté de l'équipe continue de le faire à sa manière même après que quelqu'un a mentionné le besoin de normaliser. Dans une telle situation, il serait peut-être préférable d'observer son style de code et de le suivre car il a probablement le plus de connaissances sur la base de code et les exigences et vous ne voudrez peut-être pas perdre de temps à marcher sur ses orteils même s'il est difficile. C'est ce que nous avons fait dans cette situation particulière et je suis à contrecœur.

Il est donc important de prendre également en compte votre situation.

Oncle Bob montre un style de codage plus moderne et actuel dans son livre "Clean Code". Malheureusement, il ne contient aucune liste d'articles. Vous devez le lire. Il se dit que pour voir ses conventions, il faut lire son code. L'oncle Bob est sans aucun doute une sorte d'institution. Le livre est de toute façon une excellente lecture, donc même s'il est trop tard pour le lire maintenant, lisez-le dès que possible.

Ce qui importe vraiment dans le code est une faible complexité cyclomatique, une petite portée, une cohésion élevée et un choix d'identifiants expressifs. Compte tenu de ceux-ci, le code devient facile à saisir et un tel code est bon.

Je vous suggère de regarder dans la programmation Spartan .

La plupart des normes de codage vous indiquent comment rendre joli un code mal écrit et la plupart des discussions sur le "style de codage" concernent en fait le formatage. Le formatage du code consiste à représenter visuellement la structure de votre code. Il est trivial et automatisable et n'a pratiquement rien à voir avec le style de codage, car le style de codage ne concerne pas la façon dont vous représentez la structure du code, mais la façon dont vous structurez le code.
Il y a aussi beaucoup de guerres de religion à propos des conventions de dénomination, bien qu'elles ne soient vraiment qu'un hack pour contourner une mauvaise conception. Un nom est bon, s'il dit ce qu'il signifie. Plus vos portées sont petites et claires, plus il est facile de choisir un tel nom.