Lo sviluppo di C # è effettivamente inseparabile dall'IDE che usi?

Sono un programmatore di Python che sta imparando C # che sta cercando di smettere di preoccuparsi e adoro C # per quello che è, piuttosto che confrontarlo costantemente con Python.

Sono sorpreso da un punto: la mancanza di esplicitazione su dove sono definite le cose, come dettagliato in questa domanda Stack Overflow . In breve: in C #, using foonon ti dice quali nomi foovengono resi disponibili, il che è analogo a from foo import *Python - una forma che è scoraggiata nella cultura del codice Python per essere implicita piuttosto che per l'approccio più esplicito di from foo import bar.

Sono stato piuttosto colpito dalle risposte di Stack Overflow a questo punto dai programmatori C #, il che era che in pratica questa mancanza di esplicitazione non ha davvero importanza perché nel tuo IDE (presumibilmente Visual Studio) puoi semplicemente passare sopra un nome e farti dire da il sistema da cui proviene il nome. Per esempio:

Ora, in teoria, mi rendo conto che questo significa che quando stai guardando con un editor di testo, non puoi dire da dove provengono i tipi in C # ... ma in pratica, non trovo che questo sia un problema. Con quale frequenza stai effettivamente visualizzando il codice e non riesci a utilizzare Visual Studio?

Questo è rivelatore per me. Molti programmatori Python preferiscono un approccio alla codifica con un editor di testo, usando qualcosa come Sublime Text 2 o vim, in cui è tutto basato sul codice, oltre a strumenti da riga di comando e accesso diretto e manipolazione di cartelle e file. L'idea di dipendere da un IDE per comprendere il codice a un livello così basilare sembra un anatema. Sembra che la cultura C # sia radicalmente diversa su questo punto. E mi chiedo se devo solo accettarlo e accettarlo come parte del mio apprendimento di C #.

Il che mi porta alla mia domanda qui: lo sviluppo di C # è effettivamente inseparabile dall'IDE che usi?

Visual Studio è così conveniente che dopo aver lavorato per un po 'è difficile usare un IDE diverso. Ha molti strumenti utili e un sacco di plugin disponibili, quindi praticamente ha tutte le funzionalità di cui hai bisogno.

D'altra parte, qualunque sia la lingua che impari, si consiglia di utilizzare la riga di comando all'inizio, in modo da poter capire meglio come funziona. C # non fa eccezione.

lo sviluppo di C # è effettivamente inseparabile dall'IDE che usi?

Teoricamente no, ma praticamente sì. È possibile scrivere in C # usando un editor di testo e la riga di comando, ma se si dispone di Visual Studio, non lo si farebbe mai. In effetti pochissimi programmatori hanno mai eseguito il codice C # dalla riga di comando.

A proposito, se ti senti a disagio using foo, puoi usare l'intero percorso quando usi un tipo.

L'idea di dipendere da un IDE per comprendere il codice a un livello così basilare sembra un anatema.

Non si tratta di capire il tuo codice: dato il tempo sufficiente, puoi sempre individuare la variabile giusta con un editor di testo di base o anche in una stampa. Per quanto riguarda la comprensione del codice, la dipendenza IDE non esiste assolutamente.

Individuare i riferimenti in modo efficiente è un argomento completamente diverso: amo la capacità di trovare gli usi delle variabili Java in Eclipse tanto quanto amo trovare i punti di dichiarazione in Visual Studio, sia per C # che per C ++. Preferisco spendere il mio tempo a programmare, piuttosto che cercare manualmente i punti di dichiarazione. Questo è simile a fare la matematica: posso moltiplicare i numeri a più cifre su un pezzo di carta, ma preferisco usare la calcolatrice per risparmiare un minuto o due.

A partire da una certa "dimensione critica" del codice, un buon IDE diventa molto utile indipendentemente dal linguaggio di programmazione. Le dimensioni possono variare da lingua a lingua, ma una volta attraversate diverse migliaia di righe, avere un IDE aiuta indipendentemente dalla tua lingua. Ciò ha più a che fare con i limiti di una mente umana che con un particolare linguaggio di programmazione: ad un certo punto, la tua memoria a breve termine è destinata a "traboccare".

Ci sono trucchi che ti consentono di aumentare quella dimensione critica in cui l'IDE diventa utile. Ad esempio, potresti seguire una convenzione di denominazione (i nomi ungheresi erano grandi nel mondo C ++ ad un certo punto, specialmente tra i professionisti di Windows). Un altro trucco comune è la qualificazione delle variabili di istanza this.anche in contesti in cui tale qualificazione non è richiesta.

