O desenvolvimento de C # é efetivamente inseparável do IDE que você usa?

Sou um programador Python aprendendo C # que está tentando parar de se preocupar e adora C # pelo que é, em vez de compará-lo constantemente ao Python.

Estou envolvido em um ponto: a falta de explicitação sobre onde as coisas são definidas, conforme detalhado nesta questão do Stack Overflow . Resumindo: em C #, using foonão informa de quais nomes fooestão sendo disponibilizados, o que é análogo ao from foo import *Python - uma forma desencorajada na cultura de codificação do Python por ser implícita, e não a abordagem mais explícita from foo import bar.

Fiquei bastante impressionado com as respostas do Stack Overflow a esse ponto dos programadores de C #, que na prática essa falta de explicitação realmente não importa porque no seu IDE (presumivelmente Visual Studio) você pode simplesmente passar o mouse sobre um nome e ser informado por o sistema de onde o nome vem. Por exemplo:

Agora, em teoria, percebo que isso significa que, quando você está procurando com um editor de texto, não pode dizer de onde vêm os tipos em C # ... mas, na prática, não acho que isso seja um problema. Com que frequência você está realmente vendo o código e não pode usar o Visual Studio?

Isso é revelador para mim. Muitos programadores de Python preferem uma abordagem de editor de texto à codificação, usando algo como Sublime Text 2 ou vim, onde tudo se resume ao código, além de ferramentas de linha de comando e acesso direto e manipulação de pastas e arquivos. A idéia de depender de um IDE para entender o código em um nível tão básico parece anátema. Parece que a cultura C # é radicalmente diferente nesse ponto. E me pergunto se só preciso aceitar e abraçar isso como parte do meu aprendizado de C #.

O que me leva à minha pergunta aqui: o desenvolvimento de C # é efetivamente inseparável do IDE que você usa?

O Visual Studio é tão conveniente que, depois de trabalhar um pouco, é difícil usar um IDE diferente. Ele tem muitas ferramentas úteis e vários plugins disponíveis, então praticamente tem todos os recursos que você precisa.

Por outro lado, seja qual for o idioma que você aprende, é recomendável usar a linha de comando no início, para que você possa entender melhor como ele funciona. C # não é uma exceção.

o desenvolvimento de C # é efetivamente inseparável do IDE que você usa?

Teoricamente não, mas praticamente sim. É possível escrever em C # usando um editor de texto e uma linha de comando, mas se você tiver o Visual Studio, nunca faria isso. De fato, pouquíssimos programadores já executaram código C # a partir da linha de comando.

Entre: Se você se sentir incomodado using foo, poderá usar o caminho inteiro ao usar um tipo.

A idéia de depender de um IDE para entender o código em um nível tão básico parece anátema.

Não se trata de entender seu código: com tempo suficiente, você sempre pode localizar a variável certa com um editor de texto básico ou mesmo em uma impressão. No que diz respeito à compreensão do código, a dependência do IDE absolutamente não existe.

A localização eficiente de suas referências é um assunto totalmente diferente: adoro a capacidade de encontrar usos de variáveis ​​Java no Eclipse tanto quanto adoro encontrar pontos de declaração no Visual Studio, para C # e C ++. Prefiro gastar meu tempo codificando, em vez de procurar pontos de declaração manualmente. É o mesmo que fazer matemática: posso multiplicar números de vários dígitos em um pedaço de papel, mas prefiro usar a calculadora para economizar um ou dois minutos.

Começando com um certo "tamanho crítico" do código, um bom IDE se torna muito útil, independentemente da linguagem de programação. O tamanho pode variar de idioma para idioma, mas depois de cruzar vários milhares de linhas, ter um IDE ajuda independentemente do seu idioma. Isso tem mais a ver com as limitações da mente humana do que com uma linguagem de programação específica: em algum momento, sua memória de curto prazo está fadada ao "transbordamento".

Existem truques que permitem aumentar esse tamanho crítico onde o IDE se torna útil. Por exemplo, você pode seguir uma convenção de nomenclatura (os nomes húngaros eram grandes no mundo C ++ em algum momento, especialmente entre os profissionais do Windows). Outro truque comum é qualificar variáveis ​​de instância this.mesmo em contextos em que essa qualificação não é necessária.

