Le développement de C # est-il effectivement indissociable de l'EDI que vous utilisez?

41

Je suis un programmeur Python qui apprend le C # et qui essaie d'arrêter de s'inquiéter. J'adore le C # pour ce qu'il est, plutôt que de le comparer constamment à Python.

Je suis rattrapé par un point: le manque de précision sur la définition des choses, comme détaillé dans cette question de débordement de pile . En bref: en C #, using foone vous dit pas quels noms foosont disponibles, ce qui est analogue à from foo import *Python - une forme déconseillée dans la culture de codage Python pour être implicite plutôt que l'approche plus explicite de from foo import bar.

Les réponses des programmeurs C # à ce sujet m'ont beaucoup frappé, c'est qu'en pratique, ce manque de clarté n'a pas d'importance, car dans votre IDE (vraisemblablement Visual Studio), vous pouvez survoler un nom et être informé par le système d'où vient le nom. Par exemple:

Maintenant, en théorie, je réalise que cela signifie que lorsque vous regardez avec un éditeur de texte, vous ne pouvez pas dire d'où viennent les types en C # ... mais dans la pratique, cela ne me pose pas de problème. À quelle fréquence consultez-vous le code et ne pouvez-vous pas utiliser Visual Studio?

Ceci est révélateur pour moi. De nombreux programmeurs Python préfèrent une approche de codage avec un éditeur de texte, utilisant quelque chose comme Sublime Text 2 ou vim, où il est question de code, d'outils de ligne de commande, d'accès direct et de manipulation de dossiers et de fichiers. L'idée de dépendre d'un IDE pour comprendre le code à un niveau aussi bas semble anathème. Il semble que la culture C # soit radicalement différente sur ce point. Et je me demande si je dois simplement accepter et accepter cela dans le cadre de mon apprentissage du C #.

Ce qui m'amène à ma question ici: le développement de C # est-il effectivement indissociable de l'EDI que vous utilisez?

Ghopper21
la source
7
Python est un langage dynamique, C # typé de manière statique (comme Java), la manière dont vous codez est donc très différente.
Oded
6
@Oded: using MyType = MyNamespace.MyType;?
pdr
4
Je ne sais pas à quoi ça ressemble en Python, mais en C #, vous pouvez toujours commencer global::et travailler à partir de là. usingne rend rien disponible qui ne l'était pas auparavant; cela facilite seulement l'accès (comme dans le cas où il est moins nécessaire de taper pour utiliser une classe particulière).
un CVn
5
"De nombreux programmeurs Python préfèrent une approche de codage utilisant un éditeur de texte, utilisant quelque chose comme Sublime Text 2 ou vim, où il est question de code, d'outils de ligne de commande, d'accès direct et de manipulation de dossiers et de fichiers." - Ce qui me semble horriblement inefficace. Un IDE est un outil qui vous aide à être plus productif. Bien sûr, vous pouvez construire une maison avec un marteau et une scie à la main et couper les arbres vous-même, mais je pense que vous auriez une période beaucoup plus rapide avec des outils électriques et l’achat de bois débité.
Andy
2
@Andy - Je vois que ça sonne comme ça. Mais ces éditeurs de texte sont en réalité très puissants et offrent une tonne d'outils permettant d'optimiser l'efficacité des programmeurs. Il s’agit simplement d’une manière radicalement différente d’obtenir et d’utiliser ces outils et fonctionnalités par rapport à un IDE (et qui peut être plus ou moins appropriée pour certaines langues / cultures de programmation).
Ghopper21

Réponses:

26

Visual Studio est tellement pratique qu’après avoir travaillé pendant un moment, il est difficile d’utiliser un IDE différent. Il a beaucoup d'outils pratiques et une multitude de plugins disponibles, il a donc pratiquement toutes les fonctionnalités dont vous auriez besoin.

