Embora eu seja um grande fã do Código Completo — é meu livro de programação mais recomendado por um bom motivo: há capítulos nele que eu não consegui digerir, mesmo depois de 16 anos.
Um desses capítulos descreve algo chamado Processo de Programação de Pseudocódigo. E, pelo menos no papel, parece bastante sensato. Antes de escrever uma rotina, o senhor descreve o que essa rotina deve fazer em inglês simples. Portanto, se quisermos escrever uma rotina de pesquisa de tratamento de erros, primeiro a escreveríamos em pseudocódigo:
set the default status to "fail" look up the message based on the error code if the error code is valid if doing interactive processing, display the error message interactively and declare success if doing command line processing, log the error message to the command line and declare success if the error code isn't valid, notify the user that an internal error has been detected return status information
Depois, quando estiver convencido de que entendeu o que a rotina deve fazer, transforme esse pseudocódigo em comentários que descrevam o código que está prestes a escrever.
// set the default status to "fail"
Status errorMessageStatus = Status_Failure;
// look up the message based on the error code
Message errorMessage = LookupErrorMessage( errorToReport );
// if the error code is valid
if ( errorMessage.ValidCode() ) {
// determine the processing method
ProcessingMethod errorProcessingMethod = CurrentProcessingMethod();
// if doing interactive processing, display the error message
// interactively and declare success
if ( errorProcessingMethod == ProcessingMethod_Interactive ) {
DisplayInteractiveMessage( errorMessage.Text() );
errorMessageStatus = Status_Success;
}
O pseudocódigo é mais ou menos como o Tang das linguagens de programação – o senhor hidrata o código em torno dele.
Mas por que pseudocódigo? Steve oferece algumas justificativas:
- O pseudocódigo facilita as revisões. O senhor pode analisar projetos detalhados sem examinar o código-fonte. O pseudocódigo facilita a revisão de projetos de baixo nível e reduz a necessidade de revisar o próprio código.
- O pseudocódigo suporta a ideia de refinamento iterativo. O senhor começa com um projeto de alto nível, refina o projeto para pseudocódigo e, em seguida, refina o pseudocódigo para código-fonte. Esse refinamento sucessivo em pequenas etapas permite que o senhor verifique o projeto à medida que o leva a níveis mais baixos de detalhes. O resultado é que o senhor detecta erros de alto nível no nível mais alto, erros de nível médio no nível intermediário e erros de baixo nível no nível mais baixo, antes que qualquer um deles se torne um problema ou contamine o trabalho em níveis mais detalhados.
- O pseudocódigo facilita as mudanças. Algumas linhas de pseudocódigo são mais fáceis de alterar do que uma página de código. O senhor prefere mudar uma linha em uma planta ou arrancar uma parede e pregar os pregos em outro lugar? Os efeitos não são tão dramáticos fisicamente no software, mas o princípio de alterar o produto quando ele é mais maleável é o mesmo. Uma das chaves para o sucesso de um projeto é detectar erros no “estágio de menor valor”, o estágio em que o menor esforço foi investido. Investiu-se muito menos no estágio de pseudocódigo do que após a codificação, os testes e a depuração completos, portanto, faz sentido, do ponto de vista econômico, detectar os erros logo no início.
- O pseudocódigo minimiza o esforço de comentários. No cenário típico de codificação, o senhor escreve o código e adiciona comentários depois. No PPP, as declarações de pseudocódigo se tornam os comentários, portanto, na verdade, é mais trabalhoso remover os comentários do que deixá-los.
- O pseudocódigo é mais fácil de manter do que outras formas de documentação de design. Com outras abordagens, o design é separado do código e, quando um deles é alterado, os dois não estão de acordo. Com o PPP, as declarações de pseudocódigo tornam-se comentários no código. Desde que os comentários em linha sejam mantidos, a documentação do pseudocódigo do design será precisa.
Todos argumentos convincentes. Como acólito de McConnell, é doloroso admitir isso, mas toda vez que experimentei o Processo de Programação de Pseudocódigo, quase imediatamente o abandonei por considerá-lo impraticável.
Por quê? Por dois motivos:
- código > pseudocódigo. Para mim, é mais fácil pensar em código em código. Embora eu seja totalmente a favor de descrever o objetivo geral da rotina antes de escrevê-la em inglês simples, isso ajuda a nomeá-la, que é incrivelmente difícil — estender isso dentro da rotina não funciona bem para mim. Há algo fundamentalmente… irrealista… na tentativa de usar um inglês preciso para descrever as porcas e os parafusos do código.
- Começar com o objetivo de adicionar comentários ao seu código parece retrógrado. Eu prefiro codificação sem comentários, pois quero que o código seja tão autoexplicativo quanto humanamente possível. Não me entenda mal; os comentários ocorrem regularmente em meu código, mas somente porque o código não poderia ser mais claro sem eles. Os comentários devem ser um método de último recurso, não algo com que o senhor começa.
É claro que o PPP é apenas uma maneira proposta de codificar, não a maneira perfeita ou ideal. McConnell não tem ilusões sobre isso e reconhece que a refatoração, o TDD, o design por contrato e até mesmo o velho e simples “hacking” são formas válidas e alternativas de construir código.
Mas, ainda assim, é difícil para mim ver o pseudocódigo como útil em qualquer coisa que não seja possivelmente em entrevistas de emprego. E, mesmo assim, prefiro sentar na frente de um computador e escrever código real para resolver o problema que está sendo apresentado. Qual é a opinião do senhor? O pseudocódigo é uma ferramenta útil em sua programação? O senhor escreve pseudocódigo antes de escrever código?