Esses truques vêm com trocas: quase inevitavelmente, tornam seu programa menos legível ocultando nomes ou inserindo as referências explícitas que o encapsulamento pretendia ocultar. Diante da escolha, escolho um código de aparência limpa mais um IDE em vez de um código de aparência menos limpa menos um IDE. Reconheço plenamente, no entanto, que as escolhas de outras pessoas podem diferir das minhas.

Muitos programadores de Python preferem uma abordagem de editor de texto à codificação, usando algo como Sublime Text 2 ou vim, onde tudo se resume ao código, além de ferramentas de linha de comando e acesso direto e manipulação de pastas e arquivos.

Isso é ótimo, mas perde o objetivo do VS IDE. O objetivo de um IDE como o VS é o suporte rápido ao desenvolvimento por meio de ferramentas de código fortes, como refatoração e intellisense. O VS é um editor muito bom para código C #.

Agora, o C # permite codificar em um estilo que depende do IDE em maior medida (você pode usar muitas varpalavras-chave e similares). Algumas pessoas preferem ser mais explícitas, por exemplo, usando aliases de namespace para ter clareza em qual namespace uma classe pertence (como importem Java ou Python). É mais uma opção de estilo de codificação do que um recurso do idioma.

Como o C # é digitado estaticamente (embora com algumas extensões dinâmicas, a partir da v4), é sempre fácil descobrir quais tipos estão sendo referidos - se estiverem errados, o código não será compilado e o VS não é o único IDE com suporte para C # intellisense. Provavelmente é o melhor.

Desenvolver C # sem um IDE poderoso (como o VS) é como martelar as unhas à mão quando você já tem uma pistola de pregos de primeira linha - pode haver momentos estranhos que você precisa fazer, mas os profissionais usam a ferramenta certa para o trabalho .

Eu diria que o mesmo provavelmente também se aplica ao Java. Se houver um IDE poderoso com ferramentas intellisense e refatoras de código, provavelmente você deve usá-lo.

No entanto, olhe para o contrário - se você não quiser inteligência, compilar verificação de código de tempo e análise / refatoração de código, um IDE inchado não é o caminho a seguir, nem uma linguagem de tipo estaticamente. Eu acho que é o contrário:

