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

15

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 ...

hiring coding-standards coding-style WarrenFaith
la source
9
Intelligent. Plutôt que de supprimer les «graves difficultés d'adaptation» (qui ne sont pas étayées par les faits), mettez une ligne à travers. Comme si cela changeait réellement l'affirmation sans fondement de l'attitude de quelqu'un d'autre.
S.Lott
2
Le style de codage est la chose la moins importante qui devrait vous préoccuper. Après tout, ce n'est qu'un code.
SK-logic
7
J'essayais de lire votre question, mais j'ai trouvé votre mise en forme difficile à suivre. Pourriez-vous ajouter un retrait de départ à vos paragraphes. 'K THX BAI
dietbuddha
2
La cohérence (ou son absence) du code est un indicateur. Par exemple, si quelqu'un n'a pas le temps d'organiser son code, il n'a probablement pas non plus le temps de trouver le bon endroit pour valider un nouveau projet en subversion. Ils n'ont probablement pas le temps de refactoriser. La liste continue.
Kevin
10
Le style de codage est ridiculement facile à ajuster. C'est comme demander "Cette personne porte des costumes noirs, mais dans notre entreprise, nous préférons que les employés portent des costumes gris foncé. Dois-je les embaucher?" Dites-leur simplement les règles de style que vous avez dans votre entreprise. Problème résolu.
lucy juteuse

Réponses:

41

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.

Marjan Venema
la source
5
+1 n'en avoir pas, ou ne pas l'utiliser de manière cohérente sont des «drapeaux rouges», ce n'est pas le cas d'un style différent.
jv42
1
Je suis totalement d'accord sur "au moins l'utiliser de manière cohérente". C'est la chose la plus importante lorsque je passe en revue le code. Mais vous devez admettre que le style de code / format de code est la toute première impression que vous obtenez lorsque vous regardez un code étranger ...
WarrenFaith
3
@WarrenFaith: vous jugez donc un livre par sa couverture? :-) Sérieusement, oui, cela donne une première impression, mais je suppose que lors des entretiens, vous veillerez à regarder au-delà et à ne pas laisser passer un développeur parfaitement capable simplement parce que son style actuel ne correspond pas au vôtre.
Marjan Venema
+1 pour la cohérence: le manque de style indique généralement qu'ils n'ont pas beaucoup écrit. Lorsque vous écrivez, vous choisissez des habitudes.
Matthieu M.
1
Je déteste les formateurs de code automatiques, mais je peux en accepter le besoin. Ils semblent juste choisir des sauts de ligne à tous les mauvais endroits. Oui, je parle d'éclipse.
Kevin
27

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.

