Sim, entendo sua frustração com a regra boba. Eu li muitos programas com comentários inúteis, como
x = x + 1; // add 1 to x
E digo para mim mesmo: Então, isso é o que significa um sinal de mais !! Uau, obrigado por me dizer, eu não sabia disso.
Mas dito isso, o cliente está pagando a conta. Portanto, você dá a eles o que eles querem. Se eu trabalhasse em uma concessionária de carros e um cliente dissesse que queria uma caminhonete, eu não discutiria com ele sobre se ele realmente precisa de uma caminhonete e o questionaria sobre o que ele espera transportar nela. Eu venderia uma caminhonete para ele.
Ok, há momentos em que o que os clientes dizem que ele quer e o que ele realmente precisa estão tão distantes que eu tento discutir o assunto com ele, talvez o convença a concordar com algo mais racional. Às vezes isso funciona, às vezes não. No final, se não consigo mudar de idéia, dou o que ele quer. Se ele voltar mais tarde e disser: Ah, isso realmente não atendeu aos meus requisitos de negócios, poderemos cobrar mais dele pelo que dissemos a ele na primeira vez. O quanto você pode negociar com o cliente depende de quanto eles confiam nos seus conhecimentos, como o contrato deles com você se encaixa na organização e, francamente, como eles são tímidos.
Seria um caso muito raro em que, assumindo que dependesse de mim, eu perderia um contrato porque achava que os requisitos eram mal concebidos.
Lembre-se de que as pessoas com quem sua empresa está negociando podem ou não ser quem inventou essa regra de 25%. Poderia ser uma regra imposta a eles de cima para baixo.
Eu vejo cinco respostas possíveis:
1. Convença seu chefe ou quem está negociando com o cliente a discutir sobre isso. As probabilidades são de que isso não fará nada, mas você pode tentar.
Dois. Recuse-se a fazê-lo. Provavelmente, você será demitido ou, se a empresa concordar com você, fará com que você perca o contrato. Isso parece improdutivo.
Três. Escreva comentários inúteis para preencher o espaço, o tipo de comentários que apenas repete o que está no código e que qualquer programador capaz de modificar o código poderá ver em 2 segundos. Já vi muitos comentários como esse. Anos atrás, trabalhei para uma empresa na qual fomos obrigados a colocar blocos de comentários na frente de todas as funções que listavam os 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)
A objeção de que esses comentários são um ônus de manutenção porque você precisa mantê-los atualizados não é válida. Não há necessidade de mantê-los atualizados, porque nenhum programador sério jamais os olhará. Se houver alguma dúvida sobre isso, deixe claro para todos os membros da equipe que os comentários inúteis e redundantes devem ser ignorados. Se você quiser saber quais são os parâmetros de uma função ou o que uma linha de código faz, leia o código, não veja os comentários inúteis.
Quatro Se você quiser adicionar comentários inúteis redundantes, talvez valha a pena escrever um programa para gerá-los. Algo como um investimento adiantado, mas poderia economizar um monte de digitação no caminho.
Quando comecei neste negócio, uma empresa na qual trabalhei usava um programa anunciado como "Grava sua documentação para você! Documentação completa para cada programa!" O sistema exigia que atribuíssemos a todas as variáveis nomes essencialmente sem sentido e, em seguida, tivéssemos uma tabela fornecendo um nome significativo para cada variável, então basicamente o que a "documentação automática" substituiu o nome sem sentido que nos forçou a usar com um nome com significado. Por exemplo - isso funcionou com o COBOL - você teria uma linha no seu programa que dizia
MOVE IA010 TO WS124
e eles gerariam uma linha de "documentação" que dizia
COPY CUSTOMER NAME IN INPUT RECORD TO CUSTOMER-NAME IN WORKING STORAGE
De qualquer forma, alguém poderia certamente escrever um programa para gerar documentação igualmente inútil com bastante facilidade. Leia uma linha como
a=b+c
e gere o comentário
// add b to c and save result in a
Etc.
Cinco. Faça o melhor da regra boba. Tente escrever comentários úteis e significativos. Ei, poderia ser um bom exercício.
Ah, a propósito, devo acrescentar que você sempre pode jogar a métrica.
Lembro-me de uma vez que um empregador disse que começaria a medir a produtividade dos programadores por quantas linhas de código produzíamos por semana. Quando nos disseram isso em uma reunião, eu disse: Ótimo! Eu posso facilmente aumentar minha pontuação. Não há mais escrita
x=x+4;
Em vez disso, vou escrever:
x=x+1;
x=x+1;
x=x+1;
x=x+1;
Rotações? Esqueça, vou copiar e colar o código dez vezes. Etc.
Então aqui, se eles vão contar linhas de comentários, reduza cada linha e continue com a ideia na próxima linha. Se houver uma alteração no que está nos comentários, não atualize o comentário existente. Coloque uma data, copie o texto inteiro e escreva "Atualizado" e uma nova data. Se o cliente questionar, diga que você achou necessário manter o histórico. Etc etc.