formatting - google - java code conventions en español
¿Es importante el estilo de programación? ¿Que tan importante? (30)
Absolutamente, el estilo es importante. Especialmente cuando se trata de cosas como sangría y espacios en blanco. El código debe ser fácilmente legible por una persona, ya que es una persona que debe mantener ese código más adelante. Cuanto más legible sea el código, más fácil será mantenerlo y más alta será la calidad de ese código.
Hay un factor psicológico que viene a jugar con el estilo del código. Cuando el código es "feo" y es difícil de leer / entender, usted quiere tomar menos posesión de ese código, por lo que hay menos incentivo personal para hacer su mejor trabajo. A medida que el código se vuelve más legible / fácil de entender, se siente mejor acerca del trabajo que ha realizado y desea hacerse con más propiedad. Cuanta más propiedad tenga el código, más importante será escribir un mejor código.
En cuanto a cómo respondió Microsoft, habría respondido exactamente de la misma manera. Creo que su respuesta de no devolverle la llamada probablemente esté perfectamente justificada (y puede haber otros factores aparte de la falta de estilo de código, aunque estoy seguro de que fue un colaborador).
El año pasado estaba solucionando el problema del código de un miembro del equipo y me faltaban guiones y comentarios. Estaba hablando con él sobre eso diciéndole que no era una buena idea, pero se ofendió. Él era / es más inteligente que yo o ciertamente más educado.
Desde entonces me enteré de que solicitó a Microsoft y cuando le pidieron que realizara una implementación de la lista doblemente enlazada, la escribió sin sangrías ni comentarios, afirmando que no tenía tiempo para preocuparse por el estilo. (Fue un envío de correo electrónico por el que hubo 2 horas para completar)
Microsoft no lo devolvió ... ¿Cómo crees que respondieron? ¿Cómo responderías?
¿Alguien de Microsoft aquí puede sugerir qué harían en este caso?
Bueno, el hecho es que la fase del ciclo de vida del software en la que vive más tiempo es el mantenimiento. Durante ese tiempo, la mayoría de las personas lo leen y analizan tratando de arreglarlo, reutilizarlo, mejorarlo, etc. Esa es la mejor razón para mantenerlo legible y extensible. Alguien que dice que no tiene tiempo para preocuparse por el estilo, que explícitamente influye en la legibilidad, muestra solo su inmadurez como ingeniero de software. O tal vez simplemente no entiende el ciclo de vida del software.
El código lo leen tres entidades: la computadora, el programador y, en última instancia, el mantenedor.
El estilo y el formato son irrelevantes para la computadora, posiblemente importantes para el programador, pero sin duda son importantes para el mantenedor, quien debe tratar de comprender la funcionalidad del programa.
Negarse a acomodar a otros desarrolladores haciendo que el código sea legible es irrespetuoso.
Crear código organizado con nombres de variables y comentarios significativos es una forma de cortesía común para cualquier persona que lo lea.
El estilo de codificación es bastante importante. La mayoría de las principales compañías de desarrollo tienen un documento que define las convenciones de nomenclatura requeridas, las pautas para comentar y otras pequeñas cosas que hacer con el estilo del código y las pautas de arquitectura.
Todo lo cual es muy bueno y ayuda a promover un entorno de trabajo en el que los miembros del equipo pueden tener buenas expectativas de cómo se verá el código de sus colegas.
Solo asegúrate de que no llegue al nivel de un gerente que obligue a un desarrollador a realizar un cambio en una revisión de código de algo como esto:
if( someBool() ) doSomething();
else doNothing();
Para algo como esto simplemente porque "sienten" que es el "mejor" estilo:
if( someBool() )
{
doSomething();
}
else
{
doNothing();
}
Solo por favor tenga razones mejores que la preferencia personal por los requisitos de estilo y todos podemos ser más felices.
El estilo de programación es muy importante. Comentarios aún más. Incluso si trabaja solo, en su propio proyecto, debe comentar su código, porque un mes después no recordará lo que hizo y por qué. Y si trabaja en equipo, un código poco claro, sin formatear y sin comentario puede causar un desastre.
El formateo no toma ningún tiempo en absoluto. Es una excusa horrible. Simplemente deja que tu editor lo formatee cuando hayas terminado por el psicópata violento.
En mi opinión, decir que el estilo no es importante es como decir que la ortografía no es importante. Si su estilo (o falta de estilo) está causando problemas de legibilidad, entonces será difícil para un equipo trabajar con los archivos que esta persona está escribiendo / editando.
De forma similar, si un programador no se toma el tiempo de deletrear palabras correctamente en bloques de comentarios, nombres de funciones, etc. ... causará problemas con otros desarrolladores que intenten descifrar el código. Siempre me pregunto a mí mismo, "sí, si miras esto en 1 semana, ¿lo entenderás? Si lo miras el próximo año, ¿lo entenderás?" (o al menos, puede leer documentación / comentarios para refrescar su memoria).
Para mí, el estilo no es importante cuando estás hablando de colocar el corchete en la siguiente línea de tu bloque if en lugar de ponerlo al final del enunciado condicional ... siempre que cumpla con tus estándares de codificación, es internamente consistente , y el resto del equipo usa el mismo enfoque; Dicho esto, creo que el estilo es extremadamente importante si afecta la legibilidad del código.
Dado que MS es una empresa tan grande, probablemente estén buscando a alguien que pueda resolver problemas y también sea un jugador de equipo. Alguien que dice que "no tiene tiempo para peinar" me parece que no es un jugador de equipo.
¡Buena pregunta!
En una entrevista, está perfectamente bien no sangrar ni comentar su código. De hecho, me sorprendería si tuvieras tiempo para hacer eso, normalmente no damos tanto tiempo.
Sin embargo, como práctica general, espero que sangren su código y agreguen comentarios cuando sea necesario. De hecho, nuestra máquina de compilación fallará en cosas diminutas como incluir pestañas en lugar de espacios en su código.
La legibilidad del código es importante. Al igual que a nadie le gusta leer un párrafo grande (en lugar de párrafos pequeños y estructurados), a nadie le gusta leer un gran trozo de código sin formato.
Encuentro difícil de creer que alguien piense que no hay sangrado es una buena idea. Es tonto, yo tampoco lo devolvería si hiciera eso por mí en una entrevista.
Los comentarios son un poco más grises, el gran código se auto documenta en gran medida. SI escribe un gran código, los comentarios solo deberían ser pequeños en lugares donde lo que está ocurriendo es realmente complejo y difícil de seguir.
Estilo que el énfasis en la legibilidad es importante. Extremadamente importante.
Muchos programadores discuten sobre la frecuencia y el uso de comentarios, pero la mayoría argumenta que son necesarios.
Hay otra razón por la cual el estilo del código es importante. Puede actuar como un proxy para determinar el profesionalismo de un programador. Así como las plumas de la cola de un pavo real demuestran su salud y virilidad (un organismo no saludable no podría dedicar recursos escasos a la construcción de una cola afelpada), el estilo de un programa puede revelar mucho sobre la persona que lo escribió.
Cuando veo un código mal formateado con convenciones de nomenclatura inconsistentes y comentarios escasos, me alejo de él no solo porque ese código es intrínsecamente ilegible, sino también porque es bastante probable que el código albergue problemas aún peores debajo de esta superficie problemática.
Hay pocas excusas para no comentar y ninguna para no sangrar. La mayoría de los mejores editores manejan las sangrías y los comentarios deben ser una segunda naturaleza para alguien a quien la MS le gustaría contratar.
Ciertamente, ambas son disciplinas en las que las personas se involucran (ya sea de forma natural o mediante la escolarización), por lo que si no muestran ninguna de ellas, tal vez muestre falta de disciplina o, al menos, esfuerzo para expresarla.
Editar: ¡2 horas para una lista enlazada! Veo que quiso decir ahora ... ¡Encajar todo ese formato en la hora restante, cincuenta minutos habría sido bastante difícil! (Estoy jugando solo, ¡supongo que había más en la entrevista que una lista vinculada!)
La programación sin identificación y un estilo legible es como escribir un libro sin párrafos y saltos de página. Es solo un montón de texto y nunca me tomaría el tiempo para entenderlo.
Entiendo completamente la reacción de Microsoft, no lo llamaría también.
Me gustaría saber cómo cualquier programador decente podría escribir código sin sangría, ya sea que se haga en un IDE, vi, Notepad, en una pizarra o en un post-it. Sangría el código debe venir de forma natural. No volvería a llamarlo si lo que entregó se parecía a esto (estoy copiando la implementación de Wikipedia, el foco está en la falta de sangría):
struct Node{
data
next
prev
}
struct List{
Node firstNode
Node lastNode
}
function insertAfter(List list, Node node, Node newNode) {
newNode.prev := node
newNode.next := node.next
if node.next = null
list.lastNode := newNode
else
node.next.prev := newNode
node.next := newNode
}
function insertBefore(List list, Node node, Node newNode) {
newNode.prev := node.prev
newNode.next := node
if node.prev is null
list.firstNode := newNode
else
node.prev.next := newNode
node.prev := newNode
}
function remove(List list, Node node){
if node.prev = null
list.firstNode := node.next
else
node.prev.next := node.next
if node.next = null
list.lastNode := node.prev
else
node.next.prev := node.prev
destroy node
}
No me importaría que no hiciera comentarios de inmediato. Pero la sangría es importante. Cuando escribes código, rara vez aparece linealmente en un ataque de frenesí de mecanografía.
No, incluso antes de probar y posiblemente depurar el código, generalmente hay mucha edición y poder ver claramente la estructura del código es importante.
Esto me recuerda un incidente que ocurrió al principio de mi carrera. Yo era un programador de nivel junior y otro programador junior me pidió ayuda con su código. Estábamos usando Pascal en ese momento. Su código era un desastre. He visto código sin sangría antes, pero nunca he visto código con indentación aleatoria. No había forma de seguirlo.
Entonces, lo primero que hice fue arreglar la sangría. Él dijo engreído. "¡No creo que eso lo arregle!". Volví a mirar el código. El error ahora era fácil de detectar, así que solo lo señalé y me alejé.
Puede argumentar que el código bien escrito no necesita comentarios, o al menos muy pocos comentarios. Pero la falta de sangrado no es aceptable. Al compilador le importa (en la mayoría de los casos), pero las personas que mantienen el código lo hacen.
Si dedica más tiempo a sangrar el código que a escribirlo, podría ser un problema. Pero el estilo del código fuente, las convenciones y la coherencia en toda la solución son importantes.
Es por eso que confío en una herramienta para hacer eso. Resharper me permite volver a formatear todo mi código presionando Ctrl + F, combinación de teclas E.
Siempre he pensado que lo único con lo que puedes contar es que las personas que miran tu código después de que te hayas ido pensarán que eres un idiota. La clave es maximizar el tiempo entre la primera vez que se ve el código y cuándo se toma esa determinación.
Un buen formato es una forma de aumentar N, los comentarios útiles son otro.
Sobre "estilo" (que prefiero llamar "formateo"): es en gran medida una cuestión de gusto personal, pero trabajar en equipo es muy importante para definir algunas pautas que TODOS deben seguir, doblando sus preferencias personales si es necesario (en Eclipse exportamos la configuración del formateador y con una pulsación de tecla obtenemos el archivo formateado). Muy pronto todos se acostumbrarán al estándar y el código de lectura será menos fatigoso.
Acerca de los comentarios: prefiero un buen nombre para mis métodos, pero un comentario sobre dos de las partes más oscuras es obligatorio.
Todo es una cuestión de quién es la audiencia prevista del código fuente. La respuesta correcta es "otros programadores" (mantenedores, etc.). Su colega pensó que no era importante y entiendo completamente por qué la EM no lo contrató. ¡Me sorprendería si alguna gran compañía lo contratara!
Recuerdo un viejo artículo titulado "El estilo tipográfico es más que cosmético " aparecido en "Comunicaciones de ACM" que hizo experimentos sobre el impacto del código de buen formato en la productividad.
Tomaron un grupo de programadores y les dieron una prueba para clasificarlos. Luego dividieron el grupo en dos, los dos grupos, la misma tarea: modificar una pieza de software para agregar alguna funcionalidad.
Solo que el primer grupo obtuvo un código fuente muy bien formateado para trabajar y los otros tenían una versión bastante desordenada del mismo código.
Midieron su productividad de nuevo y el resultado final fue que el peor programador del primer grupo obtuvo mejores resultados que el programador BETTER del segundo grupo.
Desde entonces, siempre puse un esfuerzo extra para hacer que mi código fuera claro para otros humanos.
Para aquellos interesados en el tema, sugiero leer sobre programación alfabetizada, programación intencional y otros conceptos relacionados.
Tu amigo necesita tener sus prioridades correctas, y en mi opinión, creo que a Microsoft le importaría más de lo que parece pensar que lo haría.
Un desarrollador al que no le importa el estilo es como un artista, un pintor, a quien no le importa el color.
El estilo de programación es muy importante. El código limpio satisface la vista y mejora el mantenimiento del programa. Por lo tanto, está directamente relacionado con la calidad y la arquitectura del programa en sí.
Incluso en un lenguaje que fuerza la sangría uno puede realmente romper todo con mal estilo. El estilo incorrecto puede no ser, por lo tanto, falta de sangrado o comentarios. En realidad, rara vez uso comentarios, prefiero los documentos y, en general, escribir mejor documentación. Asocio los comentarios a pequeñas notas que distribuyes en todo el código si realmente ves que hay algo para arreglar o para preguntar por ahí.
Prefiero ver el estilo malo como no permitir que el lenguaje de programación haga algunas de tus cosas por ti. La macro correcta y bien escrita en un lugar o dos es realmente un buen estilo en lugar de malo.
Intentaría halagarlo, decirle que, debido a que puede hacer cosas más complejas que otros programadores, necesita comentarlo y exponerlo bien para que el resto de nosotros lo pueda entender.
Creo que si alguien me demostrara ese tipo de actitud en una entrevista, pensaría cuidadosamente sobre contratarlo. Estoy seguro de que incluso Microsoft quiere jugadores de equipo.
Esta es la razón por la cual se necesitan estándares de codificación. El equipo debe cumplir con los estándares incluso si no es así como normalmente codifican. Podría aprender mucho por mantener el lío de otra persona, como lo que tengo. 7000 líneas de escritura en C ++ en estilo C se dividen en 7 métodos (la mayoría de los métodos son más de 600 líneas), muchas macros de una línea que contienen gotos a etiquetas dentro de los métodos. También hay muchas sentencias line if y macros añadidas al final de estas y otras llamadas a métodos que no verá porque tiene que desplazarse para verlas. Añádelo a los terribles nombres de las variables y al estilo de horquillado incoherente y obtendrá un caos inmanejable. Lo positivo es que funciona bien y hemos confiado en él durante años.
Lo despediría, pero afortunadamente, nunca sería contratado.
Preferiría que pasara dos horas escribiendo un código limpio y casi funcional, que para él dar un golpecito a algo que funcione.
El estilo de programación es importante, especialmente cuando se trabaja en equipo.
Se vuelve crítico cuando se soportan aplicaciones heredadas, escritas por varias personas.
Parte de ser un profesional, y no solo un script-kiddie, es preocuparse por el código. Se trata de darse cuenta de que alguien más leerá este código (¡quizás incluso tú!) Dentro de seis meses. Por lo tanto, debe hacer que sea lo más fácil posible de mantener.
"No tuvo tiempo de preocuparse por el estilo ..." No es de extrañar que no lo llamaran. ¿Ni siquiera llegó a la entrevista cara a cara y ya se niega a hacer lo que se le pide? Esa es una buena manera de no pasar una entrevista para ninguna profesión.
El estilo es inherente a todo lo que hacemos. No es una superposición. No es un complemento. No es un beneficio. Existe ya sea que lo usemos o no. Cosas - programas, productos, lo que tiene - no se mejoran por estilo; se mejoran al tener un BUEN estilo (lo contrario es simplemente tener un mal estilo).
El problema con las personas que vienen desde un punto de vista muy técnico es que si no se equilibra con ningún interés o apreciación estética, se asume que el "estilo" es una herramienta que los programadores no usan; "estilo" significa "dejarlo en la interfaz de usuario o comercializar chicos". Simplemente no es verdad. Al esforzarte al máximo en lo que haces, debes mejorar todos los aspectos del trabajo. Eso significa no solo la ejecución, sino la presentación.
Los humanos son seres orientados a la vista. Elegimos cosas según su aspecto (¡Chica guapa! ¡Paquete brillante!).
Al anunciar claramente que no tenía tiempo para el estilo, básicamente daba la impresión de que no era el paquete brillante que Microsoft estaba buscando. Y a través de una pre-disculpa tan obvia, también hizo que su falta de guiones y comentarios fueran más evidentes para el evaluador (aunque estoy seguro de que no lo habrían contratado por su falta de comentarios).
Bueno, hay vida, y luego hay entrevistas.
Pregúntale a tu amigo: ¿aparecería en la entrevista con unos vaqueros raídos y una camiseta sucia?
Su tarea en la entrevista (sin importar el formato) es impresionar a la persona que realiza la entrevista. Impresionelos lo suficiente como para que les ofrezcan un trabajo.
Entonces, si se está postulando para un trabajo de programador, ¿por qué en el mundo este tipo presentaría un código de "jeans andrajosos y camisetas mugrientas"?
Realmente espero que esta persona tenga alguna pista sobre el estilo de codificación, los comentarios y el espacio en blanco. En ese caso, hizo la llamada de juicio de que el entrevistador estaba más preocupado por la "corrección" que por la "bondad" (mi interpretación).
PERO - dada la tarea (lista enlazada, esto debería ser fácil para un programador), parecería que la tarea es mucho más que solo la "corrección" del código.
Sospecho que el entrevistador buscaba muchas cosas, INCLUYENDO una buena práctica de codificación (es 1000 veces más difícil "desaprender" las malas prácticas de programación que tenerlas al principio). El entrevistador probablemente también estaba buscando algo que indicara iniciativa, buenas suposiciones, tal vez incluso creatividad o inventiva.
Por ejemplo, hay muchas maneras de escribir una lista vinculada que son "correctas", pero algunas (como el uso de la recursividad) se consideran más "elegantes" que otras.
Sospecho que tu amigo se perdió la marca en varios niveles en esta entrevista.
-R
Se dice que el 80% de la vida útil de un proyecto se gasta en mantenimiento. Si tu código es ilegible, estás perdiendo mucho tiempo por quienquiera que esté manteniendo tu código, e inevitablemente, harás que piensen mal de ti.
Sin embargo, por lo que he visto, la mayoría de los equipos de programadores (o incluso de una empresa completa, a veces) tienen un documento o algo que explica las convenciones y los estilos del código a los que se adhieren. Por lo tanto, es bastante fácil en su primer día de trabajo allí ingresar sus reglas en su IDE y simplemente hacer que formatee automáticamente su código para que no tenga que preocuparse por ello. Incluso mejor, probablemente pueda encontrar a alguien que esté dispuesto a "exportar" su archivo de preferencias, por lo que solo es cuestión de unos pocos clics hasta que todo el código que escriba en esa empresa tenga el formato perfecto.
Dicho esto, no siempre tendrá acceso a estas convenciones específicas de equipo (por ejemplo, en una entrevista). Siempre es una buena idea seguir algunas convenciones básicas que tengan sentido. Dependiendo de su idioma, una buena idea sería Google " sus convenciones de código de idioma" y leer sobre los conceptos básicos. Lo importante en la situación de la entrevista es que sigas algunas pautas básicas y tengas un estilo de formato al que te apegues. Si hace el paréntesis después de una declaración "else" en la misma línea una vez y la escribe en la siguiente línea en otro momento, probablemente le está diciendo al entrevistador que realmente no le importa lo suficiente y / o que no tiene suficiente experimentar que una forma se ha convertido en un hábito para ti.
Ningún programador es una isla. Alguien tendrá que leer su código un día. Se ha repetido aquí muchas veces antes:
Siempre codifique como si el tipo que termina manteniendo su código será un psicópata violento que sabe dónde vive. - Martin Golding (tal vez)
Dicho esto, si su estilo es adecuado, hay otras cosas mucho más importantes que evaluar al contratar a un programador. Pero si se niegan rotundamente a utilizar comentarios o intentan hacer que su código sea legible para otros, es un factor decisivo.