D'autre part, quelle que soit la langue que vous apprenez, il est recommandé d'utiliser la ligne de commande au début pour mieux comprendre son fonctionnement. C # n'est pas une exception.

Le développement de C # est-il effectivement indissociable de l'EDI que vous utilisez?

Théoriquement non, mais pratiquement oui. Il est possible d'écrire en C # à l'aide d'un éditeur de texte et d'une ligne de commande, mais si vous avez Visual Studio, vous ne le ferez jamais. En fait, très peu de programmeurs ont déjà exécuté du code C # en ligne de commande.

BTW Si vous ne vous sentez pas à l'aise avec using foo, vous pouvez utiliser le chemin complet lorsque vous utilisez un type.

SuperM
la source
9
SharpDevelop et MonoDevelop sont des IDE alternatifs à Visual Studio.
Oded
@Oded, je ne les ai jamais utilisées, mais il est intéressant de jeter un coup d'œil. Merci))
superM
Merci, superM - pouvez-vous donner un aperçu des types de fonctionnalités qui rendent Visual Studio si indispensable? Je sais que le code est très bien complété, mais quoi d'autre? Cela ressemble-t-il plus ou moins à Eclipse pour C #, ou y a-t-il quelque chose de plus spécifique à ce sujet sur lequel les développeurs C # s'appuient?
Ghopper21
2
@ Ghopper21: Je suggérerais qu'il est plus comparable à IntelliJ qu'à Eclipse (surtout si vous incluez Resharper), sauf que, dans le monde .NET, les plug-ins de communauté sont généralement écrits pour Visual Studio.
pdr
5
+1: Je suis d'accord, alors que vous pouvez écrire du code en ligne de commande avec le bloc-notes, vous seriez un idiot d'ignorer les outils que VS ou Sharp Develop apporte à la table.
Binary Worrier
33

L'idée de dépendre d'un IDE pour comprendre le code à un niveau aussi bas semble anathème.

Ce n’est pas une question de compréhension de votre code: avec suffisamment de temps, vous pouvez toujours localiser la bonne variable avec un éditeur de texte de base ou même dans une impression. En ce qui concerne la compréhension du code, la dépendance à l'IDE n'existe absolument pas.

La localisation efficace de vos références est un sujet totalement différent: j'aime autant la capacité de trouver des utilisations des variables Java dans Eclipse que celle de rechercher des points de déclaration dans Visual Studio, aussi bien en C # qu'en C ++. Je préfère passer mon temps à coder plutôt que de chercher des points de déclaration manuellement. C'est comme faire des maths: je peux multiplier des nombres à plusieurs chiffres sur un morceau de papier, mais je préfère utiliser une calculatrice pour gagner une minute ou deux.

Partant d'une certaine "taille critique" du code, un bon IDE devient très utile quel que soit le langage de programmation. La taille peut varier d'une langue à l'autre, mais une fois que vous avez traversé plusieurs milliers de lignes, le fait d'avoir un IDE vous aide quelle que soit votre langue. Cela a plus à voir avec les limites de l'esprit humain qu'avec un langage de programmation particulier: à un moment donné, votre mémoire à court terme est vouée au "débordement".

Il existe des astuces vous permettant d'augmenter cette taille critique pour laquelle l'EDI devient utile. Par exemple, vous pouvez suivre une convention de dénomination (les noms hongrois ont déjà été importants dans le monde C ++, en particulier chez les utilisateurs de Windows). Une autre astuce courante consiste à qualifier des variables d'instance this.même dans des contextes où une telle qualification n'est pas requise.

Ces astuces impliquent des compromis: presque inévitablement, elles rendent votre programme moins lisible en masquant les noms ou en insérant les références explicites que l’encapsulation était censée masquer. Face au choix, je choisis un code épuré plus un IDE par rapport à un code moins épuré moins un IDE. Je reconnais toutefois pleinement que les choix des autres peuvent différer des miens.

