O que justifica o uso de um IDE versus um editor padrão? [fechadas]


39

Eu me pego usando meu editor de texto preferido (vim, nano, gedit, escolha seu veneno) com muito mais frequência do que qualquer IDE ultimamente.

Depois de perceber que meus atalhos ide ficaram empoeirados, comecei a pensar sobre isso e me perguntar: o que justifica o uso de um IDE para você, em vez de um editor de texto ?

Para essa matéria que lógica você teria para não usar um IDE e simplesmente confiar em um editor?



o que você realmente faz em seus editores?

Escreva código, desenvolva aplicativos, ... praticamente tudo ultimamente.
Chris

15
Pessoalmente, acho o IDE muito mais útil ao ler o código de outras pessoas (especialmente projetos grandes) do que ao escrever meu próprio código. Os IDE permitem navegar mais facilmente pela fonte, facilitando a compreensão rápida do código fonte de outras pessoas.
Charles Salvia

3
Eu gostaria de mudar a questão. O que justifica NÃO usar um IDE.
precisa

Respostas:


70

OI: integração . Um bom editor de texto pode ser bom para escrever código, mas a maior parte da sua programação não é gasta escrevendo; é gasto em testes e depuração e, para isso, você deseja que seu editor de texto se integre ao seu compilador e seu depurador. Essa é a maior força de um IDE.


Se ao menos eu conseguisse encontrar um que não atrapalhasse :)
Tim Post

5
Acabei de aceitar a edição sub-par como o preço pago pela conveniência da integração.
TMN

Não está testando a programação se você faz certo? Se você passa a maior parte do tempo depurando e testando macacos, acho que vejo onde está o seu problema.
Tom Hawtin - tackline

8
@ Tom, Testing está programando quando você pode automatizar os testes que realiza o tempo todo. Caso contrário, verifique por qualquer método que produza a melhor qualidade.
Andres Jaan Tack

49

Esses são meus recursos favoritos do meu IDE favorito, IntelliJ, que eu gosto de usar para Java, PHP, Javascript, HTML e até ActionScript.

  • Verificação de erro - como código de verificação ortográfica ao vivo. Absolutamente essencial.
  • Navegação de código - Ctrl+clickem uma função, variável, digite para ir para a definição. (IntelliJ é muito bom nisso em todos os idiomas acima)
  • Conclusão de código - uso Ctrl+spaceconstantemente para ajudar a preencher o nome da classe ou do método de que preciso. Isso acelera a codificação de uma tonelada e até ajuda a detectar erros antes que eles aconteçam quando algo que você precisava não está acessível no contexto em que você está. O IntelliJ até ajuda a expandir acrônimos - digite NPE, hit Ctrl+spacee mostrará "NullPointerException", "NoPageError", etc. PressionandoAlt+enter para adicionar automaticamente o também importé muito bom.
  • Geração de código - Gere getters e setters, implemente métodos a partir de uma interface com apenas alguns cliques.
  • Muito bom coloração de código - O IntelliJ não apenas utiliza a palavra-chave padrão, string, coloração de nome de variável, mas também colore variáveis ​​de membros, variáveis ​​locais e parâmetros. No ActionScript, uma variável que é realmente um setter / getter será colorida como uma função.
  • Refatoração - A renomeação sem erros é a maior. O IntelliJ é muito bom em renomear até setters e getters ou usos de string. É claro que há pesquisa e substituição baseada em regex quando necessário e uma opção "preservar maiúsculas e minúsculas" para permitir que você substitua "meuNúmero", "MeuNúmero" e "MEU NÚMERO" por "myString", "MyString" e "MYSTRING" em uma operação
  • Integração de controle de versão - usamos o SVN, e meus recursos favoritos do IDE VC podem criar, excluir, mover classes sem pensar no SVN, navegar facilmente no histórico, uma ferramenta diff muito boa, boa capacidade de mesclagem e anotação de arquivos (mostrando histórico por linha) no editor.
  • Importação de dependência - Ao contar com uma biblioteca de terceiros para a qual você possui a fonte, você pode navegar facilmente para o código para referência, depuração etc.
  • Digitação inteligente - colando o código e colando-o automaticamente na posição da guia direita, preenchimento automático de colchetes, parênteses, aspas, etc.
  • Um corredor de teste muito bom para JUnit, FlexUnit, PHPUnit
  • Depuração - é claro. Depura o JBoss, Jetty e até o Flash na perfeição. Ctrl + clique nos rastreamentos da pilha para ir direto para o código.

