Clique aqui para ler todos os artigos desta edição
“Culto à Carga” no desenvolvimento de software
por Mauro Sant’Anna
Durante a Segunda Guerra Mundial, os americanos ocuparam várias ilhas do Pacífico Sul com o intuito de apoiar as operações contra o Japão. Nessas ilhas, eles construíram pistas de pouso e armazéns para facilitar a movimentação de cargas por via aérea. A fim de não serem massacrados e devorados pela população local – que era ampla maioria – os americanos distribuíam parte da carga que circulava pelas bases aos habitantes locais. Os nativos adoravam ganhar coisas como comida enlatada e tendas e rapidamente se acostumaram com as comodidades da “vida moderna”.
Terminada a guerra, os americanos foram embora e abandonaram as instalações, até porque os aviões tinham mais autonomia e as pistas não eram mais necessárias. Os nativos, acostumados a desfrutar aquelas cargas, ficaram desolados. Decidiram então imitar o que os militares americanos costumavam fazer e que, na percepção deles, seria a causa da vinda dos aviões. Construíram novas pistas de pouso, torres de controle, fones de ouvido de madeira “operados” por nativos e tudo que fosse necessário para que os aviões “pudessem” voltar à pousar. Eles criaram um “Culto à Carga” (“cargo cult”). Evidentemente, apesar do grande esforço empreendido pelos nativos, os aviões não retornaram.
Note que construir as pistas de pouso foi a forma encontrada para suprir a razão original, que era movimentar a carga. Os nativos confundiram a forma com a necessidade original e ficavam cultuando a forma sem se importar com a razão.
Nós, desenvolvedores, acreditamos que somos mais espertos que os nativos da Micronésia, mas o “Culto à Carga” é muito comum no desenvolvimento de software. Existem várias situações nas quais despendemos um trabalhão para repetir um ritual cuja razão original de existir há muito se foi. O meu exemplo preferido é o uso da chamada “notação húngara” para dar nomes às variáveis.
Na década de oitenta, Chales Symoniy, então arquiteto-chefe da Microsoft, defendeu uma convenção na qual os nomes das variáveis na linguagem C deveriam incluir o tipo como prefixo. Por exemplo, uma variável do tipo usingned int teria o prefixo uint. Essa notação resolvia um sério problema da linguagem C (padrão “Kernighan & Ritchie”) usada na época, que era a ausência de tipagem forte. Podia-se atribuir um “char * para um int e o compilador não reclamava! Com a notação, conseguia-se alguma tipagem no “olhômetro”: era só ver se os prefixos nas atribuições eram iguais. Como os nomes das variáveis se tornavam muitas vezes impronunciáveis, e dada a origem húngara do Sr. Symoniy, seus colegas, por gozação, apelidaram a solução de “notação húngara”, e o apelido pegou. Ela foi bastante popularizada pela API do Windows 3.0 e muito utilizada pela Microsoft e pelos programadores em geral.
A notação húngara tinha lá seus problemas, como, por exemplo, impedia que se abstraíssem os tipos com o uso do comando typedef. Se você quisesse mudar o tipo de uma variável (de int para float, por exemplo), deveria alterar não só a declaração mas também todos os lugares que usassem a variável, já que o prefixo tinha mudado de “i” para “f”.
Com o passar dos anos, a utilidade da notação húngara foi diminuindo. O padrão C ANSI de 1990 que substituiu o “Kernighan & Ritchie” era fortemente tipado e não permitia coisas como atribuir um char * a um int por acidente. A API do Windows 3.10 de 1991 abandonou o húngaro tradicional, pois já previa futuras extensões de 32 bits e a codificação de tipos de 16 bits nos programas traria problemas no futuro. Acabou a guerra. Os aviões voltaram para casa. É o fim da notação húngara, então?
Nem tanto. Ainda hoje, em 2004, eu vejo nativos, ou melhor, programadores de linguagem fortemente tipadas como o C# usando notação húngara (mais de 10 anos depois de qualquer razão lógica para seu uso ter-se evaporado). Na verdade, em minhas consultorias, freqüentemente encontro não só a notação húngara como normas e convenções sem o menor sentido, para as quais a única explicação que recebo é uma variação do “aqui nós sempre fizemos assim”. Fico então imaginando algum analista bem-intencionado de farda verde e capacete de tenente do exército americano elaborando um padrão ultrapassado, porém ainda cultuado por nativos em trajes sumários, colares de conchas e ossos amarrados aos cabelos. A diferença é que eles agora estão sentados em frente a computadores.
Conclamo a todos os desenvolvedores que são vítimas de padrões aparentemente sem sentido que questionem a razão da existência desses padrões. Caso as razões não sejam aparentes, adote um novo padrão usando o bom senso. No caso dos nomes de variáveis, acho um bom padrão usar uma expressão baseada em um ou mais substantivos seguido ou não de um adjetivo que expresse o que a variável é. Por exemplo, “TotalPedido”, “NomeUsuario” e “QtdTelasAbertas” e evitar nomes que não tem significado como “temp1”, “var2” e “xxx0”, para não dizer do “húngaro”.Ao contrário dos habitantes da Micronésia, não temos a desculpa de sermos nativos ignorantes para adorarmos algum “Culto à Carga”.
