I want to force people to read the code. I hate debuggers for a
similar reason. They are too convenient and allow you to step through
dirty code with watches and breakpoints and find the so-called
problem, when the real problem was that there are bugs in the code
because the code has not been simplified enough.
Seu programador sênior parece ter um problema compreensível sobre o estilo de codificação . Ele está errado em como ele resolve o problema, no entanto.
Ambos comentários e codificação descritiva são essenciais: código bem escrito com nomes descritivos informa rapidamente o código ; mas os comentários informam o que o código deve fazer (e por que não, por que ele faz isso de uma forma e não de outra . Então você tem testes de unidade para verificar se o "contrato "(o que o código deveria ter feito ) foi realmente cumprido e feito automaticamente, com frequência e sem nenhum esforço adicional da sua parte.
Sem os comentários, levaria muito tempo (ou um teste de unidade, que neste momento eu suspeito que seu chefe goste menos do que os comentários, se ele acreditar que " bugs foram pegos por pessoas lendo código ) antes de encontrar o erro:
// Multiply margin by a fixed amount.
page->margin += fixedMargin;
e, sim, o comentário pode estar errado, mas agora você sabe que em uma dessas duas linhas há um erro . Isso, além de outro recurso útil, controle de versão , permite que você encontre a discrepância em menos de 30 segundos. Verificar a saída e até mesmo avançar com um depurador pode não ser (um valor de fixedMargin de cerca de 1.01 pode fornecer resultados ambíguos, por exemplo).
Se o seu mentor está atrás da simplicidade (eu concordo com ele que é um traço desejável), ele deve implementar alguma maneira de verificar métricas como e estabelecimento de metas métricas. Isso vale para comentários também: eu concordo que não faz sentido documentar cada linha de código, mas você deve se esforçar para cobrir módulos, funções e qualquer "ponto WTF" no código.
// Useless comment: multiply a by four
// Useful comment (even if maybe it shouldn't be in this exact point of code):
// Zooming 2:1, four pixels get mapped into one, divisor needs multiplying by four
a *= 4;
Seu método pode dar resultados - caso ele odeie, você terá 20% de codificação e 80% de documentação e teste. Com esse método, você obtém 20% de codificação e 80% de depuração e scratching de cabeça.
A diferença entre os dois casos é, na minha opinião, na moral das pessoas e na produtividade geral. Se você documentar e simular corretamente funções e módulos, um módulo pode ser implementado por alguém que não precisa conhecer a visão geral , não precisa estudar efeitos colaterais em um cenário de caixa preta e o objetivo da linha inferior, pode ser menos experiente .
Seu mentor aparentemente está confortável com uma quantia espantosa de dívida técnica . Eu verificaria as estatísticas dele sobre o escorregamento de prazo e / ou ETAs; a menos que um milagre, qualquer projeto de longa duração que não seja mantido por uma banda de um homem só ou por um grupo de colegas de codificação é devido a uma dívida técnica chamada mais cedo ou mais tarde.