Recentemente tenho utilizado o Visual Studio como ferramenta de desenvolvimento. Não tinha expectativas elevadas, até porque nos últimos 9 meses tinha utilizado o CLion, porém não estava à espera de encontrar, naquilo que chamam de “Visual Studio 2015”, um IDE tão incompleto. No texto que se segue tento resumir alguns pontos que me desagradaram e que tornaram a minha experiência bastante negativa.
IDE e Visual Studio são oximoros
Antes de mais, o próprio conceito de IDE (Integrated Development Environment) é logo posto em causa. Necessitam
de fazer uma ligação remota? FTP? Não há. Abrir uma consola? Não há. Abrir outros ficheiros que não sejam .c, .cpp ou .h?
Também não é boa ideia, já que nem sequer têm syntax highlighting…
Na prática, e ao fim de alguns dias de frustração, vão acabar como eu: um ambiente de trabalho com o Visual Studio, Atom (ou, ironia das ironias, Visual Studio Code), meia dúzia de consolas e algumas pastas abertas. Desnecessário, não?
Windows Only
Outro grande problema (e dos grandes) prende-se com o Windows. Para começar, só conseguem correr o Visual Studio no Windows, o que obriga a que toda a equipa utilize esse sistema operativo. Mas principalmente porque todo o Visual Studio roda à volta do ecossistema Microsoft. Esqueçam a ideia de desenvolver aplicações cross-platform (e nem me falem do Visual C++ for Linux Development que crasha o Visual Studio a cada 10 minutos). Aliás, tenho vindo a investigar e desenvolver formas de o conseguir, utilizando containers Docker e outras ferramentas (mais sobre isto, talvez, noutro commit).
E acho que nem vale a pena dizer que têm de esquecer gcc, cmake, etc..
Intellisense é lento e pouco inteligente
Qualquer programador dá bastante valor à capacidade do seu IDE de navegar pelo código de forma fácil e intuitiva e ter ajudas como code completion. No caso do Visual Studio, estas funcionalidades ficam a cargo do Intellisense (e da paciência do programador).
Em primeiro lugar, o Intellisense, por alguma razão, gasta bastante memória RAM (não me perguntem porquê). Em segundo, não compreendo porque é que o Intellisense atualizar os seus índices seja algo tão crítico para bloquear por completo qualquer ação no Visual Studio durante uns bons segundos.
Dá-me um aperto no coração de cada vez que o Visual Studio me notifica por causa de erros ortográficos (expliquem-me lá qual é a lógica de um IDE fazer spell-checking…), mas nem sequer piar quando preciso de verificar os parâmetros que a função X recebe.
Análise estática de código? Nenhuma, acertaram!
Atalhos? Templates? Refactoring?
Lembram-se do quão repetitivo e error-prone é escrever um ciclo for? Ou fazer um switch statement? Pois bem, o
Visual Studio tem algo chamado Visual Studio Snippets, uma versão arcaica daquilo que a JetBrains chama de Live
Templates.
Podia dar mil e um exemplos de comparação (ora aqui está outra boa ideia para um futuro post). Fiquemo-nos só por dizer que, infelizmente, o Visual Studio está a anos-luz da concorrência nesta área (e podem incluir aqui o Intellisense também).
Estrutura dos projetos e Nomencleatura
Esta é uma das partes mais controversas e, portanto, espero não me alongar. Para começar, um bocado de contexto: o
Visual Studio decidiu chamar aquilo que entendemos como um projeto de Solução. A solução é única e pode conter mais
que um projeto (aquilo que normalmente se chama de módulo), podendo cada projeto ter propriedades distintas. É aqui que
começa a confusão. Propriedades partilhadas por vários projetos, devem ser agrupadas em props (Project Properties) de
forma a evitar repetição de informação. Porém, não existe o conceito de “Run Configurations”, pelo que as configurações
que podem fazer compile and run são as que estão de momento ativas (sim, para mudar têm de ir à mão, uma a uma… não
há como ter configurações pré-definidas).
Mas a confusão não se fica por aqui: já referi que não podem abrir 2 janelas de propriedades de projeto simultaneamente
(para comparar é necessário estar a alternar entre uma e outra)? E já referi que existem configurações de Release e
Debug (até aqui tudo OK), e que cada uma se subdivide em x86, x64, ARM, etc? E que, apesar desta explosão combinatória de
possibilidades e configurações, podem usar o “simpático” “All Configurations? A idea parece boa ao início, mas basta
terem uma das configurações diferentes, que o Visual Studio vos presenteia com a informação também simpática <different configurations>.
Muito informativo…
Mas preparem-se… Deixei a “bomba” para o fim. Preparados? Aqui vai: o projeto do Visual Studio não tem qualquer relação com o sistema de pastas. Isto significa que a organização de pastas que têm no vosso projeto (ou solução no Visual Studio) não tem qualquer relação com aquilo que vão encontrar dentro do Visual Studio. Podem organizar à vontade o vosso projeto com pastas e subpastas, que nada disso se vai refletir dentro do Visual Studio.
E a melhor parte é que se moverem um ficheiro de local no filesystem, o Visual Studio perde-lhe a referência e vão ter que remover o ficheiro do Visual Studio e voltar a adicionar. E criar um ficheiro? Se o fazem dentro do Visual Studio (para não o ter que importar para lá mais tarde), o Visual Studio cria-o na root do projeto (porque não há qualquer associação com as pastas do filesystem, lembram-se?). E se depois quisermos mover o recém-criado ficheiro para uma pasta? Voltamos ao primeiro caso… Agora imaginem isto para projetos com centenas/milhares de ficheiros.
Para colmatar esta falha (ou design propositado), o Visual Studio tem a noção de pastas virtuais (isto é, fazem o mesmo que pastas, mas não existem no filesystem), mas chama-lhe, carinhosamente, de filtros. Podem sempre, claro, replicar a estrutura de pastas do filesystem no Visual Studio, mas é repetir trabalho sem necessidade…
E fico-me por aqui. E pelo CLion.