Questi trucchi hanno dei compromessi: quasi inevitabilmente, rendono il tuo programma meno leggibile oscurando i nomi o inserendo i riferimenti espliciti che l'incapsulamento doveva nascondere. Di fronte alla scelta, scelgo un codice dall'aspetto pulito più un IDE su un codice dall'aspetto meno pulito meno un IDE. Riconosco pienamente, tuttavia, che le scelte di altre persone possono differire dalle mie.

Molti programmatori Python preferiscono un approccio alla codifica con un editor di testo, usando qualcosa come Sublime Text 2 o vim, in cui è tutto basato sul codice, oltre a strumenti da riga di comando e accesso diretto e manipolazione di cartelle e file.

È fantastico, ma manca il punto dell'IDE VS. Il punto di un IDE come VS è il rapido supporto allo sviluppo attraverso strumenti di codice forti come refactoring e intellisense. VS è un molto molto buon editor per il codice C #.

Ora C # ti consente di programmare in uno stile che dipende in gran parte dal suo IDE (puoi usare molte varparole chiave e simili). Alcune persone preferiscono essere più esplicite, ad esempio utilizzando gli alias dello spazio dei nomi per chiarire a quale spazio dei nomi appartiene una classe (come importin Java o Python). È più una scelta di stile di codifica che una caratteristica del linguaggio.

Dato che C # è tipizzato staticamente (anche se con alcune estensioni dinamiche, a partire dalla v4) è sempre abbastanza facile scoprire a quali tipi si fa riferimento - se sono sbagliati il ​​codice non verrà compilato e VS non è l'unico IDE con supporto per C # intellisense. È probabilmente il migliore però.

Sviluppare C # senza un potente IDE (come VS) è un po 'come martellare a mano le unghie quando hai già una pistola di alta gamma - potrebbe esserci il tempo strano che devi fare, ma i professionisti usano lo strumento giusto per il lavoro .

Direi che lo stesso vale probabilmente anche per Java. Se c'è un potente IDE con intellisense e strumenti di refactoring là fuori probabilmente dovresti usarlo.

Tuttavia, guardalo al contrario: se non vuoi intellisense, compila il controllo del codice temporale e l'analisi del codice / refactoring, allora un IDE gonfio non è la strada da percorrere, e nemmeno un linguaggio tipicamente statico. Penso che sia il contrario:

