¿Qué tan importante es un buen estilo de codificación para la decisión de contratar a un programador? [cerrado]

15

Incluso como estudiante, se me pide que revise el código de los programadores que (no) pasaron una prueba (crear una lista de números de Fibonacci en Android).

Si bien soy muy estricto con el estilo de codificación, acabo de leer sobre el estilo de "bloque" que alguien usó (¡lea los comentarios!) .

En mi posición, recomendaría no contratar a un chico con este tipo de estilo. El código es completamente opuesto al estilo de codificación utilizado en mi empresa.

Mientras busco el estilo de codificación y cómo lidiar con la falta de él, tengo curiosidad por una cosa: ¿Debería contratar a un tipo que tengaproblema serio adaptando el estilo de codificación utilizado en la empresa?

Por favor: Esto no debería ser una discusión sobre el estilo de codificación en general y cuál es mejor. ¡Se trata de la importancia del estilo de codificación para la decisión de contratar a alguien!

Más información:

No soy el tipo que toma la decisión, solo doy mi opinión basada en el código. El chico tiene que pasar una entrevista donde nuestro jefe de lo que sea verifica las habilidades blandas. Si pasó esto, tiene que pasar nuestra pequeña prueba de habilidad y ahí es donde a veces me piden que revise el código escrito. No estoy en condiciones de decir sí o no. Solo quiero saber cuán importante debe ser el estilo de codificación para mi revisión ...

WarrenFe
fuente
99
Inteligente. En lugar de eliminar el "problema serio de adaptación" (que no está respaldado por los hechos), póngalo en una línea. Como si eso realmente cambiara la afirmación infundada sobre la actitud de otra persona.
S.Lott
2
El estilo de codificación es lo menos importante que debe preocuparle. Después de todo, es solo un código.
SK-logic
77
Estaba tratando de leer su pregunta, pero encontré que su formato era difícil de seguir. ¿Podría agregar una sangría inicial a sus párrafos? 'K THX BAI
dietbuddha 03 de
2
La consistencia del código (o la falta de ella) es un indicador. Por ejemplo, si alguien no tiene tiempo para organizar su código, probablemente tampoco tenga tiempo para averiguar el lugar correcto para comprometer un nuevo proyecto en subversion. Probablemente no tengan tiempo para refactorizar. La lista continua.
Kevin
10
El estilo de codificación es ridículamente fácil de ajustar. Esto es como preguntar "Esta persona usa trajes negros, pero en nuestra empresa preferimos que los empleados usen trajes gris oscuro. ¿Debería contratarlos?" Solo dígales las reglas de estilo que tiene en su empresa. Problema resuelto.
juicy lucy

Respuestas:

41

¿Cómo sabes que tendrá problemas para adaptarse? ¿Solo porque usan un estilo de codificación diferente? Eso es bastante presuntuoso. He sido contratista durante mucho tiempo, y no importa qué estilo de codificación se use, usted se adapta. Puede llevar algo de tiempo, pero los hábitos se forman bastante rápido.

Espero que al codificar el estilo no se refiera solo a la sangría y al diseño del código. Eso se trata fácilmente utilizando un formateador de código e integrándolo en su sistema de control de versiones.

Tomando el estilo de codificación en el sentido de nombres, ordenamiento general, separación de unidades y todo lo demás relacionado con la legibilidad y la facilidad de mantenimiento, lo más importante sobre el estilo de codificación es que tiene uno. No cual. No tener un estilo de codificación es una clara bandera roja.

La segunda cosa más importante sobre cualquier estilo de codificación que alguien use, es que lo usan de manera consistente. Cuando alguien parece usar un estilo de codificación, pero frecuentemente "peca" contra él, esa es otra señal de alerta.

