Design Paterns na POG

Nos últimos meses andei dando manutenção em vários programas antigos. Embora não tenha encontrado muitos exemplos dignos do Worse Than Failure, de vez em quando um trecho fica atravessado na garganta.

Aviso: o post a seguir é irônico, quem preferir um texto mais sério dê uma olhada aqui.

Para felicidade de muitos e desespero de um grupo cada vez menor, a POG (Programação Orientada a Gambiarras) vem ganhando cada vez mais adeptos. Embora um dos pilares da POG seja o improviso, é possível detectar uma série de padrões de projeto nas criações dos praticantes desta metodologia.

Seguindo uma tradição não oficial da POG, os exemplos serão apresentados em Visual Basic (que muito consideram a linguagem perfeita para a POG). Seguindo outra tradição, os exemplos não forma testados e nenhuma referência foi consultada.

Constantes

As constantes devem ser preferialmente colocadas diretamente no código. Para maior otimização, quando elas estiverem envolvidas em cálculos deve ser colocado diretamente o valor final.

Estruturas de Dados

Uma das vantagens no VB é a não obrigatoriedade de declaração das variáveis. Isto permite realizar todo o potencial de improviso da metodologia POG.

No caso dos chatos implicarem com as declarações implícitas e obrigarem o uso de "Option Explicit", é essencial o uso de tipos genéricos como variants, strings e ints para garantir a máxima flexibilidade. Com um pouco de engenhosidade uma variável string pode substituir todos os demais tipos, inclusive matrizes.

Validação de Entrada

Infelizmente os usuários insistem em entrar com valores absurdos e em considerar como bug quando o programa retorna valores também absurdos.

A maneira mais adotada na POG para implementar a validação de entrada é fazer testes diretos contra valores ilegais, à medida em que os usuários os forem inventando. Ao detectar um valor ilegal, um valor legal deve ser silenciosamente adotado.

Se isto gerar reclamações, apresente uma mensagem de erro com um texto humilhante e obrige o usuário a refazer uma grande quantidade de passos. Isto terá um efeito disciplinador, fazendo com que o usuário seja cuidadoso na entrada de dados.

Por exemplo, uma construção típica na POG é o teste de um campo vazio:

If Text1 = "" Or Text1 = " " Or Text1 = " " Or Text1 = " " Then
Text1 = "(vazio)"

Tratamento de Erros

Tratamento de erros é para maricas e a POG desaconcelha o seu uso. Entretanto, os gerentes tendem a ficar do lado dos chorões dos usuários e os praticantes da POG se vem obrigados a implementar tratamentos de erros.

O cálice sagrado do tratamento de erro está disponível no VB:

On Error Resume Next

Uma alternativa menos eficaz é o tratamento específico aos erros:

arq$ = "xis"
On Error GoTo DeuCaca
Apaga:
Delete arq$
GoTo Apagou
DeuCaca:
If Error = -123 Then
Begin
If arq$ = "xis" Then arq = "yps" Else arq = "ze"
GoTo Apaga
End
Apagou:

Subrotinas

Os adeptos da POG costumam evitar as subrotinas, preferindo criar trechos imensos de código. No caso de uma mesma funcionalidade ser necessária em mais de um ponto, aplica-se a técnica C&P (Cut and Paste). Além do ganho em desempenho, isto confere a flexibilidade de ter versões ligeiramente diferentes.

Mensagens

Na POG as mensagens apresentadas ao operador seguem sempre a nomenclatura do programa. Por exemplo, é preferível "Código inputado não passou no teste de Módulo 11" ao invés de "Código incorreto, verifique o valor digitado". Neologismos (como o 'inputado' acima) contam pontos extras.

Controle de Fluxo

Na POG o controle de fluxo é obtido através de IFs e GOTOs. Como alternativa aos GOTOs podem ser usados flags e mais IFs. Neste segundo caso existem dois padrões comuns: usar uma única variável para todos os testes ou um nova variável para cada teste. Pontos de bonus para nomes criativos como 'flag', 'teste', 'flag33', etc.

O uso de SWITCH / CASE é desaconselhado pelos puristas na POG.

Traces e Logs

Os traces e logs são fundamentais na POG como o intrumento exclusivo para a depuração. Mensagens típicas de trace e log são "passei por aqui", "ponto 1", "i = 1", "não devia passar por aqui!".

Uma vez forçado o funcionamento do programa, existem duas técnicas comumente usadas: comentar todas as instruções de traces e logs ou deixá-las na execução normal. É considerado um desvio grave da filosofia POG a existência de um controle do nível de log ou trace, principalmente em tempo de execução.