dasblinkenlight
la source
1
J'aurais probablement dû dire «lire rapidement le code» ... C'est un changement de mentalité pour moi de ne pas avoir toutes les références dans le même fichier source, mais d'utiliser des outils pour localiser ces références.
Ghopper21
5
Non pas que je ne pouvais pas choisir d’utiliser thisidiosyncratiquement - mais coder n’est pas un art isolé et je pense que c’est mieux de suivre (ou au moins de commencer) avec les normes d’une culture de codage - c’est-à-dire être "Pythonic" avec Python et quelle que soit la "voie C #" équivalente est avec C #. Et il ressort clairement des réponses et des commentaires ici que l’utilisation d’un bon IDE comme Visual Studio est au cœur de la "méthode C #" (si c’est la bonne façon de le dire).
Ghopper21
3
@ Ghopper21 Ce que vous rencontrerez avec C # n'est pas que vous ne pouvez pas l'écrire sans IDE, mais que la grande majorité du code C # a été écrit dans un IDE et que tous les développeurs l'utilisent. Ce fait, combiné à intellisense, fait tomber les développeurs dans le piège de la mémoire google, car des études ont évoqué huffingtonpost.com/2011/07/15/… "Selon les conclusions de ces études, les personnes ayant accès à l'index Web massif de Google sont moins susceptibles de ils se rappellent un fait à l'invite, mais ils se souviennent où et comment le localiser en ligne "
Jimmy Hoffa
2
@ Ghopper21 Je ne dis pas que ce piège mémoire est mauvais , c'est une source de productivité extrêmement accrue pour la plupart des gens. C'est pourquoi seuls ceux qui ont de longs souvenirs de l'époque où ils pouvaient mémoriser l'intégralité de l'API avec laquelle ils travaillaient s'en plaignaient vraiment. Je signale simplement cela parce que cela affecte directement le code C # que vous allez lire, ainsi que le style et la culture du développement C #.
Jimmy Hoffa
1
Je ne suis jamais vraiment tombé sur les API bios / low dos dos; mais ma langue maternelle / environnement était Borland TurboPascal; et j'ai probablement eu ~ 90% de la bibliothèque de langage / standard mémorisée à un moment donné. Les principales exceptions sont liées à l’incapacité complète de comprendre ce qui était supposé être OO.
Dan Neely
8

De nombreux programmeurs Python préfèrent une approche de codage avec un éditeur de texte, utilisant quelque chose comme Sublime Text 2 ou vim, où il est question de code, d'outils de ligne de commande, d'accès direct et de manipulation de dossiers et de fichiers.

C'est génial, mais ça manque le but de VS IDE. L’intérêt d’un IDE comme VS est un support de développement rapide via des outils de code puissants tels que le refactoring et intellisense. VS est un très très bon éditeur pour le code C #.

Maintenant, C # vous permet de coder dans un style qui dépend davantage de son IDE (vous pouvez utiliser beaucoup de varmots-clés, etc.). Certaines personnes préfèrent être plus explicites, par exemple en utilisant des alias d'espace de nom pour indiquer clairement à quel espace de nom appartient une classe (comme importen Java ou en Python). C'est plus un choix de style de codage qu'une caractéristique de la langue.

Comme C # est typé de manière statique (bien qu'avec certaines extensions dynamiques à partir de la v4), il est toujours assez facile de savoir à quels types font référence, le code ne sera pas compilé et VS ne sera pas le seul. avec le support de C # intellisense. C'est probablement le meilleur cependant.

Développer C # sans un IDE puissant (comme VS), c'est un peu comme enfoncer des clous à la main quand on a déjà un clou haut de gamme - il se peut qu'il y ait des moments où il faut le faire, mais les professionnels utilisent le bon outil pour le poste. .

Je dirais qu'il en va probablement de même pour Java. S'il existe un IDE puissant avec des outils intellisense et de refactorisation de code, vous devriez probablement l'utiliser.