Marjan Venema
fuente
55
+1 no tener uno, o no usarlo consistentemente son 'banderas rojas', tener un estilo diferente no lo es.
jv42
1
Estoy totalmente de acuerdo con el "al menos usarlo de manera consistente". Eso es lo más importante cuando reviso el código. Pero debes admitir que el estilo de código / formato de código es la primera impresión que obtienes cuando miras un código extranjero ...
WarrenFaith
3
@WarrenFaith: ¿entonces juzgas un libro por su portada? :-) Sin embargo, en serio, sí, da una primera impresión, pero supongo que al entrevistarlo se ocuparía de mirar más allá y no dejar pasar a un desarrollador perfectamente capaz solo porque su estilo actual no coincide con el suyo.
Marjan Venema
+1 por coherencia: la falta de estilo generalmente indica que no han escrito mucho. Cuando escribes, eliges hábitos.
Matthieu M.
1
Odio los formateadores de código automáticos, pero puedo aceptar la necesidad de ellos. Simplemente parecen elegir saltos de línea en todos los lugares equivocados. Sí, estoy hablando de eclipse.
Kevin
27

Después de haber programado en cientos de proyectos diferentes para casi un centenar de clientes diferentes, permítanme enfatizar un punto.

El estilo de codificación (y las disputas sobre el estilo de codificación) es una completa pérdida de tiempo.

Superalo.

He leído mucho código de muchos programadores diferentes. (Suponga un tamaño de equipo mediano de 5 y 100 equipos diferentes. Eso es 500 compañeros de trabajo.) El estilo no importa.

He visto código bonito pero patológicamente incorrecto.

[Hay un límite. La ofuscación intencional es motivo de terminación. Además de eso, el estilo es una pérdida de tiempo.]

El estilo de codificación es la "frontera final"

Si ha resuelto todos los problemas del desarrollo de software; si puede producir código libre de errores más o menos al instante; si su nivel de calidad es tan alto que ya no tiene una cola para corregir errores; si su usabilidad es tan fabulosa que ya no tiene una mesa de ayuda; si puede optimizar sin piedad hasta el punto en que no tiene una granja de servidores, pero ejecuta la empresa desde un iPad ...

Cuando no queda nada por arreglar, finalmente puede concentrarse en el estilo de codificación.

Hasta entonces, hay numerosos problemas que son más grandes y más valiosos que el estilo.

S.Lott
fuente
2
@WarrenFaith: No puedo decir esto con suficiente fuerza. No importa. Repetiré mi punto. He leído (profesionalmente, por pago, horas facturables) el código de cientos y cientos de programadores. No importa. No es la primera impresión: la corrección y la claridad son las primeras impresiones.
S.Lott
2
@WarrenFaith: la oscuridad intencional es rara. "si simplemente no puede leer el código" es algo que puede ser tanto un problema del lector como del escritor. Repetiré mi punto. He leído (profesionalmente, por pago, horas facturables) el código de cientos y cientos de programadores. "Simplemente no puedo leer" nunca ha sucedido. El estilo no importa.
S.Lott
2
El estilo de codificación (y las disputas sobre el estilo de codificación) es una completa pérdida de tiempo. - Estoy de acuerdo al 100% en el segundo punto, y alrededor del 40% en el primero. El estilo de codificación sí importa, si no hay ningún estilo en su codificación. Si es así, no importa mucho cómo se vea.
Treb
44
@WarrenFaith: He mirado la muestra y no veo nada allí que no esté claro. No está formateado como podría formatearlo, pero no hay nada allí que indique que el código no funcionará. No hay nada claro al respecto. No hay nada que sugiera que la persona que escribió no podría o no estaría dispuesta a cumplir con el estándar del equipo. @ S.Lott tiene razón. No importa.
Joel Etherton
44
Y usando //Importanten cada línea. Ejem. Cada línea de código es importante o debería eliminarse.
S.Lott
7

Juzgar a los programadores basados ​​en el estilo de codificación es 50% de esnobismo y 50% de inseguridad.

