Debe ser suavemente desalentado
..no es posible saber quién podrá ver el código fuente durante su vida útil.
Si bien es parte del trabajo frustrarse con un código particularmente complejo o antiguo y querer hablar mal de él, poner improperios / discursos / arte ASCII / chistes malos / comentarios ofensivos en el código fuente no es profesional y Mala idea en mi experiencia. A veces, el ingeniero que escribe los comentarios es ajeno a los posibles efectos que sus comentarios podrían tener. Estos son solo algunos de los problemas que he visto:
- Una gran cantidad de improperios en el código lanzado al público como código de código abierto / muestra.
- Chistes de mal gusto que causan una profunda ofensa a algunos miembros del equipo que resultan en un tribunal industrial.
- Los comentarios descartables que en realidad eran racistas / sexistas / de género causaron el despido de personas.
Si bien todos necesitamos tener algunos puntos de venta para la frustración / diversión / bromas, el código fuente no es el lugar para hacerlo, en mi opinión. No pondría improperios / chistes / comentarios ofensivos en un contrato, páginas de ayuda, planos u otro documento profesional, a pesar de que esos documentos pueden leerse incluso con menos frecuencia que el código fuente.
Si los líderes de equipo se ponen duros al respecto, habrá disgusto, por lo que digo 'desanimado gentilmente' por medio de una palabra tranquila con ingenieros de problemas y proporcioné mecanismos de ventilación adecuados para desahogarse, ya sea Facebook, mensajes instantáneos , air hockey o un saco de boxeo.
No es una defensa decir que los comentarios se compilan tampoco: ¿qué pasa con JavaScript o cualquier otro código dinámico del lado del cliente?
Estas son algunas de las experiencias del mundo real que he tenido que han moldeado mi opinión:
Mientras trabajaba en Microsoft, descubrí que un ingeniero de software no sabía la ortografía correcta de "no podía", echaba de menos la O, I y D, y había salpicado gran parte de su código con largas explicaciones de cómo no podía hacer que X funcione porque la persona Y estaba causando el problema Z. Su código era excelente; su ortografía no era tan buena. Baste decir que cualquier revisor posterior de este código (por ejemplo, yo) se alarmó al ver una gran cantidad de juramentos aleatorios en el código. Parte de este código pasó a mostrarse a los socios (escritores de controladores). Imagine su horror al ver los juramentos. Idealmente, los comentarios deberían haber sido dirigidos al gerente del proyecto en forma verbal (en cuyo caso, la persona Y podría ser arrastrada a la discusión) o tal vez enviar mensajes, pero no en la fuente.
En una empresa, un individuo que habla un idioma extranjero se unió a un equipo predominantemente de habla inglesa. Escribió comentarios en su idioma, pensando que nadie más podría leerlos. Esto estuvo bien, hasta que Babelfish / Google Translate lanzó una opción 'al inglés' para su idioma, momento en el que el resto del equipo tradujo algunos comentarios y se horrorizó por los comentarios sucios y a menudo despectivos que el tipo había estado haciendo sobre la compañía. , su equipo y una compañera de trabajo. Incómoda .
En otra compañía, un tipo realmente se sintió atraído por el arte ASCII y puso todo tipo de arte en su código fuente, sin ser visto (o quizás bendecido) por los revisores del código. Después de un tiempo, habitó en dragones, por alguna razón, generalmente con algún tipo de etiqueta. Más tarde, una persona galesa se unió al equipo. El emblema nacional de Gales es un dragón rojo, por lo que el nuevo chico inicialmente se mostró alegre con las imágenes, pero luego se ofendió cuando algunas de las tontas frases podrían interpretarse como ofensivas. Sí, se requiere cierta mediación del líder del equipo, pero esto no debería haber sucedido.
Nombres / detalles eliminados para proteger a los inocentes.