Cependant, voyez l'inverse: si vous ne voulez pas intellisense, compilez la vérification du code temporel et l'analyse / le refactoring, alors un IDE gonflé n'est pas la solution, pas plus qu'un langage à typage statique. Je pense que c'est l'inverse:

Beaucoup de programmeurs qui préfèrent une approche de codage par un éditeur de texte ne gagnent pas autant aux langages à typage statique (comme C # et Java) et pourraient donc s'en trouver mieux s'ils s'en tiennent à des langages dynamiques comme Python et Javascript.

Je pense:

  • Les langages dynamiques conviennent aux outils légers (les IDE lourds confèrent ici moins d'avantages)
  • Les langages statiques conviennent à des IDE puissants (des outils peuvent aider avec le code au détriment de la flexibilité)
Keith
la source
+1 pour la citation inversée.
fbmd
5

Pour répondre à votre question: bien que cela change lentement, l’environnement de développement Microsoft est en grande partie une monoculture .

Cette approche présente de nombreux avantages et inconvénients, qui pourraient être discutés longuement (par exemple, examiner les avantages et les inconvénients des plates-formes ouvertes et fermées, telles que les ordinateurs personnels par rapport à une Xbox), mais au bout du compte, les outils de Microsoft les gens utilisent. La société a également montré que sa prise de décision est souvent une sorte de processus consistant à "donner le plus de valeur à la majorité de nos utilisateurs", toujours à la recherche de compromis pratiques (le plus récemment: envisager une typographie ). Donc, fondamentalement, je ne serais pas surpris de constater que le développement de C # était / est fait avec l’outillage (VS) à l’esprit.

Daniel B
la source
À propos, on pourrait faire valoir que Python est aussi sa propre monoculture, étant donné le fort attachement à ce qui est considéré comme "pythonique" dans le style et l'approche de codage, ainsi que le principe de base de la conception du langage, qui consiste à avoir une manière claire et évidente de faire les choses. J'ai tendance à penser que la programmation de monocultures dans ce sens peut être très bonne, car cela crée une communauté cohérente et un code partageable. C'est juste (dommage? Et / ou une occasion d'élargir mon esprit?) Que les cultures Python et C # sont si ... différentes!
Ghopper21
2
@ Ghopper21 C'est un très bon point à propos de Python. Je pense que la version MS de "il devrait y avoir un seul moyen évident de le faire" s'étend au choix de l'IDE :)
Daniel B
4

D'une part, C # n'est pas Python .. Il existe différentes méthodologies de conception.

Maintenant, pour répondre à votre question, il est tout à fait possible d’utiliser votre déclaration Python à l’aide de déclarations.

using FooBar=MyName.Foo.FooBar; 

C'est juste que ce n'est certainement pas la norme parce que ce n'est pas si facile. Cependant, je pense que vous devriez moins vous préoccuper de savoir exactement d'où vient exactement chaque classe. Je ne comprends pas tout l'intérêt de le faire de cette façon en Python.

Et aussi, C # est un langage qui se prête très bien à l’utilisation des IDE pour le rendre plus facile. Intellisense est incroyablement simple à mettre en œuvre, notamment par rapport aux langages dynamiques tels que Ruby et Python. Cependant, vous n'êtes pas obligé d'être collé à votre IDE. J'ai entendu parler de personnes utilisant Eclipse. Il existe aussi bien sûr MonoDevelop (que j'utilise souvent) et vous pouvez même travailler à partir d'une ligne de commande. Parfois, sur mon serveur, je vais éditer des fichiers C # avec vi, puis utiliser xbuildpour les reconstruire ... C'est juste que l'utilisation d'un IDE rend les choses beaucoup plus faciles comparées à la ligne de commande pour des cas typiques.

Earlz
la source
4

Quelqu'un prend la peine de lire bien ici ??

Je résume en disant que la fonctionnalité extrêmement complexe de l'EDI est indispensable et qu'elle évoluera (devrait) évoluer vers le zen du sublime VimNess un jour ou l'autre ....

Notre logiciel consiste en 129 projets d'environ 2 millions de LOC. Ajoutez à cela la massivité du framework .NET et tout ce que je peux dire, c'est que l'IDE est vital, transcendant les motivations de la question de ce fil.

Aperçu de la base de code

Période. Vous connaissez les types de fonctionnalités dont nous parlons; sauf que sa commodité devient indispensable et indispensable avec le type de base de code que je traite.

J'écris un meilleur code à cause de l'IDE. J'ajoute toujours des messages personnalisés à mes tests Nunit parce que c'est facile, rapide et précis. Je préfère les énumérations aux chaînes dues en grande partie à intellisense. Je n'hésite pas à utiliser une dénomination descriptive / longue: une instruction multiligne se compose rapidement et proprement.

Mais même cette intelligence est parfois trop. J'utilise souvent le bon vieux "recherche dans les fichiers" la recherche de texte.

Aide au codage

Voici où je pleure souvent "assez!". Imaginez un écran plein avec une douzaine de couleurs essentiellement obscureatta, une variable particulière mise en évidence partout, une accolade soulignant obscurcissant ce qu'est l'accolade, un soulignement ondulé partout car "il" veut que j'écrive de la littérature, pas du code, des icônes pour les menus contextuels Resharper (vous il suffit de cliquer dessus! puis de l’ignorer la plupart du temps), une fenêtre d’aide à la signature recouvrant les 2/3 de l’écran horizontalement, affichant verticalement plusieurs surcharges, une fenêtre contextuelle car vous venez de laisser le curseur de la souris .... I Je ne peux même pas voir la & ^!% ligne * s * de code sur laquelle je travaille!

Vis.Stud. doit adopter le minimalisme pour que je puisse me concentrer sur le codage et ne pas passer par des centaines (des milliers si vous comptez tous les paramètres de codage couleur et tous ces plugins) de paramètres dans une bataille perdue pour récupérer la santé mentale. Une clé " Pareto " serait géniale.

radarbob
la source
1
Vraiment apprécié vos pensées ici, car vous semblez vraiment "comprendre" à la fois en termes d'approches IDE et "Sublime VimNess". Je suis avec vous dans tout ce que vous dites ici. En espérant que cela se produise.
Ghopper21
3

Le développement de C # est-il effectivement indissociable de l'EDI que vous utilisez?

Bien sûr que non. Pourquoi n'importeriez-vous pas tout l'espace de noms? Le choix d'utiliser un IDE intégré ou un éditeur de texte n'a rien à voir avec cela. L'importation de l'espace de noms entier ne rend pas plus difficile la lecture ou l'utilisation du code.

Rappelez-vous que C # est un langage typé. Si vous importez plusieurs espaces de noms ayant la même classe, vous obtiendrez une erreur de compilation.

Personnellement, je n'utilise pas beaucoup les déclarations de type dans les deux cas. Au lieu de cela, j'utilise le varmot clé à la place pour les raisons que je décris ici: http://blog.gauffin.org/2012/08/to-var-or-not-to-var-is-that-really-the-question/

Jgauffin
la source
1
Le problème est en train de lire, pas d'écrire du code. (La question de débordement de pile à laquelle je renvoie ci-dessus donne un exemple.) Lors de la lecture du code, comment savoir d'où vient quelque chose? Avec Python, vous pouvez rechercher une importation explicite (en supposant que le code respecte les conventions strictes de Python pour l’utilisation de telles importations). Avec C #, le consensus semble être que, dans la pratique, vous utilisez un IDE comme VS.
Ghopper21
Si vous ne savez pas d'où vient la classe, vous devrez probablement la regarder de toute façon pour savoir comment elle fonctionne. Il suffit de google msdn <classname>et cliquez sur le premier lien. Là vous obtenez l'espace de noms aussi.
Jgauffin
Cette approche illustre la différence culturelle. Non pas que les programmeurs Python ne fassent pas des recherches sur Google - bien sûr, ils le font - c'est simplement que la façon de penser est différente.
Ghopper21
Sur une note séparée, var en C # est un joli raccourci syntatique sucre / compilateur que j’aime bien pour rendre le code moins verbeux et répétitif. J'aimerais que vous puissiez l'utiliser partout, pas seulement à l'intérieur des méthodes.
Ghopper21
@ Ghopper21: Oui, je sais. Mon point est que Google indexe assez bien MSDN et vous obtiendrez la documentation directement en le faisant. Par conséquent, vous n'avez vraiment pas besoin de documenter chaque classe que vous utilisez en incluant le chemin d'accès complet.
Jgauffin
1

D'après ce que j'avais compris, en Python, "tout est public" ou quelque chose de similaire. En C #, le concepteur de module décide ce qui est public et ce qui ne l’est pas. Ainsi, lorsque vous le faites, vous n’obtenez importque l’API publique. Cela pourrait expliquer la différence que vous décrivez.

Scott Whitlock
la source
C'est certainement une grande différence entre Python et C #, mais cela ne m'aide pas vraiment à comprendre pourquoi il y a un tel manque de clarté dans les importations. Comme @pbr l'a noté dans son commentaire, Java (qui a également la distinction public / privé) est similaire à Python dans sa préférence culturelle pour les importations explicites.
Ghopper21
5
@ Ghopper21 - La seule raison de préférer les importations explicites en Java (et C ++ par exemple) est d'empêcher les collisions de noms. C # a pris la décision de conception pour faire face à ce problème via des alias import / type, car ils mieux gérer lorsque vous réellement avez une collision de nom ainsi que l'avantage de ne pas avoir un tas d'importations qui encombrent boilerplate votre source.
Telastyn
1

Le développement de C # est-il effectivement indissociable de l'EDI que vous utilisez?

A mon emploi précédent, j'utilisais principalement vim pour coder dans des langages tels que C #, JavaScript, Powershell, Perl, C ++ et bon nombre de développeurs faisaient auparavant quelque chose de similaire. Le projet était trop volumineux pour Visual Studio.

Cela dit, la plupart des développeurs C # traitent de projets beaucoup plus petits et sont plutôt heureux d’utiliser VS.

Nemanja Trifunovic
la source
0

C'est une vue intéressante sur le développement en C #. Ce que vous demandez va au-delà de C #, si vous posez des questions sur l'EDI.

Comme vous le dites, en Python, vous pouvez utiliser différents éditeurs pour écrire votre code. Vous pouvez également le faire avec le framework .NET. Il existe également d'autres outils IDE que vous pouvez utiliser, tels que SharpDevelop. Visual Studio est très étroitement développé avec le framework .NET et est relativement coûteux. Des outils tels que SharpDevelop et les versions "Express" de VS existent pour inciter davantage de développeurs à utiliser .NET. Essentiellement, tout un IDE fournit pour vous un environnement organisé, généralement avec intellisense, des modules complémentaires pour la productivité et un "assistant" pour assembler ce qui peut s'avérer être une ligne de commande très effrayante à transmettre à votre compilateur. Il en va de même pour Java. Des outils tels que Eclipse ne font que nous apporter des améliorations en termes d’organisation et de productivité. Sous le capot, rien de magique n’arrive jusqu’à ce que vous construisiez ou compiliez votre projet et ce respect,

Lorsque vous parlez de l'instruction "using" en C # et que vous la comparez à Python, ce n'est pas vraiment la même chose qui se passe sous le capot. Les instructions using sont utilisées par le compilateur pour l'aider à transformer le code C # en MSIL. Dans MSIL, il n'y a pas de directive "importer toutes ces classes de cet espace de noms". Lorsque le code temporel est au niveau MSIL, toutes les classes ont été étiquetées avec leur nom complet. Ces déclarations "using" et "import" sont destinées à améliorer la lisibilité humaine. Ce ne sont pas des commandes d'optimisation du compilateur. Une fois que tout ce "balisage initial des noms qualifiés" s'est poursuivi, il pourrait y avoir une sorte de "minify" de bas niveau pour les FQN, mais ceci aidera le compilateur / interprète à s'exécuter plus rapidement.

Une dernière différence fondamentale entre tous ces langages mentionnés ici est que certains d'entre eux sont interprétés par les VM, certains sont interprétés en style JIT et d'autres sont entièrement compilés. La manière dont ces directives d’utilisation sont mises en œuvre sur ces compilateurs et interprètes diffère considérablement.

HTH.

Lee James
la source
"Ces déclarations d'utilisation et d'importation sont destinées à améliorer la lisibilité." - Oui, c'est une différence philosophique clé au travail ici. La lisibilité au niveau textuel est un principe clé de conception Python de premier ordre. C # n’a pas strictement besoin, mais s’appuie pratiquement sur un bon IDE comme VS pour être "lisible". Incidemment, "importer" en Python est également plus qu'une question de lisibilité, contrairement à "utiliser" en C #.
Ghopper21
0

Je pense qu'historiquement, la réponse est quasiment oui, le développement de C # opérationnel dans des applications autres que Visual Studio, Xamarin ou SharpDevelop était tout simplement une expérience désagréable.

Mais récemment, beaucoup de projets sont apparus pour faciliter les choses, par exemple:

OmniSharp , fournit une base pour intellisense et le refactoring, ainsi que des plugins vim, emacs, atom et sublime. En fait, je ne l'ai pas utilisé, donc je ne sais pas si cela fonctionne bien, mais cela semble prometteur.

Yeoman ASP.NET MVC , aide à amorcer un nouveau projet MVC (peut-être qu’il existe d’autres générateurs).

Paket , une alternative à NuGet où vous pouvez réellement ajouter des packages NuGet à votre projet à partir de la ligne de commande et faire mettre à jour vos fichiers .csproj (bien qu’il existe un outil de ligne de commande NuGet, la mise à jour des projets pour utiliser les packages faisait partie de l’EDI intégration, pas d’outils de ligne de commande).

Paket implique que vous devez adapter votre code source à son utilisation. Par conséquent, si vous vous associez à un membre unique d'une équipe et souhaitez utiliser un éditeur de texte pour le codage, et que tout le monde utilise Visual Studio, vous devrez convaincre tout le monde. sinon adapter la solution à vos besoins :(

Vous devriez donc être en mesure de vous lancer et d’être opérationnel, mais il reste beaucoup de travail à faire pour que votre chaîne d’outils soit opérationnelle et efficace.

Pete
la source
-1

Plus maintenant:

http://www.omnisharp.net/

OmniSharp est une famille de projets Open Source ayant chacun un objectif: permettre un excellent développement .NET dans VOTRE éditeur de choix.

C'est amusant de dire Cross Platform .NET. Mais est-il raisonnable que quelqu'un développe .NET sans Visual Studio et Windows?

Est-ce amusant de faire .NET sur un Mac avec Sublime? Ubuntu et Emacs? Windows et Atom? Vous pouvez utiliser votre éditeur PLUS pour utiliser d’excellentes fonctionnalités telles que Intellisense (pas seulement la saisie semi-automatique), Ajouter une référence, Formater le document, etc. Développer n'importe où, déployer n'importe où (et sur Azure!)

J'ai testé cela avec Subime3 et OSX

Plus d'échantillons à

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

Mamcx
la source
Omnisharp permet d'utiliser C # avec des éditeurs de texte, tels que sublime et emacs. Alors pourquoi est-il voté?
Mamcx