Me gusta que mi código se vea ordenado y limpio, y suena como el tipo que el OP hizo en el enlace también. Nuestro código no se ve igual, pero ambos usamos un estilo que nos ayuda a entender el código cuando volvemos a él. No tuve absolutamente ningún problema para comprender su código y dudo que el OP tampoco. El "consejo" de estilo de codificación no es más que un tiro fácil y barato donde puedes transmitir tu inmensa sabiduría sobre por qué las llaves deben estar en la próxima línea. No importa en absoluto. Lo que hace que el código sea difícil de leer es:

  • convenciones de nombres insanas (o falta de ellas) que no describen lo que representan.
  • flujo de programa loco que hace que sea difícil saber qué está sucediendo (ir a, probar / atrapar con lógica de negocios, etc.).
  • funciones increíblemente largas que hacen más cosas de las que el cerebro puede seguir.

Tengo problemas para imaginar cualquier código que no haga ninguna de las cosas enumeradas anteriormente, pero que aún sea difícil de leer, especialmente con una herramienta como Style Cop.

Morgan Herlocker
fuente
7

Es ridículo que el formato del código sea un factor al decidir contratar a alguien.

  1. Hay muchos factores más importantes a considerar.
  2. La mayoría de los desarrolladores pueden adaptar su estilo.
  3. Si el formato es tan importante, utilice un reformateador de código y un comprobador de pelusas.

No contratar a un buen desarrollador porque no agrega un espacio después de que una coma es una tontería.

dietbuddha
fuente
4

Supongo que tiene un estilo de formato oficial en la empresa.

Luego, haga que sea extremadamente fácil reformatear cualquier fuente al estilo oficial, y preferiblemente haga que ocurra automáticamente cada vez que se guarde el archivo fuente.

A cualquier programador que valga la pena le encantará esto porque garantiza una mayor calidad al minimizar las diferencias para los compromisos.


fuente
olvidé los problemas de confirmación ... y sí, tenemos un estilo de formateo oficial y también formateo automático antes de guardar.
WarrenFaith
@Warren, bueno, entonces dilo en la entrevista y asegúrate de que el programador entienda que esto es importante. Entonces depende de él cumplir su promesa si quiere mantener el trabajo.
4

Use StyleCop

Si está utilizando Visual Studio, siempre puede forzar las reglas de StyleCop con su compilación, lo que asegurará que su código sea al menos legible.

Rechazo el código ilegible, posiblemente de estilo no estándar , porque será muy difícil de mantener en el futuro, incluso por los propios autores. Esto ha sido probado muchas veces en el pasado.

Formato de código integrado CVS = solución óptima

Realmente sería genial si alguno de los CVS admitiera el formato de código automático en los registros. Acabas de establecer tus prioridades de estilo, el código se formateará antes de guardarlo. Eso haría obsoleto el estilo específico del desarrollador en términos de formato de código. Puedo ver el problema si algunos desarrolladores están usando diferentes caracteres de sangría. No es tan problemático para mí mirar un código diferente (y puedo formatearlo fácil y rápidamente), pero DIFF se vuelve más difícil de manejar. Muchos falsos positivos en la herramienta DIFF.

Robert Koritnik
fuente
Entonces ... si alguna empresa inventara sus propios estándares de codificación C #, ¿sería una señal de alerta?
Trabajo
1
@ Job: no necesariamente porque StyleCop permite agregar reglas adicionales. Sé que he escrito dos de ellos que imponen TABs sobre SPACE que no estaban allí en primer lugar. Pero la idea es que se puede forzar el estilo de codificación, lo que hará que sea mucho más fácil tener un código uniforme.
Robert Koritnik
¿Qué pasaría si su estilo volviera a ser el de StyleCop, y si no estuvieran utilizando StyleCop en absoluto, ¿sería entonces?
Trabajo
@Trabajo. A menos que alguien no escriba el código C # como si fuera el viejo Fortran (¿alguien tiene un diseño fijo de 80 columnas?), Sigo pensando que se puede pedir que se obedezca el estilo de codificación. Si alguien es un gran desarrollador, puede recordarles que mejoren su estilo (o dejar que justifiquen su estilo sobre el nuestro ). Para eso es la revisión de código. Cualquier código puede formatearse rápidamente, pero al menos se deben seguir las convenciones de nomenclatura. Pero de ninguna manera es una bandera roja de alquiler. No debe ser
Robert Koritnik
3

