Quelle est l'importance d'un bon style de codage pour la décision d'embaucher un programmeur? [fermé]

Même en tant qu'étudiant, on me demande de revoir le code des programmeurs qui ont (non) réussi un test (créer une liste de numéros de Fibonacci sur Android).

Bien que je sois très strict sur le style de codage, je viens de lire le style "bloc" que quelqu'un a utilisé (lire les commentaires!) .

Dans ma position, je recommanderais de ne pas embaucher un gars utilisant ce genre de style. Le code est complètement à l'opposé du style de codage utilisé dans mon entreprise.

Tout en recherchant le style de codage et comment faire face à un manque de celui - ci, je suis curieux d'une chose: devrais-je embaucher un gars qui auraproblème grave adapter le style de codage utilisé dans l'entreprise?

S'il vous plaît: Cela ne devrait pas être une discussion sur le style de codage en général et ce qui est mieux. Il s'agit de l'importance du style de codage pour la décision d'embaucher quelqu'un!

Plus d'information:

Je ne suis pas le gars qui prend la décision, je donne juste mon opinion basée sur le code. Le gars doit passer une entrevue où notre chef de tout vérifie les compétences générales. S'il a réussi, il doit passer notre petit test de compétence et c'est là que parfois on me demande de revoir le code écrit. Je ne suis pas en mesure de dire oui ou non. Je veux juste savoir à quel point le style de codage devrait être important pour ma revue ...

Comment savez-vous qu'il aura du mal à s'adapter? Tout simplement parce qu'ils utilisent un style de codage différent? C'est assez présomptueux. Je suis un entrepreneur depuis longtemps et quel que soit le style de codage utilisé, vous vous adaptez. Cela peut prendre un certain temps, mais les habitudes se forment assez rapidement.

J'espère que le style de codage ne signifie pas seulement l'indentation et la mise en page du code. Cela est facilement résolu en utilisant un formateur de code et en l'intégrant dans votre système de contrôle de version.

Prenant le style de codage pour signifier des choses comme la dénomination, l'ordre général, la séparation des unités et tout ce qui concerne la lisibilité et la maintenabilité, la chose la plus importante à propos du style de codage est que vous en avez un. Pas lequel. Ne pas avoir de style de codage est un drapeau rouge certain.

La deuxième chose la plus importante à propos du style de codage utilisé par quelqu'un, c'est qu'il l'utilise de manière cohérente. Quand quelqu'un semble utiliser un style de codage, mais souvent "pèche" contre, c'est un autre drapeau rouge défini.

Ayant programmé des centaines de projets différents pour près d'une centaine de clients différents, permettez-moi de souligner un point.

Le style de codage (et l'ergotage sur le style de codage) est une perte de temps totale.

Passer à autre chose.

J'ai lu beaucoup de code de beaucoup de programmeurs différents. (Supposons une taille médiane d'équipe de 5 et 100 équipes différentes. Cela fait 500 collègues.) Le style n'a pas d'importance.

J'ai vu du code joli mais pathologiquement incorrect.

