Sí, entiendo tu frustración con la tonta regla. He leído muchos programas con comentarios inútiles como
x = x + 1; // add 1 to x
¡Y me digo a mí mismo, así que ESO es lo que significa un signo más! Wow, gracias por decirme que no lo sabía.
Pero dicho eso, el cliente está pagando la factura. Por lo tanto, les das lo que quieren. Si trabajara en un concesionario de automóviles y un cliente dijera que quería una camioneta, no discutiría con él sobre si realmente necesita una camioneta y le preguntaría qué espera transportar. Le vendería una camioneta.
De acuerdo, hay momentos en que lo que los clientes dicen que quiere y lo que realmente necesita están tan separados que trato de discutir el asunto con él, tal vez convencerlo de que acepte algo más racional. A veces esto funciona, a veces no. Al final, si no puedo cambiar de opinión, le doy lo que quiere. Si regresa más tarde y dice: Oh, eso realmente no satisfizo los requisitos de mi negocio, entonces podemos cobrarle más por hacer lo que le dijimos que hiciera la primera vez. Cuánto puede negociar con el cliente depende de cuánto confía en su experiencia, cómo su contrato con usted encaja con la organización y, francamente, cuán tacaños son.
Sería un caso muy raro donde, suponiendo que fuera por mí, perdería un contrato porque pensaba que los requisitos estaban mal concebidos.
Tenga en cuenta que las personas con las que su empresa está negociando pueden ser o no las que inventaron esta regla del 25%. Podría ser una regla impuesta sobre ellos desde más arriba.
Veo cinco posibles respuestas:
Uno. Convencer a su jefe o al que esté negociando con el cliente para discutir sobre esto. Lo más probable es que esto no logre nada, pero puedes intentarlo.
Dos. Negarse a hacerlo. Esto probablemente lo despedirá, o si la compañía está de acuerdo con usted, hará que pierda el contrato. Esto parece improductivo.
Tres. Escriba comentarios inútiles para llenar espacio, el tipo de comentarios que simplemente repiten lo que está en el código y que cualquier programador capaz de modificar el código podría ver en 2 segundos. He visto muchos comentarios como este. Hace años trabajé para una empresa donde se nos exigía colocar bloques de comentarios delante de cada función que enumeraba los parámetros, como:
/*
GetFoo function
Parameters:
name: String, contains name
num: int, the number
add_date: date, the date added
Returns:
foo code: int
*/
int GetFoo(String name, int num, Date add_date)
La objeción de que tales comentarios son una carga de mantenimiento porque hay que mantenerlos actualizados no es válida. No es necesario mantenerlos actualizados porque ningún programador serio los mirará. Si hay alguna pregunta al respecto, asegúrese de dejar en claro a todos los miembros del equipo que los comentarios inútiles y redundantes deben ignorarse. Si desea saber cuáles son los parámetros de una función o qué hace una línea de código, lea el código, no mire los comentarios inútiles.
Cuatro. Si va a agregar comentarios redundantes sin valor, quizás valga la pena escribir un programa para generarlos. Algo de una inversión por adelantado, pero podría ahorrar un montón de tipeo en el futuro.
Cuando comencé en este negocio, una compañía para la que trabajaba utilizaba un programa que se anunciaba como "¡Escribe su documentación para usted! ¡Documentación completa para cada programa!" El sistema requería que le diéramos a todas las variables nombres esencialmente sin sentido y luego tener una tabla con un nombre significativo para cada variable, así que básicamente lo que hizo la "documentación automática" fue reemplazar el nombre sin sentido que nos obligó a usar con un nombre significativo. Entonces, por ejemplo, esto funcionó con COBOL, tendría una línea en su programa que decía
MOVE IA010 TO WS124
y generarían una línea de "documentación" que decía
COPY CUSTOMER NAME IN INPUT RECORD TO CUSTOMER-NAME IN WORKING STORAGE
De todos modos, uno seguramente podría escribir un programa para generar documentación igualmente inútil con bastante facilidad. Lee una línea como
a=b+c
y generar el comentario
// add b to c and save result in a
Etc.
Cinco. Haz lo mejor de la regla tonta. Intenta escribir comentarios útiles y significativos. Oye, podría ser un buen ejercicio.
Ah, por cierto, puedo agregar que siempre puedes jugar la métrica.
Recuerdo que una vez que un empleador dijo que iban a comenzar a medir la productividad de los programadores por la cantidad de líneas de código que producíamos por semana. Cuando nos dijeron esto en una reunión, dije: ¡Genial! Puedo aumentar mi puntaje fácilmente. No más escribir
x=x+4;
En cambio, escribiré:
x=x+1;
x=x+1;
x=x+1;
x=x+1;
Bucles? Olvídalo, copiaré y pegaré el código diez veces. Etc.
Entonces, si van a contar líneas de comentarios, haga cada línea corta y continúe con la idea en la siguiente línea. Si hay un cambio en los comentarios, no actualice el comentario existente. Ponga una fecha, luego copie todo el texto y escriba "Actualizado" y una nueva fecha. Si el cliente lo cuestiona, dígales que pensó que era necesario mantener el historial. Etcétera etcétera.