Muy por debajo de los siguientes detalles mucho más importantes:

  • Ajuste del equipo
  • Habilidades para resolver problemas
  • Comunicación

La mayoría de las personas que tienen los dos últimos mencionados pueden aprender los estilos de codificación.

Sin embargo, generalmente veo una muestra de código antes de la entrevista final, y si el estilo de codificación está muy lejos de lo que usamos, me enfocaré en preguntas que expongan su capacidad de adaptación.

pdr
fuente
En mi caso, su a menudo la única cosa que veo desde el chico ...
WarrenFaith
@WarrenFaith - Ok, pero nunca vas a tomar una decisión con una sola mano para contratar a alguien con tan poca información, ¿verdad? Solo te piden una opinión.
pdr
Cierto. Doy mi opinión desde el punto de vista técnico y las habilidades blandas también son importantes. Y solo probamos a chicos que al menos pasaron la "prueba" de habilidades blandas en la entrevista. Pero tengo curiosidad sobre el impacto que el estilo de codificación debería tener en mi opinión ...
WarrenFaith
@WarrenFaith: en su posición, lo mencionaría, pero como una nota al margen en lugar de algo de gran importancia.
pdr
Básicamente solo hago una lista de pro y contra y la explico y justifico para nuestro CTO. La decisión final depende de él ...
WarrenFaith
3

Mientras el estilo sea consistente y esa persona sea capaz de adaptarse (cambiar) a otro estilo, no veo ningún problema.

Si el estilo actual es diferente al que usa, no significa que sea malo. Para el candidato, podría tener todo el sentido.

Al igual que otros dijeron, tener problemas para adaptarse podría ser el único problema.

Victor Hurdugaci
fuente
0

No diría que esto definitivamente no es contratado, pero es un fuerte argumento en contra de esta persona.

En realidad, no me preocuparía el estilo de codificación, sino que esta incapacidad de adaptación sea un síntoma de un problema general. Temo que al candidato también le resulte difícil adaptarse a otros aspectos de la cultura del equipo.

Si no puede pensar en usar el estilo pascal en lugar de la envoltura estilo camello, entonces es muy posible que tenga problemas para recordar comenzar un nuevo lote de café si toma la última taza. Ese tipo de cosas puede ser realmente perjudicial para el equipo.

(Y sí, soy un adicto a la cafeína).

Treb
fuente
El problema que viene con un "mal estilo de codificación" es a menudo la inexperiencia. Cuando veo a la mayoría de los principiantes, a menudo les falta algo que pueda llamarse estilo de codificación.
WarrenFaith
?? "fuerte argumento en contra de esta persona" ... "en realidad no te preocupes por el estilo de codificación". Cual es ¿Importa o no? Por la respuesta, es difícil saber cuál es su consejo. ¿Podría aclarar, por favor?
S.Lott
@ S.Lott: ¿Cuál es? - Bueno, ambos por supuesto. El mal estilo de codificación es un mal hábito, la mayoría de las personas puede aprender a deshacerse de él. Es cuando no pueden (o no quieren) saber que tienes un problema.
Treb
0

En mi opinión, un buen estilo de código es esencial para que un programador trabaje con él.

Tener un buen estilo de código es una cuestión de desarrollo personal. Es un indicador de qué nivel ya alcanzó este programador.

La pregunta es si su empresa quiere "altos profesionales" o "altos potenciales". Si necesita "altos profesionales" y no hay espacio para aprender y evolucionar, el estilo de código es un criterio de exclusión.

Si hay espacio para la evolución y el desarrollo de programadores, será mejor que se preocupe por su capacidad de aprender rápido o pensar de forma creativa.

florianb
fuente