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

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

D'altra parte, qualunque sia la lingua che si impara, si raccomanda di usare la riga di comando all'inizio, in modo da poter capire meglio come funziona. C # non è un'eccezione.

is C# development effectively inseparable from the IDE you use?

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

BTW Se ti senti inopportuno con using foo , puoi usare l'intero percorso quando usi un tipo.

The idea of being dependent on an IDE to understand code at such a basic level seems anathema.

Non è una questione di comprensione del tuo codice: dato un 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 tuoi riferimenti in modo efficiente è un argomento completamente diverso: adoro la capacità di trovare utilizzi delle variabili Java in Eclipse tanto quanto amo trovare i punti di dichiarazione in Visual Studio, sia per C # che per C ++. Preferisco passare il mio tempo a programmare, piuttosto che cercare i punti di dichiarazione manualmente. Questo è simile al fare matematica: posso moltiplicare i numeri multidigit su un pezzo di carta, ma preferisco usare la calcolatrice per risparmiarmi un minuto o due.

Partendo 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 che si attraversano diverse migliaia di linee, avere un IDE aiuta a prescindere dalla lingua. Questo 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 permettono di aumentare le dimensioni critiche in cui l'IDE diventa utile. Ad esempio, è possibile 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 con this. anche in contesti in cui tale qualifica non è richiesta.

Questi trucchi sono accompagnati da compromessi: quasi inevitabilmente rendono il tuo programma meno leggibile oscurando i nomi o inserendo i riferimenti espliciti che l'incapsulamento era destinato a nascondere. Di fronte alla scelta, scelgo un codice dall'aspetto pulito più un IDE su un codice meno pulito all'infuori di un IDE. Riconosco pienamente, tuttavia, che le scelte degli altri potrebbero differire dalle mie.

Many Python programmers prefer a text editor approach to coding, using something like Sublime Text 2 or vim, where it's all about the code, plus command line tools and direct access and manipulation of folders and files.

È grandioso, ma manca il punto dell'IDE IDE. Il punto di un IDE come VS è il rapido supporto allo sviluppo tramite strumenti di codice potenti come il refactoring e l'intellisense. VS è un ottimo editor molto per il codice C #.

Ora C # consente di codificare in uno stile che dipende dal suo IDE in misura maggiore (puoi usare molte parole chiave%% di% di e simili). Alcuni preferiscono essere più espliciti, ad esempio usando alias di namespace per essere chiari su quale spazio dei nomi appartiene una classe (come var in Java o Python). È più una scelta di stile di codifica che una caratteristica della lingua.

Siccome C # è tipizzato staticamente (sebbene con alcune estensioni dinamiche, come in v4) è sempre abbastanza facile scoprire a quali tipi si fa riferimento - se sono sbagliati il codice non verrà compilato, e VS non lo è l'unico IDE con supporto per C # intellisense. Probabilmente è il migliore però.

Sviluppare C # senza un IDE potente (come VS) è come martellare a mano le unghie quando si dispone già di un nail art ad alta gamma - potrebbe esserci il tempo dispari per farlo, ma i professionisti usano lo strumento giusto per il lavoro.

Direi che lo stesso è probabilmente vero anche per Java. Se c'è un potente IDE con strumenti di intellisense e refactor del codice là fuori, probabilmente dovresti usarlo.

Tuttavia, guardate il contrario - se non volete intellisense, compilare il controllo del timecode e l'analisi del codice / refactoring, allora un IDE gonfio non è la strada da percorrere, e nemmeno uno è un linguaggio tipizzato staticamente. Penso che sia il contrario:

Many programmers that prefer a text editor approach to coding don't gain as much from statically typed languages (like C# and Java) and so could be better off if they stick to dynamic ones like Python and Javascript.

Penso:

• Le lingue dinamiche si adattano agli strumenti leggeri (gli IDE pesanti offrono meno vantaggi qui)
• I linguaggi statici si adattano a potenti IDE (gli strumenti possono aiutare il codice al costo della flessibilità)

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

