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 ...
fuente
Respuestas:
¿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.
fuente
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.
fuente
//Importanten cada línea. Ejem. Cada línea de código es importante o debería eliminarse.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:
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.
fuente
Es ridículo que el formato del código sea un factor al decidir contratar a alguien.
No contratar a un buen desarrollador porque no agrega un espacio después de que una coma es una tontería.
fuente
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
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.
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.
fuente
Muy por debajo de los siguientes detalles mucho más importantes:
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.
fuente
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.
fuente
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).
fuente
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.
fuente