C＃開発は、使用しているIDEと事実上切り離せませんか？

私はC＃を学習しているPythonプログラマーであり、心配するのをやめようとしています。

このスタックオーバーフローの質問で詳述されているように、物事が定義されている場所に関する明示性の欠如という点に私は追いついています。要するに、C＃では、using fooどの名前fooが利用可能になっているかを教えてくれません。これはfrom foo import *、Pythonに類似していますfrom foo import bar。

私はむしろC＃プログラマーからのこの点に対するスタックオーバーフローの回答に驚いていました。実際には、この明示性の欠如は実際には問題ではありませんでした名前が由来するシステム。例えば：

今、理論的には、これはテキストエディターで探しているときに、C＃で型がどこから来たのかわからないことを意味しますが、実際には、それが問題になることはありません。実際にコードを見て、Visual Studioを使用できない頻度はどれくらいですか？

これは私に啓示です。多くのPythonプログラマーは、Sublime Text 2やvimのようなコードに加えて、コマンドラインツールとフォルダーやファイルの直接アクセスと操作を使用して、コーディングにテキストエディターアプローチを好みます。このような基本レベルでコードを理解するためにIDEに依存するという考えは、忌み嫌われるようです。この点でC＃の文化は根本的に異なっているようです。そして、C＃の学習の一環として、それを受け入れて受け入れる必要があるのだろうか。

ここで私の質問に私を導きます：C＃開発は、使用しているIDEから事実上不可分ですか？

Visual Studioは非常に便利なので、しばらくの間作業した後、別のIDEを使用することは困難です。多くの便利なツールと多数のプラグインが利用できるため、実際には必要なすべての機能を備えています。

一方、どの言語を学んだとしても、最初にコマンドラインを使用することをお勧めします。そうすれば、コマンドラインの仕組みをよりよく理解できます。C＃は例外ではありません。

C＃開発は、使用しているIDEと事実上切り離せませんか？

理論的にはありませんが、実際にはあります。テキストエディターとコマンドラインを使用してC＃で記述できますが、Visual Studioを使用している場合は、これを行うことはできません。実際、コマンドラインからC＃コードを実行したプログラマーはほとんどいません。

ところでusing foo、に不便を感じている場合は、型を使用するときにパス全体を使用できます。

このような基本レベルでコードを理解するためにIDEに依存するという考えは、忌み嫌われるようです。

コードを理解することは問題ではありません。十分な時間を与えられれば、基本的なテキストエディターで、または印刷物でさえ、いつでも正しい変数を見つけることができます。コードを理解する限り、IDE依存関係は絶対に存在しません。

参照を効率的に見つけることはまったく別のテーマです。C＃とC ++の両方について、Visual Studioで宣言ポイントを見つけるのと同じくらい、EclipseでJava変数の使用を見つける機能が大好きです。宣言ポイントを手動で探すよりも、コーディングに時間を費やす方が好きです。これは数学をするのと似ています。紙の上に複数桁の数字を掛けることができますが、電卓を使って1〜2分節約できます。

コードの特定の「クリティカルサイズ」から開始すると、プログラミング言語に関係なく、優れたIDEは非常に役立ちます。サイズは言語によって異なる場合がありますが、一度数千行を超えると、IDEがあれば言語に関係なく役立ちます。これは、特定のプログラミング言語よりも人間の心の制限に関係しています。ある時点で、短期記憶は「オーバーフロー」に縛られます。

IDEが役立つ重要なサイズを大きくするためのトリックがあります。たとえば、命名規則に従うことができます（ハンガリー語の名前は、C ++の世界では、ある時点で、特にWindowsの実践者の間で大きかったです）。別の一般的なトリックはthis.、そのような修飾が必要でないコンテキストでもインスタンス変数を修飾することです。

これらのトリックにはトレードオフが伴います。ほとんど必然的に、名前を不明瞭にするか、カプセル化が隠そうとする明示的な参照を挿入することにより、プログラムが読みにくくなります。選択肢に直面して、私はきれいに見えるコードとIDEを選びます。ただし、他の人の選択は私の選択とは異なる可能性があることを完全に認識しています。

多くのPythonプログラマーは、Sublime Text 2やvimのようなコードに加えて、コマンドラインツールとフォルダーやファイルの直接アクセスと操作を使用して、コーディングにテキストエディターアプローチを好みます。

それは素晴らしいことですが、VS IDEのポイントを逃しています。VSのようなIDEのポイントは、リファクタリングやインテリセンスなどの強力なコードツールによる迅速な開発サポートです。VSは、C＃コードの非常に優れたエディターです。

C＃では、IDEに大きく依存するスタイルでコーディングできます（多くのvarキーワードなどを使用できます）。たとえば、クラスがどのネームスペースに属しているかを明確にするためにネームスペースエイリアスを使用することによりimport、JavaやPythonのように、より明示的にしたい人もいます。これは、言語の機能というよりもコーディングスタイルの選択です。

C＃は静的に型付けされているため（v4の時点でいくつかの動的拡張機能があります）、どの型が参照されているかを見つけるのは常にかなり簡単です-それらが間違っている場合、コードはコンパイルされず、VSは唯一のIDEではありませんC＃インテリセンスのサポート。おそらく最高でしょう。

