Proliferação de APIs
Vinte anos atrás, em Novembro de 1985, o Windows 1.0 foi lançado com cerca de 400 funções documentadas. Dez anos depois, o Windows 95 teve bem mais de mil.
Hoje (em Outubro de 2005), estamos prontos para o lançamento oficial do .NET Framework 2.0. Tabulando somente o MSCorLib.dll e aqueles assemblies que começam com a palavra System, temos mais de 5.000 classes públicas que incluem mais de 45.000 métodos públicos e 15.000 propriedades públicas, sem contar os métodos e propriedades herdados e não sobrescritos. Um livro que listasse os nomes, valores de retorno e argumentos destes métodos e propriedades, uma por linha, teria cerca de mil páginas.
Se você escrevesse cada uma das 60.000 propriedades e métodos em cartões de 7 por 12 centímetros com uma pequena descrição do que fazem, teria uma pilha de 12 metros. Estes 60.000 cartões, alinhados de ponta a ponta – pelo comprimento de 12cm – poderia cercar o Central Park (quase), e eu ouvi que isso será realmente um projeto de arte pública no próximo verão.
Pode qualquer programador dominar 60.000 métodos e propriedades? Acho que não. Uma solução, é claro, é a especialização. Eu mesmo me especializei. Esta noite, eu espero que ninguém me faça perguntas sobre Web Forms ou ASP .NET ou SQL Server, pois essas não são minhas especialidades. Eu faço Windows Forms, e minha linguagem é C#.
IntelliSense
Visual Studio tem tentado atenuar o problema da proliferação de classes, métodos e propriedades com um recurso chamado IntelliSense. Isso certamente coloca a informação ao nosso alcance, se você pensar em seus dedos no sentido figurado como aquele lugar na tela onde o cursor do teclado está.
Como outras tecnologias viciantes, eu tenho um relacionamento de amor / ódio com o IntelliSense, e quanto mais eu o desprezo mais o uso, e quanto mais eu o uso, mais revoltado fico com a forma como fiquei viciado, e quanto mais viciado fico, mais eu desejo que isso nunca tivesse sido inventado.
Apenas no caso de você ter estado fora das trincheiras por algum tempo, o IntelliSense é a culminação de algumas tentativas anteriores em tecnologias de completar código. Se você digitar um nome de objeto e um ponto, por exemplo, obterá um menu de rolagem com uma lista de todos os métodos públicos, propriedades e eventos para essa classe, e quando você escolhe um nome de método e abre um parêntese, poderá obter as sobrecargas com vários argumentos, e uma dica descrevendo o que o método faz.
IntelliSense é considerado por alguns como a inovação de programação mais importante desde a cafeína. Ele funciona especialmente bem com .NET porque o Visual Studio pode usar reflexão para obter todas as informações que precisa das DLLs que você especificou como referências.
Na verdade, o IntelliSense tornou-se o primeiro aviso quando você não incluiu devidamente uma referência DLL ou uma diretiva using no topo do seu código. Você começa a digitar e o IntelliSense aparece com nada. Daí já sabe imediatamente que algo está errado.
E, no entanto, o IntelliSense também está ditando a forma como programamos.
Por exemplo, por muitos anos os programadores têm debatido se é melhor codificar de cima para baixo, onde basicamente você começa com a estrutura geral do programa e, eventualmente, o código das rotinas mais detalhadas na parte inferior ou, alternativamente, a abordagem de baixo para cima, onde você começa com as funções de nível baixo e prossegue para cima. Algumas linguagens, como Pascal clássico, basicamente impõe uma abordagem de baixo para cima, mas outras linguagens não.
Nota do Akita: Na comunidade Ruby on Rails, na vertente que adotou o Cucumber como ferramenta Ágil, o conceito de Behavior Driven Development (BDD) nos leva a programar de cima para baixo, que hoje é considerado uma forma muito mais eficiente de desenvolvimento, iniciando pelas User Stories, indo para a interface com o usuário, depois as rotas, os controllers, os models e só então as tabelas no banco, por exemplo.
Bem, o debate está terminado. Para o IntelliSense funcionar corretamente, programação de baixo para cima é melhor. O IntelliSense quer cada classe, cada método, cada propriedade, cada parâmetro do método, todas as variáveis locais adequadamente definidas antes de se referir a elas. Se esse não for o caso, então ele tentará corrigir o que você está digitando, usando algo que foi definido, e que provavelmente é simplesmente errado.
Por exemplo, suponha que você está digitando um código e decide que precisa de uma variável chamada id, e em vez de defini-la primeiro, você começa a digitar uma instrução que começa com id e um espaço. Eu sempre digito um espaço entre a minha variável e o sinal de igual. Como id não está definido em nenhum lugar, o IntelliSense encontrará algo que começa com estas duas letras que está sintaticamente correta, de acordo com as referências, namespaces, e o contexto de seu código. No meu caso particular, o IntelliSense decide que eu realmente queria definir uma variável do tipo de interface IDataGridColumnStyleEditingNotificationService, uma interface que eu nunca tive a oportunidade de usar.
No lado positivo, se você realmente precisa definir um objeto do tipo IDataGridColumnStyleEditingNotificationService, tudo que precisa fazer é digitar id e um espaço.
Se isso é errado, você pode eliminar o código proposto pelo IntelliSense e voltar ao que digitou originalmente com a combinação de teclas Ctrl-Z para desfazer. Eu gostaria de bater na mão dele e dizer “Não”, mas Ctrl-Z é a única coisa que funciona. Quem poderia supor que Ctrl-Z se tornaria uma das teclas mais importantes na utilização de modernas aplicações do Windows? Ctrl-Z funciona no Microsoft Word como, bem, quando o Word é excessivamente agressivo consertando sua digitação.
Mas a implicação aqui é impressionante. Para o IntelliSense começar a trabalhar direito, você não apenas deve codificar em uma estrutura de baixo para cima, mas dentro de cada método ou propriedade, também deve escrever código linearmente do início ao fim – exatamente como se estivesse usando o editor de linhas do velho DOS, o EDLIN. Você deve definir todas as variáveis antes de usá-las. Não mais saltando para qualquer lugar em seu código.
Nota do Akita: por isso é tão desconfortável exercitar Test Driven Development (TDD) com IDEs: TDD exige programação de cima para baixo, primeiro criando testes que falham para depois criar o código que a satisfaz. A IDE simplesmente não gosta dessa ordem e exige malabarismo para sair disso.
Não é que o IntelliSense está nos ensinando a programar como uma máquina, é só que o IntelliSense seria muito mais feliz se assim o fizéssemos.
E eu acho que isso está nos tornando mais idiotas. Em vez de descobrir exatamente o método que eu preciso, ou em vez de tentar lembrar um nome de propriedade indescritível, encontro-me a percorrer as possibilidades que o IntelliSense oferece, à procura de um nome familiar, ou pelo menos algo que parece se encaixar.
Eu não preciso lembrar mais nada. O IntelliSense se lembrará para mim. Além disso, eu justifico a mim mesmo que não quero aqueles 60.000 métodos e propriedades bagunçando minha mente. A minha saúde mental global será sem dúvida melhor sem eles, mas ao mesmo tempo, estou impedido de alcançar um estilo fluido de codificação porque ela não vem inteiramente da minha cabeça. Minha codificação tornou-se um diálogo constante com o IntelliSense.
Então eu não acho que o IntelliSense está nos ajudando a nos tornar programadores melhores. O objetivo real é para nos tornarmos programadores mais rápidos, o que também significa que está barateando nosso trabalho.
Claro, eu poderia sempre apenas desligá-lo.
E andar descalço? De jeito nenhum!
IntelliSense é uma tecnologia inevitável. Se a Microsoft não tivesse feito isso, alguém teria. Os seres humanos nunca foram inclinados a abster-se de perseguir certas tecnologias, pois eles podem ter repercussões infelizes.
Código Gerado
Não só o Visual Studio tenta completar código que estamos digitando, mas há muitos anos, o Visual Studio quis gerar o código para nós. Se selecionarmos um novo projeto de tipo Aplicativo Windows, por exemplo, e dar-lhe um nome e um local em uma unidade de disco, o Visual Studio gerará código suficiente para que este projeto seja imediatamente compilável e executável.
De alguma forma, nós fomos convencidos de que esta é a maneira correta de programar. Eu não sei porquê. Pessoalmente, acho que iniciar um programa com um arquivo de código fonte vazio é muito agradável. Eu gosto de escrever as preliminares e, em seguida, a função principal, ou o método main. O momento em que eu possa realmente usar alguma ajuda não é quando estou começando um programa, mas quando estou tentando terminar. Onde está o Visual Studio então?
Vamos para o Visual Studio 2005 em nossa imaginação e criar um programa C# Windows Forms – um projeto do tipo Aplicação Windows – e analisar o código.
Primeiro, vemos que o Visual Studio ligou o nosso programa a um grupo de bibliotecas de vínculo dinâmico que ele acha que precisamos. Criou referências não somente aos assemblies System, System.Drawing e System.Windows.Forms que são necessários em qualquer aplicativo não-trivial de Windows Forms, mas também System.Data, System.Deployment e System.Xml, independentemente se seu programa necessita dessas DLLs ou não. Estas referências extras não fazem nenhum mal real, exceto se alguém examina o programa – talvez para fazer algumas alterações após o programador original ter ido embora – e assume que a aplicação requer estas referências. Agora há confusão, porque existem referências a DLLs que o programa realmente não precisa.
Entre outros arquivos, o Visual Studio cria um Form1.cs que gentilmente permite a você, o programador, modificar. Esse é o código fonte do arquivo onde os manipuladores de eventos vão para controles no formulário principal. Nós vemos um monte de directivas using no topo com os namespaces para as necessidades do programa. Os namespaces normais para os programas do Windows Forms são System, System.Drawing e System.Windows.Forms, mas o Visual Studio também inclui System.Collections, System.ComponentModel, System.Data e System.Text, alguns dos quais são úteis com certeza, mas se o programa realmente não usar qualquer uma das classes nesses namespaces, eles são apenas ruídos de distração.
O Visual Studio também inclui todo o código que gera em um namespace onde é dado o mesmo nome que o nome do projeto. Claro, eu entendo completamente o valor de ter um namespace para DLLs, mas por que ter um namespace para as aplicações? Eu pensei muito, e não consigo entender.
Eu tenho falado sobre código, mas quando você cria um novo projeto Windows Forms, o Visual Studio não coloca qualquer um dos arquivos de código fonte na sua frente. Em vez disso, ele coloca uma exibição de design de um formulário onde você deve começar a preencher de forma interativa com controles.
O Visual Studio também cria um arquivo chamado Form1.Designer.cs, e em algumas versões beta do Visual Studio 2005, esse arquivo não foi sequer listado entre os arquivos do projeto, por padrão. Este é o arquivo onde o Visual Studio insere código gerado quando você cria o formulário. O Visual Studio realmente não quer que você mexa com esse arquivo e por boas razões. Ele espera que este código gerado esteja em um determinado formato e, se você mexer nele, pode não ser capaz de lê-lo de volta na próxima vez que abrir o projeto.
(…)
Design Interativo
A maioria das coisas realmente inovadoras de design interativo, encontrou sua primeira manifestação no Visual Basic de Windows, e aqui é onde eu comecei a ficar nervoso sobre onde a programação no Windows estava indo. Não só você poderia mover um botão em seu formulário, e de forma interativa posicioná-lo e acertar seu tamanho do jeito que quisesse, mas se clicasse no botão, o Visual Basic geraria um manipulador de eventos para você, deixando-o digitar o código.
Isso me incomodou porque o Visual Basic estava tratando de um programa não como um documento completo e coerente, mas como pequenos trechos de código anexado para objetos visuais. Isso não é programar. Não é isso que o compilador vê. Como é que alguém obtêm um senso de um programa completo? Me deixou perplexo.
Eventualmente, o material de desenho interativo encontrou seu caminho para o desenvolvimento com C++ e Microsoft Foundation Classes, e lá, eu realmente acreditei, a geração de código foi usado para esconder um monte de coisas cabeludas do MFC que realmente ninguém queria ouvir falar.
Para um autor que escreve livros de programação, todo este material apresenta um dilema. Como você escreve um tutorial de programação? Você se concentra sobre o uso do Visual Studio para desenvolver aplicativos? Sinceramente, eu achei muito difícil escrever frases como “Agora arraste o objeto botão da caixa de ferramenta para a sua caixa de diálogo” e ainda sentir como se estivesse ensinando programação. Eu nunca escrevi sobre C++ e MFC, parcialmente porque MFC parecia um invólucro fino sobre a API do Windows e muito mal orientado a objetos. Eu continuei a rever edições posteriores do Programming Windows sob a suposição de que os seus leitores fossem programadores como eu, que preferiam escrever seu próprio código do zero.
Até mais, Resource Script
Eu comecei a olhar para o beta do .NET 1.0 e Windows Forms, no verão de 2000, e era claramente mais orientado a objeto do que o MFC jamais poderia ser. Gostei disso. Eu também estava intrigado que o Resource Script tinha desaparecido completamente. Você criava e montava controles nas caixas de diálogo – agora reunidos sob o termo mais global de “formulários” – ali mesmo em seu código. Claro que, mesmo no Windows 1.0, você poderia criar controles no código, e a primeira edição do Programming Windows tem alguns exemplos. Mas simplesmente não era muito agradável, porque toda criação de controles envolvia uma chamada para a função CreateWindow de 11 argumentos. Mas a criação de controles via código no Windows Forms era um piscar de olhos.
O que é agradável sobre criar e manipular controles no código é que você os está criando e manipulando no código. Suponha que você queira uma coluna de dez botões igualmente espaçados do mesmo tamanho exibindo nomes de cores. Em um programa, você pode realmente armazenar os dez valores de cores em um só lugar. É chamado um array. Há também uma excelente forma de criar e posicionar estes dez botões. É chamado de um loop for. Isso é programação.
Mas o Visual Studio não quer que você use arrays ou loops for para criar e posicionar esses botões. Ele quer que você use o designer, e ele quer gerar o código para você e escondê-lo onde você não possa vê-lo.
Quase vinte anos após o primeiro Editor de diálogo, o Visual Studio agora é o culpado, que gera código feio e o avisa para que não se meta com ele.
Se você tentar ler este código, não é assim tão fácil, porque cada classe e estrutura é precedido por um namespace completo:
1 |
System.Windows.Forms.Button button1 = System.Windows.Forms.Button (); |
Claro, nós sabemos porque o Visual Studio precisa fazer isso. Em teoria, é possível para você adicionar à caixa de ferramentas do Visual Studio outro controle Button chamado de outra DLL com outro namespace, e deve haver uma maneira de diferenciá-los.
Como o Visual Studio está gerando código baseado nos controles que você selecionar, ele dá nomes padrões aos controles, como button1, button2, button3, label1, label2, label3, textBox1, textBox2, textBox3.
Claro, o Visual Studio permite que você altere o nome da variável. Você pode alterar a propriedade Nome do controle, e isso se torna não apenas a propriedade Nome do objeto botão, mas também o seu nome de variável.
Os programadores realmente fazem isso? Eu tenho certeza que alguns fazem, mas também estou certo que muitos não o fazem. Como eu sei? Dê uma olhada em alguns dos códigos de exemplo que vem da Microsoft. Lá você verá button1, button2, button3, etc. E, no entanto, todos concordam que um dos elementos mais importantes de código auto-documentado está em dar nomes significativos às suas variáveis e objetos.
Se o Visual Studio realmente quisesse que você escrevesse código bom, toda vez que você arrastasse um controle no formulário, uma janela pop-up irritante diria: “Escreva um nome significativo para este controle.” Mas o Visual Studio não está interessado em fazer você escrever código bom. Ele quer que você escreva código rápido.
Enquanto estou no assunto de nomes de variáveis, eu deveria dizer algo positivo sobre o Visual Studio. O Visual Studio 2005 tem uma facilidade totalmente esplêndida de renomear variáveis. Você sabe como às vezes realmente quer mudar o nome de uma variável para estar mais em sintonia com sua função real no programa, mas você está receoso por causa dos possíveis efeitos secundários de buscar e substituir? Bem, esta nova renomeação de variáveis evita tudo isso, e também irá lhe dizer se você está renomeando algo para um nome que já existe. Espero que as pessoas se aproveitem disso para renomear seus controles para algo diferente dos padrões do Visual Studio.
Propriedades usadas Demais
Outro problema com a geração de código do Visual Studio é que todo controle vira uma propriedade na classe onde é criado. Esta é uma prática odiosa de programação, e realmente me incomoda que programadores possam estar olhando o código gerado pelo Visual Studio para aprender técnicas de programação adequada, e é isso que eles vêem.
Nos dias anteriories à orientação-a-objetos de programação C, tínhamos variáveis locais e variáveis globais, variáveis dentro de funções e variáveis fora de funções. Um dos objetivos da boa programação em C estava em manter o número de variáveis globais ao mínimo. Como qualquer variável global poderia ser modificada por qualquer função, era mais fácil entender um programa se simplesmente não houvesse muitas delas – se as funções estritamente se comunicassem entre si através de argumentos e valores de retorno.
Às vezes, no entanto, os programadores C ficavam um pouco, digamos, sonolentos, e faziam uma série de variáveis globais que realmente não precisavam existir, porque era mais fácil dessa maneira. Ao invés de acrescentar um argumento extra para uma função, porque armazená-lo como uma global?
As variáveis globais basicamente desapareceram em programação orientada-a-objetos, exceto que propriedades são agora as novas variáveis globais e podem ser abusadas de forma muito ruim.
Um dos princípios básicos de programação orientada-a-objetos está em esconder dados. Isso geralmente se aplica entre classes. Classes não devem expor tudo o que têm. Elas deveriam ter uma interface pública o menor possível, e outras classes devem saber apenas o que precisam saber. Mas o princípio de ocultamento de dados é importante também dentro de uma classe. Métodos devem ter acesso limitado aos dados que outros métodos estão usando. Em geral, as variáveis devem ser locais para um método a menos que haja uma razão específica de porque precisam ser acessados de qualquer outro método.
Quando você cria um objeto usando o operador new, a quantidade de armazenamento alocada no heap para o objeto deve ser suficiente para acomodar todas as propriedades definidas na classe que está criando o objeto e todas as classes ancestrais. As propriedades basicamente definem o tamanho do objeto na memória. Eu sei que estamos muito além do ponto de se preocupar com cada byte de armazenamento, mas quando você olha para as propriedades que definiu em sua classe, deve estar se perguntando: Será que todo este material realmente precisa ser armazenado com cada objeto no heap? Ou restringi com sucesso as propriedades às informações necessárias para manter o objeto?
Alguém me disse que gosta de armazenar objetos como propriedades porque tem medo do garbage collector do .NET limpar tudo que não estiver em definições apropriadas de propriedade. Depois de anos definindo muito poucas propriedades em .NET, posso lhes dizer que isto não é um problema. O garbage collector do .NET só excluirá objetos que não são mais referenciados em qualquer parte do programa. Se você ainda pode acessar um objeto de alguma forma, ele não é elegível para coleta de lixo.
Em teoria, nenhuma controle-filho criado como parte de um formulário deve ser armazenado como uma propriedade porque o pai – geralmente um formulário – armazena todos os seus controles-filho na coleção chamada Controls, e você pode fazer referência a cada controle indexando a propriedade Controls usando inteiros ou a propriedade texto Nome que lhe foi atribuída ao criar o controle. E aqui mais uma vez você está muito melhor se os controles tiverem nomes significativos e não button1, button2, button3, label1, label2, label3 …
Se um determinado objeto é definido como uma propriedade ou uma variável local é algo que nós, como programadores devemos estar pensando a cada objeto que criamos. Um label que tem o mesmo texto durante toda a duração do formulário pode ser facilmente local. Para um rótulo cujo texto é o conjunto de um manipulador de eventos de algum outro controle, provavelmente é mais conveniente armazenar como uma propriedade.
É muito simples. Mas o Visual Studio não quer que você pense sobre isso. O Visual Studio quer tudo armazenado como uma propriedade.
Visual Studio Desmistificado
Mesmo se o Visual Studio gerasse código imaculado, ainda haveria um problema. Como ele está gerando o código, também ergue muros entre o código e o programador. Ele implica que esta é a única maneira que você pode escrever um programa Windows moderno ou web, porque há certos aspectos da programação moderna que só ela conhece. E o Visual Studio aumenta essa impressão, incluindo código clichê que contém material que nunca foi realmente discutido de forma adequada, nos tutoriais ou documentação que a Microsoft oferece.
Torna-se imperativo para mim, como professor de programação Windows Forms e programação de Avalon, deliberadamente ir na direção oposta. Eu sinto necessidade de desmistificar o que o Visual Studio está fazendo e demonstrar como você pode desenvolver esses aplicativos escrevendo seu próprio código e, se você quiser, compilar esse código na linha de comando totalmente fora do Visual Studio.
Nos meus livros de formulários do Windows, eu digo ao leitor para não escolher Aplicação Windows quando se inicia um novo projeto Windows Forms, mas escolher a opção Projeto Vazio em vez disso. O projeto vazio não cria nada além de um arquivo de projeto. Todas as referências e todo o código deve ser adicionado explicitamente.
Estou prestando um serviço público, mostrando aos programadores como escrever código de uma maneira que é diametralmente oposta às funcionalidades incorporadas na ferramenta que eles estão usando? Eu não sei. Talvez isto seja errado, mas não vejo outra alternativa.
(…)
Os Prazeres Puros de Código Puro
Alguns meses atrás – talvez como um antídoto para toda essa overdose de Windows Forms e programação Avalon que tenho feito – eu comecei a programar em C novamente. Só um pouquinho. Uma revista que li – o semanário britânico New Scientist – tem uma parte chamada de “Enigma”, que apresenta um pequeno enigma de matemática. Aqui está um curto de Junho passado: “Qual é o maior inteiro cujos algarismos são todos diferentes (e não incluem 0), que é divisível por cada um dos seus dígitos individuais?” Se você resolve um dos problemas Enigma, pode enviar a sua solução, e uma é escolhida aleatoriamente em uma determinada data, e se o seu for escolhido você ganha USD 25 e uma menção na revista.
Estes problemas Enigma realmente me incomodaram durante anos, porque eles sempre me pareceram ser resolvidos escrevendo um programa curto e testando as possibilidades e, por alguma razão, isso me parecia absurdo.
Alguns meses atrás eu decidi que poderia realmente ser interessante resolver os problemas com código, e em seguida enviar os programas e soluções no meu site um dia depois do prazo, mas cerca de uma semana antes da resposta aparecer impressa.
Eu decidi usar o bom e velho ANSI C, e editar o código-fonte no Bloco de notas – que não tem nenhuma noção de IntelliSense e nenhuma noção de qualquer outra coisa – e compilar na linha de comando usando tanto o compilador Microsoft C e o compilador GNU C.
O que é interessante sobre este projeto é que eu não tenho que olhar nada. Eu tenho codificado em C há 20 anos. Foi a minha linguagem preferida antes de C#. E isso é apenas pura codificação algorítmica com saída de texto simples. É somente conteúdo.
Eu também descobri que os problemas realmente exigem uma reflexão antes de codificá-los. Muitas vezes, o número total de combinações é proibitivo. Você realmente tem que trabalhar. Você não quer escrever um programa que precisa ser executado por uma semana antes de chegar à instrução printf. Por exemplo, se o problema que citei: “Qual é o maior inteiro cujos algarismos são todos diferentes (e não incluem 0) que é divisível por cada um dos seus dígitos individuais?” Isso realmente ajuda a perceber que este número inteiro não pode conter o dígito 5 se ele também contém qualquer dígito par, porque então o número será divisível por 10, e o último dígito seria 0, o que não é permitido. Assim, o número que estamos procurando provavelmente não inclui 5. O que imediatamente reduz as possibilidades por uma ordem de grandeza.
Mesmo após este processo preliminar, há ainda codificação para fazer, mas não há nenhuma API, não há classes, não há propriedades, não há formulários, não há controles, não há manipuladores de eventos, e não há definitivamente o Visual Studio.
É somente eu e o código e, por algum tempo, me sinto como um verdadeiro programador novamente.