En primer lugar, adaptar mi estilo de codificación re: espacio en blanco. Hace mucho tiempo, un payaso escribió un artículo de broma sobre las mejores prácticas dando ejemplos de código con como 12 pestañas completas de espacios en blanco en todas partes que pudo; haciendo que el código sea imposible de leer sin una pantalla de 12 pies de ancho o con un tamaño de fuente .0001. Muchos programadores asumieron que era creíble y comenzaron a hacerlo, aunque obviamente no era una buena práctica. Me vuelve loco. Vamos chicos, digo, ustedes son más listos que eso. El 50% o más de espacio en blanco en la página de 240 columnas no tiene ningún sentido. Coloque la primera llave en la misma línea que la función o firma de clase (con un espacio o dos, no una pestaña o dos en el medio). Use 3 espacios para sangrar para los niveles de código (5 si tiene un miembro del equipo parcialmente ciego). Luego use una línea en blanco aquí y allá en el código para colocar las cosas en bloques lógicos más pequeños.
Aquí hay otro ejemplo de algo con cabeza de hueso. Primero te diré que esto no proviene de un medio ingenuo sin experiencia. Está en un código muy bueno de un tipo que pudo lograr que una técnica muy avanzada funcionara mientras que la mayoría del resto del mundo todavía se rasca la cabeza al respecto. Esto es lo que me frustra. ¿Por qué los buenos programadores son tan descarados acerca de formatear su código?
for (Iterator<Byte> iterator = collection.iterator(); iterator
.hasNext();) {
byteArray[i++] = iterator.next();
}
Ahora solo mira el formato de la condición for. Si realmente lo piensas, ¿no es ese un lugar completamente ilógico para poner un salto de línea? Por un lado, tenía mucho espacio para ver todo para ... {en una línea. (Afortunadamente, este tipo no usa múltiples pestañas para sangrar). Pero si no podía vivir sin dividirlo, ¿por qué hay en medio de una especificación de función? Hay un delimitador perfectamente bueno justo antes de eso, el punto y coma, que habría tenido más sentido como punto de quiebre. Mi voto es poner toda la condición y la apertura {(que va con el for) en la misma línea. También termina bien: es fácil hacer coincidir la llave de cierre con el "for" que se abrió. (A algunas personas, y herramientas (¿eso es redundante?), También les gusta poner eso en lugares extraños).
Segundo: tome nota del enfoque de la experiencia de cada programador y, si hay una diferencia significativa, asegúrese de que se refleje en qué parte del código trabaja cada programador. Un experto en control industrial en robótica, un ingeniero que trabaja principalmente en los complejos bits matemáticos y el tipo con el título de CS que se impresiona con la construcción de códigos totalmente oscuros (cuanto menos comprensible, más sofisticado parece, ¿verdad?) va a escribir el código de manera diferente. Donde existan estas diferencias significativas, divida el trabajo para que cada fortaleza individual coincida con el trabajo.
Cuando no haya tales diferencias, acuerde el estilo de codificación y, en cualquier caso, revisión de código, revisión de código, revisión de código. Francamente, he pasado por un montón de código de spaghetti descuidado en mi vida (12 veces más adelante en la depuración y los cambios realizados por el grupo de mantenimiento, o el resultado de la integración con ojos de gallo) y estaba en camino de ser un experto en el código después de 2 minutos de hablar con el último tipo que trabajó en él. (Nota al margen: de hecho, hay un punto en el que es mejor reescribir el código que continuar adaptándose).
Personalmente, también prefiero trabajar en casa solo. Nunca he conocido a un programador que prefiera o trabaje mejor en un cúbico rodeado de muchos otros programadores, debates e interrupciones. Pero hay que acostumbrarse a trabajar en equipo, y eso significa tomarse el tiempo para reunirse y discutir (no pelear) lo que está haciendo. Eso es en realidad parte del trabajo, realmente lo es. Mucho mejor aceptarlo y hacerlo de manera sistemática, eficiente y efectiva. Y mientras lo hacemos, también es parte del trabajo pasar tiempo transfiriendo conocimientos e información a las personas que escriben la documentación (algunas de las cuales puede que tenga que escribir usted mismo). Y cuando tenga la experiencia suficiente para aumentar su nivel de responsabilidad, incluso puede encontrarse chateando con más frecuencia con gerentes y personas en marketing, etc.
Codificar solo es un pasatiempo. La ingeniería profesional de software es una ocupación multifacética.