Coisas como a coloração de código que você pode considerar como certa, mas uma boa coloração de código é como a visão periférica - ela permite que você se concentre nas coisas importantes sem gastar um segundo extra para identificar a palavra completa.

O IntelliJ também usa Ctrl+spacepara sugerir nomes de variáveis. Em Java, se você declarar uma nova variável EventMessageItem e clicar Ctrl+space, ela sugerirá "eventMessageItem", "eventMessage", "item" etc.

Todas essas coisas me dão muito mais tempo para pensar em meu código e arquitetura e pensar menos em corrigir formatação, lidar com o sistema de arquivos, corrigir erros de copiar e colar, alternar entre aplicativos, procurar documentação, etc. etc. Não sei como você pode dizer não a esse tipo de aumento de produtividade.


4
+ 1 para menção IntelliJ Idea - eu adoro isso
Artjom

3
+1, a maioria dos pontos aqui se aplicam a qualquer IDE decente, ou deveria :)
Matthieu

21

Os IDE entendem seu código muito melhor do que um editor. Isso permite, por exemplo, a conclusão e refatoração de identificadores, o que para linguagens detalhadas como Java é enviado por Deus,


1
Observe que todo esse entendimento requer memória para armazenar. Portanto, os IDE tendem a consumir bastante recursos, em comparação com um editor de "encaixe em um disquete".

19
Sim, mas minha máquina de 8Gb i7 dev precisa fazer alguma coisa enquanto digito. : D
Dominique McDonnell

Os IDEs não precisam ter fome de recursos. Mas Smalltalk provavelmente é um caso de ponta: sintaxe fácil, muito simples de reflexão e assim por diante.
Frank Shearar

@ Frank, depende do que você quer que eles façam e de como é fácil.

18
[To the IDE] You had me at intellisense/autocomplete

1
+1 Embora seja sempre desconcertante perceber que nunca mais digito um nome completo de classe, método ou propriedade e sei exatamente quantas teclas são necessárias para destacar a opção correta de preenchimento automático ... tic-tic-tic-TAB- dot-tic-tic-tic-TAB-dot-tic-tic-tic
grossvogel

5
@gross, mas está certo ! Digitar manualmente frequentemente implica erros de digitação.

@ TThorbjørnRavnAndersen A menos que você tenha duas coisas com nomes semelhantes e, acidentalmente, não digite caracteres suficientes para obter a correta. Eu inseri acidentalmente uma propriedade "NumberOfPoints" em algumas áreas que precisavam de "NumberOfSegments" devido a não prestar muita atenção ao meu preenchimento automático: p. Dito isto, eu prefiro o preenchimento automático do que não.
KChaloux

14

Produtividade. Existe alguma outra justificativa que faça sentido? Para mim, um IDE bem projetado que centraliza muitas das funções que desempenho durante a programação - criação e edição de código, controle de origem, depuração, interação com ferramentas de gerenciamento de projetos, comunicação com outros programadores, documentação, execução de testes automatizados - reduz drasticamente o atrito do processo que reduz minha produtividade.

Além disso, mesmo que eu precise saber como usar cada ferramenta individualmente, não quero. Para mim, pelo menos, clicar com o botão direito do mouse é infinitamente preferível a abrir uma CLI e digitar.

Eu usei muitos, mas os IDEs aos quais volto repetidamente são Visual Studio, Wing IDE e NetBeans. Todos agregam um valor significativo ao tempo que gasto em programação.


9

Historicamente, os IDEs forneciam conveniência incomparável em um computador de tarefa única. Meu primeiro compilador C exigiu as seguintes etapas no ciclo de edição-compilação-execução:

  • Iniciar editor
  • Editar programa
  • Salvar programa, sair do editor
  • Programa de compilação
  • Montar programa compilado
  • Programa compilado e montado por link
  • Rodar programa

no meu sistema CP / M. (Eu poderia ter automatizado muito disso como um programa em lote se minhas unidades de disco fossem maiores.)

Quando cheguei ao Turbo Pascal, fiquei encantado por poder manter o editor disponível durante a compilação e depuração.