Questo approccio ha molti aspetti positivi e negativi, che potrebbero essere discussi a lungo (ad esempio, considerare i pro e i contro delle piattaforme aperte e chiuse, come PC vs Xbox), ma alla fine della giornata, gli strumenti di Microsoft è ciò che la maggior parte delle persone usa. La società ha anche dimostrato che il loro processo decisionale è spesso una sorta di "dare il massimo valore alla maggior parte dei nostri utenti", sempre alla ricerca di compromessi pratici (più di recente - considera tipografico ). Quindi, in sostanza, non sarei sorpreso di scoprire che lo sviluppo di C # è stato / è 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 Python-esque usando le istruzioni.

using FooBar=MyName.Foo.FooBar; 

È semplicemente non è la norma perché non è così facile. Tuttavia, penso che dovresti preoccuparti di meno di sapere esattamente da dove viene esattamente ogni classe. Però non capisco l'intero punto di farlo in questo modo in Python.

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

Qualcuno si preoccupa di leggere fino qui ??

Riassumo dicendo che la funzionalità IDE massicciamente complessa è indispensabile e che (dovrebbe) evolvere nello Zen di Sublime Vimness un giorno ....

Il nostro software è composto da 129 progetti di circa 2M LOC. Aggiungete la massività del framework .NET e dato tutto ciò che posso dire è che l'IDE è vitale, trascendendo le motivazioni della domanda di questo thread.

Informazioni dettagliate sulla base del codice

Periodo. Conoscete il tipo di caratteristiche di cui stiamo parlando; tranne che la sua convenienza diventa indispensabile ed essenziale con il tipo di codice di base con cui ho a che fare.

Scrivo codice migliore a causa dell'IDE. Aggiungo sempre messaggi personalizzati ai miei test Nunit perché è facile, veloce e preciso. Io preferisco le enumerazioni sulle stringhe dovute in gran parte all'intelligence. Non esito a usare la denominazione descrittiva / lunga: un'istruzione multilinea è composta veloce e pulita.

Ma anche questa intelligenza è troppo a volte. Io uso spesso la ricerca di testo "trova nei file" di buona conoscenza.

Guida alla codifica

Qui è dove piango "abbastanza!". Immagina uno schermo pieno di dozzine di colori per lo più obscureatta, qualche particolare variabile evidenziata in ogni punto, rinforzo evidenziando oscurando ciò che è effettivamente la controfigura, sottolineando ondulati ovunque perché "esso" vuole che io scriva letteratura e non codice, icone per i menu contestuali di Resharper (tu devi solo fare clic su di esso! quindi ignorarlo per la maggior parte del tempo), un popup di aiuto per la firma che copre i 2/3 dello schermo in orizzontale, visualizzando in verticale diversi sovraccarichi, un popup a causa di dove ti è capitato di lasciare il cursore del mouse .... I non posso nemmeno vedere la riga & ^!% * s * del codice su cui sto lavorando!

Vis.Stud. ha bisogno di abbracciare il minimalismo quindi posso concentrarsi sulla codifica e non passare attraverso centinaia (migliaia se conti ogni impostazione di codifica a colori e tutti quei plugin) di impostazioni in una battaglia persa per reclamare la sanità mentale. Una chiave " Pareto " sarebbe ottima.

is C# development effectively inseparable from the IDE you use?

Certo che 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 usarlo.

Ricorda, C # è una lingua tipizzata. Se importi diversi domini che hanno la stessa classe, otterrai un errore di compilazione.

Personalmente non uso molto le dichiarazioni di tipo in alcun modo. Invece io uso la parola chiave var invece per i motivi che descrivo qui: link

is C# development effectively inseparable from the IDE you use?

Nel mio precedente lavoro stavo principalmente usando vim per codificare in linguaggi come C #, JavaScript, Powershell, Perl, C ++, e parecchi sviluppatori usavano fare qualcosa di simile. Il progetto era troppo grande per Visual Studio.

Detto questo, molti sviluppatori di C # si occupano di progetti molto più piccoli e sono abbastanza felici di usare VS.