Molti programmatori che preferiscono un approccio alla codifica con editor di testo non ottengono molto dai linguaggi digitati staticamente (come C # e Java) e quindi potrebbero stare meglio se si attaccano a quelli dinamici come Python e Javascript.

Credo:

• I linguaggi dinamici si adattano a strumenti leggeri (gli IDE dei pesi massimi conferiscono meno benefici qui)
• I linguaggi statici si adattano a potenti IDE (gli strumenti possono aiutare con il codice a costo della flessibilità)

Per rispondere alla tua domanda: sebbene stia lentamente cambiando, l'ambiente di sviluppo Microsoft è stato in gran parte una monocoltura .

Questo approccio ha molti aspetti positivi e negativi, che potrebbero essere discussi a lungo (ad esempio, considerare i pro ei contro di piattaforme aperte e chiuse, come PC vs Xbox), ma alla fine, gli strumenti di Microsoft sono ciò che più la gente usa. L'azienda ha anche dimostrato che il loro processo decisionale è spesso una sorta di processo "dare il massimo valore alla maggior parte dei nostri utenti", sempre alla ricerca di compromessi pratici (più recentemente - considera Typescript ). Quindi, fondamentalmente, non sarei sorpreso di scoprire che lo sviluppo di C # è stato / è fatto pensando agli strumenti (VS).

Per uno, C # non è Python .. Esistono diverse metodologie di progettazione.

Ora, per rispondere alla tua domanda, è completamente possibile usare il tuo stile Python usando le istruzioni.

using FooBar=MyName.Foo.FooBar; 

È solo che non è assolutamente la norma perché non è così facile. Tuttavia, penso che dovresti preoccuparti di meno di sapere esattamente da dove proviene esattamente ogni classe. Tuttavia, non capisco il punto di farlo in Python.

Inoltre, C # è un linguaggio che si presta molto bene all'utilizzo degli IDE per renderlo più semplice. Intellisense è incredibilmente semplice da implementare, soprattutto rispetto ai linguaggi dinamici come Ruby e Python. Tuttavia, non devi essere bloccato sul tuo IDE. Ho sentito parlare di persone che usano Eclipse. Naturalmente c'è anche MonoDevelop (che uso parecchio), e puoi persino lavorare da una riga di comando. Sul mio server a volte, modificherò i file C # con vie poi utilizzerò xbuildper ricostruirlo ... È solo che l'uso di un IDE rende le cose molto più facili rispetto alla riga di comando per i casi tipici.

Qualcuno si preoccupa di leggere fin qui ??

Riassumo affermando che la funzionalità IDE estremamente complessa è indispensabile e un giorno dovrebbe (dovrebbe) evolversi nello Zen di Sublime VimNess ...

Il nostro software comprende 129 progetti di circa 2 milioni di LOC. Aggiungete l'enormità del framework .NET e, dato ciò, posso solo dire che l'IDE è vitale, trascendendo le motivazioni della domanda di questo thread.

Informazioni sulla base di codice

Periodo. Conosci i tipi di funzionalità di cui stiamo parlando; solo che la sua praticità diventa indispensabile ed essenziale con il tipo di base di codice con cui mi occupo.

Scrivo codice migliore a causa dell'IDE. Aggiungo sempre messaggi personalizzati ai miei test Nunit perché è facile, veloce e preciso. Prediligo le enumerazioni sulle stringhe dovute in gran parte all'intellisense. Non esito a usare nomi descrittivi / lunghi: un'istruzione multilinea è composta in modo rapido e pulito.

Ma anche questa intelligenza è troppo a volte. Uso spesso la ricerca del testo "trova nei file".

Aiuto per la codifica

Qui è dove piango spesso "abbastanza!". Immagina uno schermo pieno con una dozzina di colori per lo più oscuri, qualche particolare variabile evidenziata ovunque, una parentesi graffa che evidenzia ciò che è effettivamente la parentesi graffa, sottolineando ovunque ovunque perché "vuole" che io scriva letteratura non codice, icone per i menu contestuali di Resharper (tu basta fare clic su di esso! quindi ignorarlo per la maggior parte del tempo), un popup di aiuto della firma che occupa i 2/3 dello schermo in orizzontale, mostrando verticalmente diversi sovraccarichi, un popup a causa di dove ti è appena capitato di lasciare il cursore del mouse .... I non riesco nemmeno a vedere il & ^!% line * s * del codice su cui sto lavorando!

Vis.Stud. ha bisogno di abbracciare il minimalismo in modo che io possa concentrarmi sulla codifica e non passare attraverso centinaia (migliaia se contate tutte le impostazioni di codifica dei colori e tutti quei plugin) di impostazioni in una battaglia persa per rivendicare la sanità mentale. Una chiave " Pareto " sarebbe fantastica.

lo sviluppo di C # è effettivamente inseparabile dall'IDE che usi?

Ovviamente no. Perché non dovresti importare l'intero spazio dei nomi? La scelta di utilizzare un IDE integrato o un editor di testo non ha nulla a che fare con questo. L'importazione dell'intero spazio dei nomi non rende più difficile leggere il codice o utilizzarlo.

Ricorda, C # è un linguaggio tipizzato. Se importi più spazi dei nomi con la stessa classe, otterrai un errore di compilazione.

Personalmente non uso così tanto le dichiarazioni di tipo in entrambi i modi. Invece uso la varparola chiave invece per i motivi che descrivo qui: http://blog.gauffin.org/2012/08/to-var-or-not-to-var-is-that-really-the-question/

La mia comprensione era che in Python "tutto è pubblico" o qualcosa in tal senso. In C #, il progettista del modulo decide cosa è pubblico e cosa non lo è, quindi quando lo fai importottieni solo l'API pubblica comunque. Questo potrebbe essere un motivo per la differenza che stai descrivendo.

lo sviluppo di C # è effettivamente inseparabile dall'IDE che usi?

Nel mio lavoro precedente usavo principalmente vim per scrivere codice in linguaggi come C #, JavaScript, Powershell, Perl, C ++ e molti sviluppatori erano soliti fare qualcosa di simile. Il progetto era troppo grande per Visual Studio.

Detto questo, la maggior parte degli sviluppatori C # si occupa di progetti molto più piccoli e sono abbastanza felici di usare VS.

Questa è una visione interessante sullo sviluppo di C #. Ciò che stai chiedendo va oltre C #, se stai chiedendo dell'IDE.

Come dici tu, in Python puoi usare vari editor per scrivere il tuo codice. Puoi farlo anche con .NET framework. Esistono anche altri strumenti IDE che è possibile utilizzare come SharpDevelop. Visual Studio è sviluppato in stretta collaborazione con .NET Framework ed è relativamente costoso. Esistono strumenti come SharpDevelop e le versioni "Express" di VS per invogliare un numero maggiore di sviluppatori a utilizzare .NET. Fondamentalmente tutto ciò che un IDE fa per te è fornire un ambiente organizzato, di solito con intellisense, componenti aggiuntivi per la produttività e un "aiuto" per assemblare ciò che può finire per essere una riga di comando dall'aspetto molto spaventoso da passare al compilatore. Lo stesso vale per Java, strumenti come Eclipse forniscono solo miglioramenti organizzativi e di produttività per noi. Sotto il cofano, non accade nulla di magico finché non costruisci o compili il tuo progetto e quel rispetto,

Quando parli dell'istruzione "using" in C # e la confronti con Python, non è proprio la stessa cosa che succede sotto il cofano. Le istruzioni using sono usate dal compilatore per aiutare il suo sforzo nel trasformare il codice C # in MSIL. In MSIL non esiste una direttiva "importa tutte queste classi da questo spazio dei nomi". Dal momento che il time code è a livello di MSIL, tutte le classi sono state taggate con i loro nomi completi. Queste dichiarazioni "utilizzo" e "importazione" servono a facilitare la leggibilità umana. Non sono comandi di ottimizzazione del compilatore. Dopo che tutto questo "tagging iniziale di nomi pienamente qualificati" è andato avanti, potrebbe esserci una sorta di "minimizzazione" di basso livello agli FQN, ma ciò serve ad aiutare il compilatore / interprete ad eseguire più velocemente.

Un'ultima differenza fondamentale tra tutti questi linguaggi citati qui è che alcuni di essi sono interpretati dalle macchine virtuali, alcuni sono interpretati in stile JIT e altri sono completamente compilati. Il modo in cui queste direttive sull'utilizzo sono implementate in quei compilatori e interpreti differisce notevolmente.

HTH.

Penso che storicamente la risposta sia praticamente sì: far funzionare lo sviluppo C # in modo efficace in qualsiasi cosa al di fuori di Visual Studio, Xamarin o SharpDevelop è stata un'esperienza davvero spiacevole.

Ma recentemente sono emersi molti progetti che lo rendono più semplice, ad esempio:

OmniSharp fornisce una base per intellisense e refactoring, insieme a plugin vim, emacs, atom e sublimi. In realtà non l'ho usato, quindi non so quanto funzioni bene, ma sembra promettente.

Generatori ASP.NET MVC di Yeoman , aiutano l'avvio di un nuovo progetto MVC (forse esistono altri generatori).

paket , un'alternativa a NuGet dove puoi effettivamente aggiungere pacchetti NuGet al tuo progetto dalla riga di comando e avere i tuoi file .csproj aggiornati (anche se c'era uno strumento da riga di comando NuGet, in realtà l'aggiornamento dei progetti per usare i pacchetti faceva parte dell'IDE integrazione, non strumenti da riga di comando).

Paket ha l'implicazione che devi adattare il tuo codice sorgente per usarlo - quindi se ti siedi come membro singolo in un team e vuoi usare un editor di testo per la codifica, e tutti gli altri usano Visual Studio, dovresti convincere tutti altro per adattare la soluzione alle tue esigenze :(

Quindi dovresti essere in grado di metterti in funzione, ma c'è ancora parecchio lavoro da fare per far funzionare la tua toolchain in modo efficiente.

Non più:

http://www.omnisharp.net/

OmniSharp è una famiglia di progetti Open Source, ciascuno con un obiettivo: consentire un ottimo sviluppo .NET nel TUO editor preferito.

È divertente dire Cross Platform .NET. Ma è ragionevole per qualcuno sviluppare .NET senza Visual Studio e Windows?

È divertente fare .NET su un Mac in Sublime? Ubuntu ed Emacs? Windows e Atom? Puoi usare il tuo editor PLUS e utilizzare grandi funzionalità come Intellisense (non solo il completamento automatico), Aggiungi riferimento, Formatta documento e molto altro. Sviluppa ovunque, distribuisci ovunque (e in Azure!)

Ho provato questo con subime3 e osx

Altri campioni a

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