Acredito que foi isso que popularizou os IDEs em primeiro lugar.


Mas todas essas coisas podem ser feitas por muitos editores; Emacs, por exemplo.
precisa saber é o seguinte

@ JasonFruit: Certamente. Estou explicando o que primeiro me atraiu para eles. Naqueles dias, eu estava executando o CP / M em um TRS-80 Mod 4, e acredito que o Emacs ainda era baseado em TECO.
precisa saber é o seguinte

Ok, ponto. :-) (Emoticon para preencher o número necessário de caracteres.)
JasonFruit

2
@JasonFruit, as máquinas CP / M-80 tinham no máximo 64 Kb de RAM. Considere quanto Emacs você pode caber nisso.

7

Se você codifica no Lisp, o Emacs possui recursos semelhantes ao Intellisense, como procurar parâmetros de método e preenchimento automático, para que você possa dizer que é o IDE original. Também é bom poder usar um programa para várias tarefas (edição em geral, shell / prompt de comando, leitura de notícias).

Em geral, a pergunta editor vs. IDE parece depender da linguagem de programação. Pelo que vi, os codificadores Ruby e Haskell, por exemplo, parecem preferir seu editor de texto favorito.


O Emacs realmente pode fazer isso em quase qualquer idioma. O modo PHP é bastante bom, são os modos para Javascript, Haskell, Erlang e SQL. (Os outros podem ser bons também, mas eu não os usei).
Zachary K

Depois de adicionar todos esses sinos e assobios ao emacs (ou a qualquer editor), o que você tem é um IDE. Ambiente de desenvolvimento integrado. Eu compará-lo com a compra de um bolo de uma padaria (IDE) versus tornando-se a partir do zero (fora enganado editor)
Sal

+1, Para Coq, Haskell e Lisp Emacs é a única coisa com qualquer apoio decente
Daniel Gratzer

4
  • Compilação com um clique
  • Depuração
  • Modelos de código
  • Conclusão de código
  • Integração com ferramentas de controle de versão e refatoração
  • Teste de unidade mais simples

para nomear alguns


3

Eu acho que a resposta dependerá muito da linguagem de programação que você está usando e do quão bom você é. Para idiomas como JAVA, um IDE é obrigatório se você estiver fazendo algo sério. Onde quer que seja, quando se trata de linguagens de script como JS ou Ruby IDES, não são muito úteis.

Eu uso o notepad ++ e um conjunto de scripts de shell (para backups, git commits) para o meu desenvolvimento e funciona perfeitamente.


Eu uso o GVIM para Javascript e acho que é muito mais rápido do que usar um IDE. Ele também usa muito menos memória. Adicione cerca de 3-4 scripts de shell para coisas como jsLint, formatação e controle de selênio, e acho que quase nunca preciso tirar a mão do teclado. (E, para ser honesto, eu provavelmente poderia transformar todos esses scripts em plugins VIM se eu me importava)
Zachary K

3

Alguns argumentos a favor dos "editores":

  1. Há casos em que um IDE ainda não foi desenvolvido ou nunca será.
  2. Com um editor, você pode fazer alterações "mais rápido" e mais cirurgicamente.
  3. Precisa de muito menos recursos (é mais fácil usar muitos abertos ao mesmo tempo)
  4. Porque é a única maneira de resolver alguns problemas como os descritos aqui .
  5. (pessoal) Às vezes, quando tenho que digitar tudo, estou trabalhando mais usando o meu consciente e mais envolvido no que estou digitando. Muitas vezes encontrei, por exemplo, um erro de ortografia em um método (formaqString), que passaria despercebido usando um IDE.
  6. Facilita o trabalho apenas com o uso do teclado (velocidade / fluxo)
  7. Mentalidade de usar macros ou outros poupadores de tempo.

Eu uso um IDE todos os dias para trabalhar, é difícil escrever Java / C # caso contrário.

(2) comparado com (3): basicamente, apenas a opção de editar arquivos remotamente (na área de trabalho ssh / remota) e fazer alterações mínimas na configuração ou nos arquivos de um servidor distante.


2

Dependendo do seu idioma, alguns IDEs também incluem designers visuais de Form / Window.