[Il existe une limite. L'obscurcissement intentionnel est un motif de résiliation. Bref, le style est une perte de temps.]

Le style de codage est la «dernière frontière»

Si vous avez résolu tous les problèmes de développement logiciel; si vous pouvez produire un code sans erreur plus ou moins instantanément; si votre niveau de qualité est si élevé, vous n'avez plus de file d'attente de correction de bogues; si votre convivialité est si fabuleuse, vous n'avez plus de service d'assistance; si vous êtes en mesure d'optimiser impitoyablement au point où vous n'avez pas de batterie de serveurs, mais exécutez l'entreprise à partir d'un iPad ...

Lorsqu'il n'y a plus rien à corriger, vous pouvez enfin vous concentrer sur le style de codage.

Jusque-là, de nombreux problèmes sont plus importants et plus précieux que le style.

Juger les programmeurs en fonction du style de codage est 50% snobisme et 50% insécurité.

J'aime que mon code soit soigné et propre, et cela ressemble aussi au gars sur lequel OP a fait des haillons dans le lien. Notre code ne se ressemble pas, mais nous utilisons tous les deux un style qui nous aide à comprendre le code lorsque nous y revenons. Je n'ai eu absolument aucun problème à comprendre son code et je doute que l'OP l'ait fait non plus. Les «conseils» de style de codage ne sont rien d'autre qu'un plan facile et bon marché où vous pouvez exprimer votre immense sagesse sur la raison pour laquelle les accolades devraient être sur la ligne suivante. Cela n'a pas d'importance du tout. Ce qui rend le code difficile à lire est:

• conventions de dénomination insensées (ou leur absence) qui ne décrivent pas ce qu'elles représentent.
• flux de programme insensé qui rend difficile de dire ce qui se passe (aller, essayer / attraper avec la logique métier, etc.).
• des fonctions incroyablement longues qui font plus de choses que le cerveau ne peut suivre.

J'ai du mal à imaginer un code qui ne fait rien des choses énumérées ci-dessus, mais qui est toujours difficile à lire, en particulier avec un outil comme Style Cop.

Il est ridicule que le format du code soit un facteur lors de la décision d'embaucher quelqu'un.

1. Il y a beaucoup plus de facteurs importants à considérer.
2. La plupart des développeurs peuvent adapter leur style.
3. Si le format est si important, utilisez un reformateur de code et un vérificateur de peluches.

Ne pas embaucher un bon développeur car il n'ajoute pas d'espace après une virgule est idiot.

Je suppose que vous avez un style de formatage officiel dans l'entreprise.

Ensuite, il est extrêmement facile de reformater n'importe quelle source dans le style officiel, et de préférence de le faire automatiquement à chaque fois que le fichier source est enregistré.

Tout programmeur digne de ce nom adorera cela, car il garantit une meilleure qualité en minimisant les différences pour les commits.

Utilisez StyleCop

Si vous utilisez Visual Studio, vous pouvez toujours forcer les règles StyleCop avec votre compilation, ce qui garantira que votre code est au moins lisible.

Je rejette le code illisible sans doute de style non standard , car il deviendra très difficile à maintenir à l'avenir - même par les auteurs eux-mêmes. Cela a été prouvé à plusieurs reprises dans le passé.

Formatage de code intégré CVS = solution optimale

Ce serait vraiment génial si l'un des CVS prenait en charge le formatage automatique du code lors des enregistrements. Vous définiriez simplement vos priorités de style, le code serait formaté avant d'être enregistré. Cela rendrait le style spécifique au développeur obsolète en termes de formatage de code. Je peux voir le problème si certains développeurs utilisent des caractères d'indentation différents. Ce n'est pas si problématique pour moi de regarder un code différent (et je peux le reformater facilement et rapidement) mais DIFF devient plus difficile à gérer. Beaucoup de faux positifs dans l'outil DIFF.

Bien au-dessous des détails beaucoup plus importants suivants:

• Fit d'équipe
• Capacités de résolution de problèmes
• la communication

La plupart des gens qui ont les deux derniers énumérés ci-dessus peuvent apprendre les styles de codage.

Cependant, je vois généralement un échantillon de code avant l'entrevue finale, et si le style de codage est loin de ce que nous utilisons, je me concentrerai sur les questions qui révèlent leur capacité à s'adapter.

Tant que le style est cohérent et que cette personne est capable de s'adapter (changer) à un autre style, je ne vois aucun problème.

Si le style actuel est différent de ce que vous utilisez, cela ne signifie pas qu'il est mauvais. Pour le candidat, cela pourrait avoir tout son sens.

Tout comme d'autres l'ont dit, avoir du mal à s'adapter pourrait être le seul problème.

Je ne dirais pas que c'est définitivement une embauche, mais c'est un argument fort contre cette personne.

Je ne m'inquiéterais pas réellement du style de codage, mais de cette incapacité à s'adapter étant le symptôme d'un problème général. J'aurais peur que le candidat ait également du mal à s'adapter à d'autres aspects de la culture d'équipe.

Si vous ne pouvez pas vous concentrer sur l'utilisation d'un style pascal au lieu d'un boîtier de style chameau, vous pouvez très bien avoir du mal à vous rappeler de commencer un nouveau lot de café si vous deviez prendre la dernière tasse. Ce genre de chose peut être très dangereux pour l'équipe.

(Et oui, je suis accro à la caféine.)

À mon avis, un bon style de code est essentiel pour qu'un programmeur puisse travailler.

Avoir un bon style de code est une question de développement personnel. C'est un indicateur du niveau déjà atteint par ce programmeur.

La question est de savoir si votre entreprise souhaite des "hauts professionnels" ou des "hauts potentiels". Si vous avez besoin de «professionnels de haut niveau» et qu'il n'y a pas de place pour apprendre et évoluer - le style de code est un critère à éliminer.

S'il y a de la place pour l'évolution et le développement de programmeurs, vous feriez mieux de prendre soin de sa capacité à apprendre rapidement ou à penser de façon créative.