S.Lott
la source
2
@WarrenFaith: Je ne peux pas le dire assez fort. Ce n'est pas important. Je répète mon point. J'ai lu (professionnellement, contre rémunération, heures facturables) le code de centaines et de centaines de programmeurs. Ce n'est pas important. Ce n'est pas la première impression: la justesse et la clarté sont les premières impressions.
S.Lott
2
@WarrenFaith: L'obscurité intentionnelle est rare. "si vous ne pouvez tout simplement pas lire le code" est quelque chose qui peut être autant le problème du lecteur que celui de l'auteur. Je répète mon point. J'ai lu (professionnellement, contre rémunération, heures facturables) le code de centaines et de centaines de programmeurs. "Je ne peux tout simplement pas lire" ne s'est jamais produit. Le style n'a pas d'importance.
S.Lott
2
Le style de codage (et l'ergotage sur le style de codage) est une perte de temps complète. - Je suis d'accord à 100% sur le deuxième point, et à environ 40% sur le premier. Le style de codage est important - s'il n'y a aucun style dans votre codage. S'il y en a, peu importe à quoi il ressemble.
Treb
4
@WarrenFaith: J'ai regardé l'échantillon, et je n'y vois rien qui ne soit pas clair. Il n'est pas formaté comme je pourrais le formater, mais il n'y a rien qui indique que le code ne fonctionnera pas. Il n'y a rien de flou à ce sujet. Rien n'indique que la personne qui a écrit ne pourrait pas ou ne voudrait pas se conformer à une norme d'équipe. @ S.Lott a raison. Ça n'a pas d'importance.
Joel Etherton
4
Et en utilisant //Importantsur chaque ligne. Ahem. Chaque ligne de code est importante ou doit être supprimée.
S.Lott
7

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.

Morgan Herlocker
la source
7

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.

Dietbuddha
la source
4

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.


la source
oublié les problèmes de commit ... et oui, nous avons un style de formatage officiel et aussi un formatage automatique avant l'enregistrement.
WarrenFaith
@Warren, eh bien, dites-le lors de l'entretien et assurez-vous que le programmeur comprend que c'est important. Ensuite, c'est à lui de tenir sa promesse s'il veut garder son emploi.
4

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.

Robert Koritnik
la source
Donc ... si une entreprise inventait ses propres normes de codage C #, serait-ce un drapeau rouge?
Job
1
@Job: Pas nécessairement parce que StyleCop permet d'ajouter des règles supplémentaires. Je sais que j'en ai écrit deux qui ont appliqué des TAB sur des ESPACES qui n'étaient pas là en premier lieu. Mais l'idée est que le style de codage peut être forcé, ce qui rendra beaucoup plus facile d'avoir un code uniforme.
Robert Koritnik
Et si leur style revenait à celui de StyleCop, et s'ils n'utilisaient pas du tout StyleCop - serait-ce alors?
Job
@Emploi. À moins que quelqu'un n'écrive pas de code C # comme s'il s'agissait d'un ancien Fortran (disposition fixe à 80 colonnes?), Je pense toujours que le style de codage peut être demandé. Si quelqu'un est un grand développeur, vous pouvez lui rappeler d'améliorer son style (ou laissez-le justifier son style par rapport au nôtre ). C'est à cela que sert la révision du code. Tout code peut être reformaté rapidement, mais au moins les conventions de dénomination doivent être suivies. Mais ce n'est en aucun cas un drapeau rouge à louer. Ça ne devrait pas l'être.
Robert Koritnik
3

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.

pdr
la source
Dans mon cas, c'est souvent la seule chose que je vois du gars ...
WarrenFaith
@WarrenFaith - D'accord, mais vous n'allez jamais prendre la décision d'une seule main d'embaucher quelqu'un sur la base de si peu d'informations, n'est-ce pas? On vous demande juste un avis.
pdr
Vrai. Je donne mon avis du point de vue technique et les soft skills sont également importants. Et nous testons uniquement les gars qui ont au moins réussi le "test" de compétences non techniques dans l'interview. Mais je suis curieux de connaître l'impact que le style de codage devrait avoir sur mon opinion ...
WarrenFaith
@WarrenFaith - à votre place, je le mentionnerais, mais en tant que sidenote plutôt que quelque chose de très important.
pdr
Je fais simplement une liste des avantages et des inconvénients et je l'explique et la justifie pour notre CTO. La décision finale lui revient ...
WarrenFaith
3

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.

Victor Hurdugaci
la source
0

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.)

Treb
la source
Le problème qui vient avec un "mauvais style de codage" est souvent l'inexpérience. Quand je vois le plus de débutants, ils manquent souvent de tout ce qu'on pourrait appeler un style de codage.
WarrenFaith
?? "argument fort contre cette personne" ... "ne vous inquiétez pas vraiment du style de codage". Lequel est-ce? Est-ce important ou non? Il est difficile de dire à partir de la réponse quels sont vos conseils. Pourriez-vous clarifier, s'il vous plaît?
S.Lott
@ S.Lott: C'est quoi? - Bien sûr, les deux. Un mauvais style de codage est une mauvaise habitude, la plupart des gens peuvent apprendre à le perdre. C'est quand ils ne peuvent pas (ou ne veulent pas) apprendre que vous avez un problème.
Treb
0

À 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.

florianb
la source