Embora deva ser destacado, a linha entre o editor de texto de um programador e um IDE não é bem definida. Muitos editores podem ser estendidos para lidar com compilação, conclusão de código, depuração etc.


2

Eu uso o IDE para teste / depuração / integração e o KEDIT para edição, porque o IDE é seriamente deficiente em recursos de edição.
Como o .NET IDE reconhece edições externas, tudo o que preciso fazer é salvar no editor e aceitar o prompt para recarregar a fonte. Isso me permite otimizar meus recursos de edição e depuração ao mesmo tempo.
Para outros IDE, eu uso o KEDIT como um processador de modelos e um programa de pesquisa de origem e copio / colo essa fonte no IDE.


O que você faz no kedit que o IDE não pode fazer? Estou realmente curiosa, ter nada nunca realmente utilizado, mas um IDE para a maioria da minha séria codificação ...
Dean Harding

O KEDIT, como outros editores inteligentes, possui recursos de script que me permitem fazer coisas que o IDE não pode. Por exemplo, eu uso o KEDIT para fazer vários buffers (até 100 por sessão do kedit), copiar e colar e editar colunas que o IDE nem consegue se aproximar.
Dave

1

Para o IDE:
- os recursos avançados são conectados com facilidade.
- alguns recursos são tão específicos para sua estrutura que os editores não têm equivalente.

Para editor:
--Mantendo as mãos no teclado.
- seu ambiente de desenvolvimento é o mesmo em todos os sistemas -
melhor script para o seu editor -
alguns recursos de um IDE estão disponíveis com ferramentas ou scripts externos. (intellisense, goto definição, encontre referências)


0

Curva de aprendizado curta. É isso aí.


4
Eu acho que você não estourou qualquer tipo de IDE
Harald Scheirich

4
Com o vim como meu co-piloto, não preciso.
N / a c

Curva de aprendizado curta para ....? perdão, mas isso não era óbvio para mim.
31410 Chris

0

O único que eu realmente recomendo é o depurador. Um IDE é realmente um editor com uma carga de outros gubbins adicionados, mas se você pode compilar digitando make (ou seta para cima + enter) em um prompt de comando, não precisa de um IDE. Se você pode se comprometer com o SCM clicando com o botão direito do mouse no explorer e escolhendo o item de menu certo, não precisa de um IDE.

Agora eu sei que algumas pessoas precisam de coisas como suporte à refatoração (escreva seu código corretamente na primeira vez :)) ou algum designer de GUI integrado (mas mesmo assim, usando o Visual Studio, eu uso o Expression para fazer meu trabalho de GUI, não o suporte XAML de baixa qualidade no VS ) e muitas pessoas precisam de inteligência e preenchimento automático (especialmente para linguagens detalhadas, como Java e C #, que possuem nomes muito bons para toda a gente).

Mas para mim, o depurador da GUI é a única boa razão para usar o IDE. Eu ainda uso um depurador de 'linha de comando' (bem, windbg), mas no dia-a-dia, é o embutido no VS.


0

Existem benefícios para um IDE. Nem todas as línguas têm um IDE abrangente para realmente mudar a escala ou pode ser proibitivamente difícil criar um para esse idioma. Razões pelas quais iria querer um IDE? Bem, vamos começar com estes:

  • A linguagem possui uma API padrão rica que, nos pop-ups do IDE, pode ajudar a acelerar o desenvolvimento.
  • Há muitos códigos de caldeira. (Tentativa / captura forçada, getters / setters, etc.)
  • O preenchimento automático pode atender com precisão às suas necessidades de codificação
  • Seu conjunto de testes de unidades de idiomas está integrado ao referido IDE.
  • O IDE está ciente e suporta várias bibliotecas comuns de idiomas em relação às melhores práticas.
  • Plugins disponíveis para tornar o trabalho mais fácil
  • Não é tão pesado que torna seu sistema lento
  • Depurador altamente integrado? Isso ajuda.

O problema não é que todas as linguagens realmente obtêm um grande ganho de produtividade com um IDE abrangente. Uso IDEs para alguns trabalhos que faço (Java, C #), mas não para outros (Python, Ruby, Coldfusion). Tudo realmente é um ato de equilíbrio. Alguns idiomas simplesmente não exigem um conjunto tão abrangente.

Existem IDEs para cada um? Certo. Você sempre precisa de um? Na verdade não.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.