強力なIDE（VSなど）を使用せずにC＃を開発することは、範囲の最高のネイルガンを既に持っているときに手で釘を打つようなものです。 。

同じことはおそらくJavaにも当てはまります。IntelliSenseとコードリファクタリングツールを備えた強力なIDEがある場合は、おそらくそれを使用する必要があります。

ただし、逆に見てください-インテリセンス、コンパイル時のコードチェック、コード分析/リファクタリングが必要ない場合は、肥大化したIDEを使用する方法ではなく、どちらも静的に型付けされた言語ではありません。私はそれが逆だと思う：

コーディングにテキストエディターのアプローチを好む多くのプログラマーは、静的に型付けされた言語（C＃やJavaなど）からそれほど得られないので、PythonやJavascriptのような動的な言語にこだわる方が良いでしょう。

おもう：

• 動的言語は軽量のツールに適しています（ここでは、重量のあるIDEのメリットはあまりありません）
• 静的言語は強力なIDEに適しています（ツールは柔軟性を犠牲にしてコードを支援できます）

あなたの質問に答えるために：マイクロソフトの開発環境は徐々に変化していますが、主に単一文化でした。

このアプローチには多くの長所と短所があり、長々と議論することができます（たとえば、PCとXboxなどのオープンプラットフォームとクローズプラットフォームの長所と短所を検討してください）が、結局のところ、Microsoftのツールは最も重要です人々が使用します。同社はまた、意思決定が多くの場合「大部分のユーザーに最も価値を与える」プロセスであり、常に実際的な妥協を模索していることを示しています（ごく最近-Typescriptを検討してください）。したがって、基本的に、C＃の開発がツール（VS）を念頭に置いて行われたことを見つけても驚くことはありません。

たとえば、C＃はPythonではありません。さまざまな設計手法があります。

さて、質問に答えるために、Python風のusingステートメントを使用することは完全に可能です。

using FooBar=MyName.Foo.FooBar; 

それほど簡単ではないので、それは間違いなく標準ではありません。ただし、各クラスがどこから来ているのかを正確に知ることについて心配する必要はないと思います。しかし、Pythonでこの方法でそれを行うことの全体のポイントを理解していません。

また、C＃はIDEを使用して簡単に使用できる言語です。Intellisenseは、特にRubyやPythonなどの動的言語と比較して、実装が驚くほど簡単です。ただし、IDEにこだわる必要はありません。Eclipseを使用している人のことを聞いたことがあります。もちろん、MonoDevelop（私は非常に多く使用しています）もあり、コマンドラインから作業することもできます。私のサーバーでは、C＃ファイルを編集viしてxbuildから再構築することがあります... IDEを使用すると、典型的な場合のコマンドラインに比べてはるかに簡単になります。

誰もがここを読むのが面倒ですか??

私は、非常に複雑なIDE機能は不可欠であり、いつか禅のSublime VimNessに進化する（すべき）と言うことで要約します。

当社のソフトウェアは、約2M LOCの129プロジェクトです。.NETフレームワークの巨大さを追加し、これを考えると、IDEが不可欠であり、このスレッドの質問の動機を超越していると言えます。

コードベースへの洞察

期間。あなたは私たちが話している機能の種類を知っています。ただし、その便利さは、私が扱う種類のコードベースにとって不可欠で不可欠なものになります。

IDEのおかげでより良いコードを記述できます。Nunitテストは簡単、高速、正確なので、常にカスタムメッセージを追加します。私は主にインテリセンスに起因する文字列よりも列挙を好みます。記述的/長いネーミングを使用することをためらいません-複数行のステートメントは高速かつクリーンに構成されます。

しかし、この賢さでさえ、時にはあまりにも多すぎます。私はよく古くからある「ファイルで検索」テキスト検索を使用します。

コーディングのヘルプ

ここで私が「十分に！」と泣くことがよくあります。十数色のほとんどが不明瞭で、どこでも特定の変数が強調表示され、ブレースが実際に何であるかを不明瞭に強調し、「それ」はコードではなく文学、Resharperコンテキストメニューのアイコン（クリックするだけです！ほとんどの場合無視します）、画面の2/3にまたがる署名ヘルプポップアップ、垂直方向にいくつかのオーバーロードを表示、マウスカーソルを置いた場所のためのポップアップ... 私が取り組んでいるコードの＆^！％行* s * も見られません！

Vis.Stud。コーディングに集中できるようにミニマリズムを取り入れる必要があるので、正気を取り戻すために負けた戦いで何百もの設定（すべてのカラーコーディング設定とすべてのプラグインを数えると数千）を経ることはありません。「パレート」キーは素晴らしいでしょう。

C＃開発は、使用しているIDEと事実上切り離せませんか？

もちろん違います。名前空間全体をインポートしないのはなぜですか？統合IDEまたはテキストエディタの使用の選択は、それとは関係ありません。名前空間全体をインポートしても、コードの読み取りや使用が難しくなることはありません。