Ho capito che in Python "tutto è pubblico" o qualcosa del genere. In C #, il progettista del modulo decide cosa è pubblico e cosa no, quindi quando si fa un import si ottiene comunque solo l'API pubblica. Questo potrebbe essere un motivo per la differenza che stai descrivendo.

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

Come dici tu, in Python puoi usare vari editor per scrivere il tuo codice. Puoi farlo anche con il framework .NET. Ci sono anche altri strumenti IDE che puoi usare come SharpDevelop. Visual Studio è strettamente co-sviluppato con .NET Framework ed è relativamente costoso. Strumenti come SharpDevelop e le versioni "Express" di VS esistono per invogliare più sviluppatori a utilizzare .NET. Essenzialmente tutto ciò che un IDE fa per te è fornire un ambiente organizzato, di solito con intellisense, componenti aggiuntivi per la produttività e un "aiutante" per assemblare ciò che può sembrare una linea di comando dall'aspetto molto spaventoso da passare al compilatore. Lo stesso vale per Java, strumenti come Eclipse forniscono solo l'organizzazione e miglioramenti di produttività per noi. Sotto il cofano, nulla di magico accade fino a quando non costruisci o compili il tuo progetto e quel rispetto, tutti gli IDE sono solo belle facce per il compilatore ostile.

Quando parli dell'istruzione "using" in C # e la confronti con Python, non è proprio la stessa cosa che sta succedendo 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 alcuna direttiva "importa tutte queste classi da questo spazio dei nomi". Dal momento che il codice temporale è a livello di MSIL, tutte le classi sono state taggate con i loro nomi completi. Queste istruzioni "using" e "import" sono di ausilio alla leggibilità umana. Non sono comandi di ottimizzazione del compilatore. Dopo che tutto questo iniziale "tagging dei nomi completi" è andato avanti, potrebbe esserci una sorta di "minify" di basso livello per gli FQN, ma questo è per aiutare il compilatore / interprete ad eseguire più velocemente. Questa è l'ottimizzazione - ma non c'è alcun controllo di questo offerto allo sviluppatore, a meno che tu non stia scrivendo la tua versione personalizzata del compilatore!

Un'ultima differenza fondamentale tra tutti questi linguaggi menzionati qui è che alcuni di essi sono interpretati da VM, alcuni sono interpretati in stile JIT e alcuni sono completamente compilati. Il modo in cui queste direttive di utilizzo vengono implementate su quei compilatori e gli interpreti differisce notevolmente.

HTH.

Penso che storicamente la risposta sia più o meno, sì - ottenere lo sviluppo C # attivo e funzionante in qualsiasi cosa al di fuori di Visual Studio, Xamarin o SharpDevelop è stata un'esperienza troppo spiacevole.

Recentemente sono emersi molti progetti che rendono più semplice, ad esempio:

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

I generatori Yeoman ASP.NET MVC , aiutano a eseguire il bootstrap di un nuovo progetto MVC (forse esistono altri generatori).

paket , un'alternativa a NuGet in cui puoi effettivamente aggiungere pacchetti NuGet al tuo progetto dalla riga di comando e avere il tuo File .csproj aggiornati (sebbene esistesse uno strumento da riga di comando NuGet, l'aggiornamento effettivo dei progetti per utilizzare i pacchetti era parte dell'integrazione IDE, non degli 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, avresti per convincere tutti gli altri ad adattare la soluzione alle proprie esigenze: (

Quindi dovresti essere in grado di essere attivo e funzionante, ma c'è ancora molto lavoro da fare per rendere efficiente la tua catena di strumenti.

Non più:

link

OmniSharp is a family of Open Source projects, each with one goal - To enable great .NET development in YOUR editor of choice.

It’s fun to say Cross Platform .NET. But is it reasonable for someone to develop .NET without Visual Studio and Windows?

Is it fun to do .NET on a Mac in Sublime? Ubuntu and Emacs? Windows and Atom? You can use your editor PLUS get to use great features like Intellisense (not just Autocomplete), Add Reference, Format Document, and lots more. Develop anywhere, deploy anywhere (and to Azure!)

L'ho provato con subime3 e osx

Altri campioni

link