Muitos programadores que preferem uma abordagem de editor de texto à codificação não ganham muito com linguagens estaticamente tipadas (como C # e Java) e, portanto, poderiam ser melhores se adotassem linguagens dinâmicas como Python e Javascript.

Eu acho que:

• Idiomas dinâmicos são adequados para ferramentas leves (IDEs pesados ​​conferem menos benefícios aqui)
• Linguagens estáticas se adequam a IDEs poderosos (as ferramentas podem ajudar com o código ao custo da flexibilidade)

Para responder à sua pergunta: embora esteja mudando lentamente, o ambiente de desenvolvimento da Microsoft tem sido amplamente uma monocultura .

Essa abordagem tem muitos pontos positivos e negativos, que podem ser discutidos detalhadamente (por exemplo, considere os prós e os contras de plataformas abertas e fechadas, como PCs versus Xbox), mas, no final das contas, as ferramentas da Microsoft são as que mais as pessoas usam. A empresa também demonstrou que sua tomada de decisão geralmente é uma espécie de processo de "dar o maior valor à maioria de nossos usuários", sempre buscando compromissos práticos (mais recentemente - considere o Typecript ). Então, basicamente, eu não ficaria surpreso ao descobrir que o desenvolvimento de C # foi / é feito com as ferramentas (VS) em mente.

Por um lado, o C # não é Python. Existem diferentes metodologias de design.

Agora, para responder sua pergunta, é completamente possível usar suas instruções em estilo Python.

using FooBar=MyName.Foo.FooBar; 

É que definitivamente não é a norma, porque não é tão fácil. No entanto, acho que você deve se preocupar menos em saber exatamente de onde vem exatamente cada turma. Eu não entendo o ponto inteiro de fazê-lo desta maneira em Python.

E também, o C # é uma linguagem que se presta muito bem ao uso de IDEs para facilitar. O Intellisense é incrivelmente simples de implementar, especialmente se comparado a linguagens dinâmicas como Ruby e Python. No entanto, você não precisa ficar preso ao seu IDE. Já ouvi falar de pessoas usando o Eclipse. É claro que também existe o MonoDevelop (que eu uso bastante), e você pode até trabalhar a partir de uma linha de comando. Às vezes, no meu servidor, editarei arquivos C # vie depois os xbuildreconstruírei ... Só que o uso de um IDE facilita muito as coisas em comparação com a linha de comando em casos típicos.

Alguém se incomoda em ler aqui embaixo?

Resumo dizendo que a funcionalidade IDE extremamente complexa é indispensável e que (deve) evoluirá para o Zen of Sublime VimNess algum dia ...

Nosso software é 129 projetos de cerca de 2M LOC. Acrescente a imensidão da estrutura .NET e, considerando tudo o que posso dizer, o IDE é vital, transcendendo as motivações da pergunta desse segmento.

Informações sobre a base de código

Período. Você conhece os tipos de recursos sobre os quais estamos falando; exceto que sua conveniência se torna indispensável e essencial com o tipo de base de código com a qual eu lido.

Eu escrevo um código melhor por causa do IDE. Eu sempre adiciono mensagens personalizadas aos meus testes da Unidade, porque é fácil, rápido e preciso. Eu sou a favor de enumerações sobre strings, devido em grande parte ao intellisense. Não hesito em usar nomes descritivos / longos - uma instrução de várias linhas é composta de forma rápida e limpa.

Mas mesmo essa inteligência é demais às vezes. Costumo usar a boa e antiga pesquisa de texto "localizar nos arquivos".

Ajuda de codificação

Aqui é onde eu frequentemente choro "basta!". Imagine uma tela cheia com uma dúzia de cores na maioria das vezes obscurecidas, alguma variável em particular destacada em todos os lugares, destaque para obscurecer o que a cinta realmente é, sublinhado em qualquer lugar porque "ele" quer que eu escreva literatura, não código, ícones para os menus de contexto do Resharper (você basta clicar nele e depois ignorá-lo na maioria das vezes), um pop-up de ajuda de assinatura abrangendo 2/3 da tela horizontalmente, exibindo verticalmente várias sobrecargas, um pop-up por causa de onde você acabou de deixar o cursor do mouse .... não consigo nem ver a & ^!% line * s * do código em que estou trabalhando!

Vis.Stud. precisa abraçar o minimalismo para que eu possa me concentrar na codificação e não passar por centenas (milhares, se você contar todas as configurações de codificação por cores e todos esses plugins) de configurações em uma batalha perdida para recuperar a sanidade. Uma chave " Pareto " seria ótima.

o desenvolvimento de C # é efetivamente inseparável do IDE que você usa?

Claro que não. Por que você não importaria o espaço para nome inteiro? A escolha de usar um IDE integrado ou um editor de texto não tem nada a ver com isso. A importação de todo o espaço para nome não dificulta a leitura ou o uso do código.

Lembre-se, C # é um idioma digitado. Se você importar vários namespaces com a mesma classe, receberá um erro de compilação.

Pessoalmente, não uso muito declarações de tipo de qualquer maneira. Em vez disso, uso a varpalavra - chave pelos motivos que descrevo aqui: http://blog.gauffin.org/2012/08/to-var-or-not-to-var-is-that-really-the-question/

Meu entendimento era que, em Python, "tudo é público" ou algo nesse sentido. Em C #, o designer do módulo decide o que é público e o que não é, portanto, quando você faz um, importvocê obtém a API pública de qualquer maneira. Essa pode ser uma razão para a diferença que você está descrevendo.

o desenvolvimento de C # é efetivamente inseparável do IDE que você usa?

No meu trabalho anterior, eu usava principalmente o vim para codificar em linguagens como C #, JavaScript, Powershell, Perl, C ++ e muitos desenvolvedores costumavam fazer algo semelhante. O projeto era grande demais para o Visual Studio.

Dito isto, a maioria dos desenvolvedores de C # lida com projetos muito menores e fica muito feliz em usar o VS.

Essa é uma visão interessante sobre o desenvolvimento de C #. O que você está perguntando vai além do C #, se você está perguntando sobre o IDE.

Como você diz, em Python, você pode usar vários editores para escrever seu código. Você também pode fazer isso com a estrutura .NET. Existem também outras ferramentas IDE que você pode usar, como o SharpDevelop. O Visual Studio é muito co-desenvolvido com a estrutura .NET e é relativamente caro. Existem ferramentas como o SharpDevelop e as versões "Express" do VS para atrair mais desenvolvedores para usar o .NET. Basicamente, tudo o que um IDE faz por você é fornecer um ambiente organizado, geralmente com inteligência, complementos para produtividade e um "auxiliar" para montar o que pode acabar sendo uma linha de comando muito assustadora para passar ao seu compilador. O mesmo vale para Java, ferramentas como o Eclipse apenas fornecem a organização e aprimoramentos de produtividade para nós. Sob o capô, nada de mágico acontece até você criar ou compilar seu projeto e esse respeito,

Quando você fala sobre a instrução "using" em C # e a compara ao Python, não é realmente a mesma coisa que acontece sob o capô. As instruções using são usadas pelo compilador para ajudar no esforço de transformar o código C # em MSIL. No MSIL, não há diretiva "importar todas essas classes deste namespace". No momento em que o código está no nível MSIL, todas as classes foram marcadas com seus nomes totalmente qualificados. Essas instruções "using" e "import" servem para facilitar a legibilidade humana. Eles não são comandos de otimização do compilador. Depois de toda essa "marcação de nomes totalmente qualificados" inicial, pode haver uma espécie de "minify" de baixo nível para os FQNs, mas isso é para ajudar o compilador / intérprete a executar mais rapidamente.

Uma diferença fundamental final entre todos esses idiomas mencionados aqui é que alguns deles são interpretados por VMs, alguns são interpretados no estilo JIT e outros são totalmente compilados. A maneira como essas diretivas de uso são implementadas nesses compiladores e intérpretes difere bastante.

HTH.

Eu acho que historicamente a resposta é praticamente sim - colocar o desenvolvimento de C # em funcionamento de maneira eficaz em qualquer coisa fora do Visual Studio, Xamarin ou SharpDevelop foi uma experiência desagradável.

Mas recentemente surgiram muitos projetos que facilitam, por exemplo:

O OmniSharp fornece uma base para intellisense e refatoração, juntamente com plugins vim, emacs, atom e sublime. Na verdade, eu não o usei, então não sei o quão bem funciona, mas parece promissor.

Os geradores Yeoman ASP.NET MVC ajudam a inicializar um novo projeto MVC (talvez outros geradores existam).

paket , uma alternativa ao NuGet, na qual você pode realmente adicionar pacotes NuGet ao seu projeto a partir da linha de comando e atualizar seus arquivos .csproj (embora houvesse uma ferramenta de linha de comando do NuGet, atualizar os projetos para usar os pacotes fazia parte do IDE integração, não ferramentas de linha de comando).

O Paket implica que você precisa adaptar seu código-fonte para usá-lo - portanto, se você se sentar como o único membro de uma equipe e quiser usar um editor de texto para codificação, e todo mundo usar o Visual Studio, terá que convencer todos mais para adaptar a solução às suas necessidades :(

Portanto, você deve poder começar a trabalhar, mas há muito mais trabalho a ser feito para que seu conjunto de ferramentas funcione com eficiência.

Não mais:

http://www.omnisharp.net/

OmniSharp é uma família de projetos de código aberto, cada um com um objetivo - Permitir um ótimo desenvolvimento .NET no SEU editor de escolha.

É divertido dizer Cross Platform .NET. Mas é razoável alguém desenvolver o .NET sem o Visual Studio e o Windows?

É divertido fazer o .NET em um Mac no Sublime? Ubuntu e Emacs? Windows e Atom? Você pode usar o seu editor, além de usar ótimos recursos como o Intellisense (não apenas o preenchimento automático), adicionar referência, formatar documento e muito mais. Desenvolva em qualquer lugar, implante em qualquer lugar (e no Azure!)

Eu testei isso com subime3 e osx

Mais amostras em

http://blog.jonathanchannon.com/2014/11/12/csharp-first-class-citizen-sublime-text/