C＃は型付き言語であることに注意してください。同じクラスを持つ複数のネームスペースをインポートすると、コンパイルエラーが発生します。

私は個人的にどちらの方法でも型宣言をあまり使用しません。代わりに、varここで説明する理由のために代わりにキーワードを使用します：http : //blog.gauffin.org/2012/08/to-var-or-not-to-var-is-that-really-the-question/

私の理解では、Pythonでは「すべてが公開されている」か、その効果があります。C＃では、モジュール設計者が公開するものとしないものを決定するため、importとにかく公開APIを取得するだけです。それがあなたが説明している違いの理由かもしれません。

C＃開発は、使用しているIDEと事実上切り離せませんか？

以前の仕事では、C＃、JavaScript、Powershell、Perl、C ++などの言語でコードを作成するためにvimを主に使用していました。プロジェクトはVisual Studioには大きすぎました。

とは言っても、ほとんどのC＃開発者ははるかに小さなプロジェクトを扱っており、VSを使用することを非常に喜んでいます。

これは、C＃開発に関する興味深い見解です。ただし、IDEについて質問している場合は、C＃の範囲を超えています。

あなたが言うように、Pythonでは、さまざまなエディターを使用してコードを書くことができます。.NETフレームワークでも同様にできます。SharpDevelopなど、使用できる他のIDEツールもあります。Visual Studioは.NETフレームワークと非常に緊密に共同開発されており、比較的高価です。SharpDevelopやVSの「Express」バージョンなどのツールは、より多くの開発者に.NETの使用を促すために存在します。基本的にIDEが行うことは、通常、インテリセンス、生産性向上のためのアドオン、および最終的にコンパイラに渡す非常に怖いコマンドラインになる可能性のあるものを組み立てる「ヘルパー」を備えた組織化された環境を提供することです。同じことがJavaにも当てはまります。Eclipseなどのツールは、組織と生産性の向上を提供するだけです。内部では、プロジェクトをビルドまたはコンパイルするまで魔法のようなことは起こりません。

C＃で「使用する」ステートメントについて話し、それをPythonと比較すると、実際には内部で行われているのと同じことではありません。usingステートメントは、C＃コードをMSILに変換する作業を支援するためにコンパイラによって使用されます。MSILには、「この名前空間からこれらのクラスをすべてインポートする」ディレクティブはありません。コードがMSILレベルになるまでに、すべてのクラスは完全修飾名でタグ付けされています。これらの「使用」および「インポート」ステートメントは、人間が読みやすいようにするためのものです。これらはコンパイラ最適化コマンドではありません。この最初の「完全修飾名のタグ付け」がすべて行われた後、FQNに対して一種の低レベルの「縮小」が行われる可能性がありますが、これはコンパイラ/インタープリターの実行を高速化するためです。

ここで言及したこれらすべての言語の最終的な根本的な違いの1つは、それらの一部はVMによって解釈され、一部はJITスタイルとして解釈され、一部は完全にコンパイルされることです。これらのusingディレクティブがこれらのコンパイラーおよびインタープリター間でどのように実装されるかは大きく異なります。

HTH。

歴史的には、答えはほとんど、そうだと思います-Visual Studio、Xamarin、またはSharpDevelop以外でC＃開発を効果的に実行して実行するのは、あまりにも不快な経験でした。

しかし最近、それを容易にする多くのプロジェクトが現れました。例えば：

OmniSharpは、Vim、emacs、atom、およびsublimeプラグインとともに、インテリセンスおよびリファクタリングの基盤を提供します。実際に使用したことがないので、どれだけうまく機能するかはわかりませんが、有望に見えます。

Yeoman ASP.NET MVCジェネレーターは、新しいMVCプロジェクトのブートストラップに役立ちます（他のジェネレーターが存在する場合もあります）。

コマンドラインからプロジェクトにNuGetパッケージを実際に追加し、.csprojファイルを更新できるNuGetの代替であるpaketコマンドラインツールではなく統合）。

Paketには、ソースコードを使用するようにソースコードを調整する必要があるという意味があります。したがって、チームで単一のメンバーとして座って、コーディングにテキストエディターを使用し、他のすべてのユーザーがVisual Studioを使用する場合、すべてのユーザーを納得させる必要がありますそれ以外の場合は、ソリューションをニーズに合わせて調整してください:(

したがって、立ち上げて実行できるはずですが、ツールチェーンを効率的に立ち上げて実行するには、比較的多くの作業が必要です。

もう違います：

http://www.omnisharp.net/

OmniSharpはオープンソースプロジェクトのファミリーであり、それぞれに1つの目標があります。これは、選択したエディターで優れた.NET開発を可能にすることです。

Cross Platform .NETと言って楽しいです。しかし、誰かがVisual StudioとWindowsなしで.NETを開発するのは合理的ですか？

SublimeのMacで.NETを実行するのは楽しいですか？UbuntuとEmacs？WindowsとAtom？エディターに加えて、Intellisense（オートコンプリートだけでなく）、参照の追加、ドキュメントのフォーマットなどの優れた機能を使用できます。どこでも開発、どこでもデプロイ（そしてAzureに！）

これをsubime3とosxでテストしました

その他のサンプル

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