C # geliştirme kullandığınız IDE'den etkili bir şekilde ayrılmaz mı?


41

Ben endişe etmeyi bırakıp C # 'yu sürekli olarak Python ile karşılaştırmak yerine, C #' yı sevmeye çalışan C # öğrenen bir Python programcısıyım.

Bir noktaya yakalanmıştım: Bu Yığın Taşması sorusunda ayrıntılı olarak açıklandığı gibi, olayların nerede tanımlandığı konusundaki açıklık eksikliği . Kısacası: C # 'da, using foohangi isimlerden fooyararlanıldığını, yani from foo import *Python'dakine benzer - Python kodlama kültüründe daha açık bir yaklaşımdan ziyade örtülü olmaları için cesaretlendirilmiş bir form olduğunu söylemez from foo import bar.

Stack Overflow'un bu noktaya C # programcılarından verdiği cevaplar beni çok etkiledi, çünkü pratikte bu açıklık eksikliği gerçekten önemli değil çünkü IDE'nizde (muhtemelen Visual Studio) bir adın üzerine gelebilir ve sizin tarafınızdan söylenebilecek adın geldiği sistem. Örneğin:

Şimdi, teoride bunun bir metin editörüyle baktığınızda, C # 'da türlerin nereden geldiğini söyleyemeyeceğiniz anlamına geldiğini anlıyorum ... ama pratikte bunu bir sorun olarak bulamıyorum. Ne sıklıkla koduna bakıyorsun ve Visual Studio'yu kullanamıyorsun?

Bu bana uygun. Birçok Python programcısı, Sublime Text 2 veya vim gibi bir şey kullanarak kodlama için bir metin düzenleyici yaklaşımını tercih eder, burada kodun tamamı, komut satırı araçları ve klasörlere ve dosyalara doğrudan erişim ve manipülasyon yapılır. Bu kadar temel bir seviyedeki kodu anlamak için bir IDE'ye bağımlı olma fikri bir anathema gibi görünüyor. Bu noktada C # kültürünün kökten farklı olduğu görülüyor. Ve merak ediyorum, bunu C # öğrenimin bir parçası olarak kabul edip kabul etmem gerekiyor mu?

Beni buradaki soruma yönlendiren: C # gelişimi kullandığınız IDE'den ayrılamaz mı?


7
Python böylece Ya sen kodudur nasıl statik (Java gibi) yazılan dinamik bir dil, C # çok farklı.
Oded

6
@Oded: using MyType = MyNamespace.MyType;?
pdr

4
Python'da nasıl bir yer olduğunu bilmiyorum, ama C # 'dan her zaman başlayabilir global::ve oradan kendi yolunuzla çalışabilirsiniz. usingdaha önce olmayan bir şeyi yapmaz; yalnızca erişimi kolaylaştırır (belirli bir sınıfı kullanmak için daha az yazı yazarken olduğu gibi).
12'de CVn

5
"Birçok Python programcısı, Sublime Text 2 veya vim gibi bir şey kullanarak kodlama için bir metin düzenleyici yaklaşımını tercih ediyor, burada kodun tümü, artı komut satırı araçları ve klasörlerin ve dosyaların doğrudan erişimi ve manipülasyonu var." - Kulağa korkunç derecede etkisiz geliyor. Bir IDE daha üretken olmanıza yardımcı olan bir araçtır. Bir çekiç ve el testeresiyle bir ev inşa edebileceğinizden ve ağaçları kendiniz kestiğinizden emin olabilirsiniz, ancak bazı elektrikli el aletleri ve önceden kesilmiş kereste satın alarak daha hızlı zaman geçireceğinizi düşünüyorum.
Andy

2
@Andy - Kulağa öyle geldiğini görebiliyorum. Ancak bu metin editörleri aslında çok güçlüdür ve bir ton takım ve programcı etkinliği özelliği sunar. Bu araç ve özellikleri bir IDE'den (ve bazı diller / programlama kültürleri için aşağı yukarı uygun olabilecek) kullanmanın ve kullanmanın radikal bir şekilde farklı bir yolu.
Ghopper21

Yanıtlar:


26

Visual Studio o kadar kullanışlıdır ki, bir süre çalıştıktan sonra farklı bir IDE kullanmak zorlaşır. Çok sayıda kullanışlı alet ve bir sürü eklenti mevcut olduğundan pratikte ihtiyacınız olan her özelliğe sahiptir.

Öte yandan, hangi dili öğrenirseniz kullanın, başlangıçta komut satırını kullanmanız önerilir, böylece nasıl çalıştığını daha iyi anlayabilirsiniz. C # bir istisna değil.

C # geliştirme kullandığınız IDE'den etkili bir şekilde ayrılmaz mı?

Teorik olarak hayır, fakat pratik olarak evet. Bir metin editörü ve komut satırı kullanarak C # ile yazmak mümkündür, ancak Visual Studio'nuz varsa bunu asla yapmazsınız. Aslında çok az programcı C # kodunu komut satırından çalıştırmıştır.

BTW Eğer kendinizi uygunsuz hissederseniz using foo, bir tür kullanırken tüm yolu kullanabilirsiniz.


9
SharpDevelop ve MonoDevelop, Visual Studio'ya alternatif IDE'lerdir.
Oded

@Oded, onları hiç kullanmadım ama bir bakış atmak için ilginç. Thanks))
superM

Teşekkürler superM - Visual Studio'yu bu kadar vazgeçilmez kılan özelliklerden bir tat verebilir misiniz? Kodun çok iyi bir şekilde tamamlandığını biliyorum, ama başka ne var? C # için Eclipse gibi mi yoksa daha az mı yoksa C # geliştiricilerin güvendiği daha belirgin bir şey var mı?
Ghopper21

2
@ Ghopper21: IntelliJ ile Eclipse'den (özellikle de Resharper'ı dahil ettiğinizde) daha karşılaştırılabilir olduğunu söyleyebilirim. Ancak, .NET dünyasında, topluluk eklentileri genellikle Visual Studio için yazılmıştır.
pdr

5
+1: Komut satırına not defteri ile kod yazarken, VS veya Sharp Develop'ın masaya getirdiği aleti görmezden gelmek için aptal olursun.
Binary Worrier

33

Bu kadar temel bir seviyedeki kodu anlamak için bir IDE'ye bağımlı olma fikri bir anathema gibi görünüyor.

Bu, kodunuzu anlama meselesi değildir : yeterli zaman verildiğinde, doğru değişkeni her zaman temel bir metin düzenleyicide veya hatta bir çıktıda bulabilirsiniz. Kodun anlaşılmasıyla ilgili olarak, IDE bağımlılığı kesinlikle mevcut değildir.

Referanslarınızı verimli bir şekilde bulmak tamamen farklı bir konu: Hem C # hem de C ++ için Visual Studio'da bildirim noktaları bulmayı sevdiğim kadar Eclipse'deki Java değişkenlerinin kullanım alanlarını da bulmayı seviyorum. Manuel olarak bildirim noktalarını aramak yerine zamanımı kodlamayı tercih ederim. Bu matematik yapmaya benzer: Çok kağıda birden fazla numarayı çarpabilirim, ancak kendimi bir veya iki dakika kurtarmak için hesap makinesini kullanmayı tercih ederim.

Kodun belirli bir "kritik boyutundan" başlayarak, programlama dili ne olursa olsun iyi bir IDE çok kullanışlı hale gelir. Büyüklük, dili diline göre değişebilir, ancak birkaç bin çizgiyi geçtiğinizde, bir IDE'nin dili ne olursa olsun yardımcı olması. Bunun bir insan zihninin belirli bir programlama diline nazaran kısıtlamaları ile ilgisi var: bir noktada, kısa süreli belleğiniz "taşma" ya bağlı.

IDE'nin kullanışlı hale geldiği kritik boyutu artırmanıza izin veren püf noktaları vardır. Örneğin, bir adlandırma kuralını takip edebilirsiniz (Macarca adlar, özellikle Windows uygulayıcıları arasında bir noktada C ++ dünyasında büyüktü). Diğer bir ortak numara, this.böyle bir yeterliliğin gerekli olmadığı durumlarda bile, örnek değişkenlerin nitelendirilmesidir .

Bu hileler takaslarla birlikte gelir: neredeyse kaçınılmaz olarak, isimleri gizleyerek veya enkapsülasyonun gizlemek istediği açık referansları ekleyerek programınızı daha az okunabilir hale getirir. Seçimle karşı karşıya kaldığımda, temiz görünümlü kod ve daha az temiz görünümlü kod eksi bir IDE yerine bir IDE seçiyorum. Bununla birlikte, diğer insanların seçimlerinin benimkinden farklı olabileceğini tamamen biliyorum.


1
Muhtemelen "hızlıca oku" kodunu söylemeliydim ... Tüm kaynakların aynı kaynak dosyada bulunmaması ve bunun yerine bu referansları bulmak için araçlar kullanmak benim için oldukça zihinsel bir kayma.
Ghopper21 15:12

5
thisKendi kendine özgü bir şekilde kullanmayı seçemedim - ama kodlama izole edilmiş bir sanat değildir ve kodlama kültürünün normlarını izlemenin (veya en azından bununla başlamanın) en iyisi olduğunu düşünüyorum - yani Python ile "Pythonic" olmak eşdeğeri ne olursa olsun "C # yolu" C # ile. Ve buradaki cevaplardan ve yorumlardan açıktır ki, Visual Studio gibi iyi bir IDE kullanmanın "C # yolu" için merkezi bir konumda olduğu (eğer doğru şekilde koyacaksa).
Ghopper21

3
@ Ghopper21 C # ile karşılaşacağınız şey IDE'siz yazamayacağınız değil, C # kodunun büyük çoğunluğunun bir IDE'ye yazılmış olması ve tüm geliştiricilerin bu IDE'yi kullanması. Bu bilgi, intellisense ile birleştirildiğinde, araştırmalar huffingtonpost.com/2011/07/15/… hakkında konuştuğu gibi geliştiricilerin google hafıza tuzağına düşmelerine neden oldu. " istendiğinde bir gerçeği hatırlayın, ancak, bu gerçeği çevrimiçi olarak nerede ve nasıl bulacağınızı hatırlıyorlar "
Jimmy Hoffa

2
@ Ghopper21 Bu bellek kapağının kötü olduğunu söylemiyorum , çoğu için son derece artmış bir verimlilik kaynağıdır, bu yüzden sadece çalıştığı tüm API'yi ezberleyebildikleri günlerin uzun hatıralarına sahip olanların bu konuda gerçekten şikayetçi olmalarının nedeni budur. Bunu sadece işaret ediyorum, çünkü bu gerçek okuyacağınız C # kodunu ve C # gelişiminin stilini ve kültürünü doğrudan etkiliyor.
Jimmy Hoffa

1
Asla biyo / düşük seviyeli dos API'lere inmedim; fakat ilk dilim / ortamım Borland TurboPascal; ve muhtemelen bir noktada ezberlenen dil / standart kütüphanesinin ~% 90'ını vardı. Öncelikli istisnalar, OO'nun ne olması gerektiğini çözememe konusunda tamamen başarısız olmayla ilgili.
Dan Neely

8

Birçok Python programcısı, Sublime Text 2 veya vim gibi bir şey kullanarak kodlama için bir metin düzenleyici yaklaşımını tercih eder, burada kodun tamamı, komut satırı araçları ve klasörlere ve dosyalara doğrudan erişim ve manipülasyon yapılır.

Bu harika, ama VS IDE'nin noktasını kaçırıyor. VS benzeri bir IDE'nin amacı, refactoring ve intellisense gibi güçlü kod araçları ile hızlı geliştirme desteğidir. VS, C # kodu için çok çok iyi bir editördür.

Şimdi C #, IDE'sine bağlı bir stilde daha fazla kodlama yapmanızı sağlar (çok sayıda varanahtar kelime ve benzeri kullanabilirsiniz). Bazı insanlar, örneğin bir sınıfın hangi ad alanına ait olduğu konusunda net olmak için ad alanı takma adları kullanarak ( importJava veya Python'da olduğu gibi) daha açık olmayı tercih eder . Bu, dilin bir özelliğinden çok bir kodlama tarzı seçimidir.

C # statik olarak yazıldığı için (bazı dinamik uzantılara rağmen, v4'ten itibaren), hangi türlerin yönlendirildiğini bulmak her zaman oldukça kolaydır - yanlışsa kod derlenmeyecek ve VS tek IDE değildir C # intellisense desteği ile. Muhtemelen en iyisi olsa.

Güçlü bir IDE'siz (VS gibi) C # geliştirmek, zaten çivi tabancanın en üstünde olduğunda elinizle çivi çakmak gibidir - yapmak için ihtiyaç duyduğunuz tuhaf bir zaman olabilir, ancak profesyoneller iş için doğru aracı kullanır .

Aynı şey muhtemelen Java için de geçerli diyebilirim. Dışarıda intellisense ve code refactor araçlarıyla güçlü bir IDE varsa, muhtemelen onu kullanıyor olmalısınız.

Bununla birlikte, diğer tarafa bakın - eğer akıllılık istemiyorsanız, zaman kodunu derleme ve kod analizi / yeniden düzenleme işlemlerini derleyin, sonra şişirilmiş bir IDE gitmenin yolu değildir ve statik olarak yazılmış bir dil de değildir. Bence bu tam tersi:

Kodlamaya metin editörü yaklaşımı tercih eden pek çok programcı statik olarak yazılmış dillerden (C # ve Java gibi) fazla kazanmaz ve Python ve Javascript gibi dinamik olanlara sadık kalırsa daha iyi olabilir.

Bence:

  • Dinamik diller hafif araçlara uygundur (ağır IDE'ler burada daha az fayda sağlar)
  • Statik diller güçlü IDE'lere uygundur (araçlar esneklik pahasına koda yardımcı olabilir)

Tersine çevrilen teklif için +1.
fbmd

5

Sorunuzu yanıtlamak için: yavaşça değişmesine rağmen, Microsoft geliştirme ortamı büyük ölçüde bir monokültür olmuştur .

Bu yaklaşımın, uzun zamandır tartışılabilecek birçok pozitif ve olumsuz yönü vardır (örneğin, PC'ler ve Xbox gibi açık ve kapalı platformların artılarını ve eksilerini göz önünde bulundurun), ancak günün sonunda, Microsoft’un araçları en çok insanlar kullanır. Şirket ayrıca karar vermelerinin genellikle "kullanıcılarımızın çoğunluğuna en fazla değeri veren" süreç olduğunu ve her zaman pratik tavizler aradığını göstermiştir (en yakın zamanda - Typescript'i düşünün ). Bu yüzden, temel olarak, C # 'ın geliştirilmesinin takım (VS) düşünülerek yapıldığı / yapıldığına şaşırmam.


Bu arada, Python'un aynı zamanda kendi monokültürü olduğu, daha sonra kodlama tarzı ve yaklaşımında "Pythonic" olarak kabul edilene ve dilin temel tasarım ilkesini bir şeyleri yapmak için açık bir şekilde doğru yapma ilkesine sıkı sıkıya bağlı kaldığı söylenebilir. Tutarlı bir topluluk ve paylaşılabilir kod oluşturduğundan, bu anlamda programlama monoküllerinin çok iyi olabileceğini düşünüyorum. Python ve C # kültürleri çok farklı ... sadece (çok kötü? Ve / veya fikrimi genişletmek için bir fırsat?).
Ghopper21

2
@ Ghopper21 Python için çok iyi bir nokta. MS’in "Bunu yapmanın tek ve açık bir yolu olmalı" sürümünün IDE’nin seçimine uzandığını düşünüyorum :)
Daniel B

4

Birincisi, C # Python değil. Farklı tasarım metodolojileri var.

Şimdi, sorunuzu yanıtlamak için, Python-esque'inizi ifadeler kullanarak kullanmak tamamen mümkündür.

using FooBar=MyName.Foo.FooBar; 

Sadece kesinlikle norm değil çünkü neredeyse hiç kolay değil. Ancak, her sınıfın tam olarak nereden geldiğini bilmek konusunda daha az endişelenmeniz gerektiğini düşünüyorum. Yine de Python'da bu şekilde yapmanın bütün anlamını anlamıyorum.

Ve ayrıca, C #, onu kolaylaştırmak için IDE'leri kullanmaya kendini çok iyi veren bir dildir. Intellisense, özellikle Ruby ve Python gibi dinamik dillerle karşılaştırıldığında, uygulanması son derece basittir. Ancak, IDE'nize takılı kalmanıza gerek yok. Eclipse kullanan insanları duydum. Tabii ki MonoDevelop da var (ki çok fazla kullanıyorum) ve hatta bir komut satırından bile çalışabilirsiniz. Sunucumda bazen C # dosyalarını düzenleyeceğim vive sonra xbuildyeniden oluşturmak için kullanacağım ... Sadece bir IDE kullanmak tipik durumlar için komut satırına kıyasla işleri çok daha kolaylaştırıyor.


4

Buradan aşağı yolu okumak isteyen herkes?

Devasa karmaşık IDE işlevselliğinin vazgeçilmez olduğunu ve bir gün Yüce VimNess Zenine dönüşmesi gerektiğini söyleyerek özetliyoruz ....

Yazılımımız yaklaşık 2M LOC 129 projedir. .NET çerçevesinin büyüklüğünü ekleyin ve söyleyebileceğim tek şey bu IDE'nin hayati önem taşıdığı, bu konunun sorusunun motivasyonlarını aşması.

Kod Tabanına Bakış

Dönemi. Bahsettiğimiz özelliklerin çeşitlerini biliyorsunuz; onun rahatlığı vazgeçilmez ve bununla uğraştığım kod üssü türünde gerekli olması dışında.

IDE yüzünden daha iyi kod yazıyorum. Nunit testlerime her zaman özel mesajlar eklerim çünkü kolay, hızlı ve doğru. Yaygın olarak intellisense nedeniyle dize sayıları lehine. Tanımlayıcı / uzun adlandırmada tereddüt etmiyorum - çok satırlı bir ifade hızlı ve temizdir.

Fakat bu zekice bile zaman zaman çok fazla. Sık sık eski "dosyalarda bul" metin aramasını kullanırım.

Kodlama yardımı

İşte "yeterince ağladım". Çoğunlukla müstehcen bir düzine renk, her yerde vurgulanan belirli bir değişken, bir perdeyi hayal etmeyin, küme ayracının gerçekte ne olduğunu belirsiz kılan vurgulayın, her yerde sivri bir şekilde altını çizin, çünkü "o" benim kod yazmamamı istiyor, Resharper bağlam menüleri için simgeler (sizce sadece tıklayın! o zaman çoğu zaman yoksay), ekranın 2 / 3'ünü kapsayan bir imza yardım penceresi yatay olarak, dikey olarak birkaç aşırı yükleme, fare imlecini bıraktığınız yer nedeniyle açılan bir açılır pencere görüntüleniyor .... I Üzerinde çalışmakta olduğum kodun & ^!% line * s * kodunu bile göremiyorum !

Vis.Stud. Öyle ihtiyaçları minimalizm kucaklamak olabilir geçmesi kodlama odaklanmak değil, yüzlerce geri kazanımı aklı bir kaybetme savaşta ayarların (binlerce her renk kodlama ayarı ve tüm bu eklentileri sayarsak). Bir " Pareto " tuşu harika olurdu.


1
Buradaki düşüncelerinizi gerçekten takdir ediyorum, çünkü hem IDE hem de “Yüce VimNess” anlamında gerçekten “anlıyorsunuz” gibi görünüyor. Burada söylediğin her şeyde seninleyim. İşte bunun geleceğini umuyoruz.
Ghopper21

3

C # geliştirme kullandığınız IDE'den etkili bir şekilde ayrılmaz mı?

Tabii ki değil. Neden tüm ad alanını içe aktarmıyorsun? Bütünleşik bir IDE veya bir metin editörü kullanma seçeneğinin bununla hiçbir ilgisi yok. Ad alanının tamamını içe aktarmak, kodu okumayı veya kullanmayı zorlaştırmaz.

Unutma, C # yazılmış bir dildir. Aynı sınıfa sahip birkaç ad alanını içe aktarırsanız, bir derleme hatası alırsınız.

Şahsen tür bildirimlerini bu şekilde kullanmıyorum. Bunun yerine, varanahtar kelimeyi burada tanımladığım nedenlerden dolayı kullanıyorum: http://blog.gauffin.org/2012/08/to-var-or-not-to-var-is-that-really-the-question/


1
Sorun kod yazmamayı okuyor. (Yukarıya bağladığım Yığın Taşması sorusu bir örnek verir.) Kod okurken bir şeyin nereden geldiğini nereden biliyorsunuz? Python ile açık bir içe aktarma arayabilir (kodun bu içe aktarmaları kullanmak için güçlü Python kurallarına uyduğu varsayılarak). C # ile, fikir birliği pratikte VS gibi bir IDE kullandığınız anlaşılıyor.
Ghopper21

Sınıfın nereden geldiğini bilmiyorsanız, nasıl çalıştığını bilmek için her iki şekilde de araştırmanız gerekecektir. Sadece google msdn <classname>ve ilk linke tıklayın. Orada da isim alanını buluyorsun.
jgauffin

Bu yaklaşım kültürel farklılığı örneklemektedir. Python programcılarının google şeyler yapmadıkları - elbette yaptıkları - bu sadece farklı düşünmenin bir yolu.
Ghopper21

Ayrı bir notta, C # var var kod daha az ayrıntılı ve tekrarlayan yapmak için sevdiğim güzel bir sözdizimsel şeker / derleyici kısayol. Keşke onu sadece yöntemlerin içinde değil, her yerde kullanabilmeyi diliyorum.
Ghopper21

@ Ghopper21: Evet, biliyorum. Demek istediğim şu ki, google MSDN’yi oldukça iyi indeksler ve doğrudan dokümantasyonu alırsınız. Bu nedenle, kullandığınız her sınıfı, kendisine tüm yolu dahil ederek belgelendirmeniz gerekmez.
jgauffin

1

Anladığım kadarıyla Python'da “her şey halka açık” ya da bunun için bir şeydi. C # 'da, modül tasarımcısı neyin halka açık olduğuna neyin karar vermeyeceğine karar verir, böylece bir importyaptığınızda sadece ortak API elde edersiniz. Bu tarif ettiğiniz farkın bir nedeni olabilir.


Bu kesinlikle Python ve C # arasında büyük bir fark, ancak ithalatta neden bu kadar açık bir eksiklik olduğunu anlamama yardımcı olmuyor. Pbr, yorumunda da belirtildiği gibi, Java (ayrıca kamusal / özel ayrımları da vardır), açıkça ithalat için kültürel tercihinde Python'a benzer.
Ghopper21 15:12

5
@ Ghopper21 - Java'da (ve örneğin C ++) belirgin bir ithalat tercih etmenin tek nedeni, ad çakışmalarını engellemektir. C # aslında onlar daha iyi sap beri, ithalat / tip takma adlarına üzerinden bu sorunla başa çıkmak için tasarım kararı var Kaynağını yığılan Demirbaş ithalatı bir demet olmamasından yararına ile birlikte bir isim çarpışma.
Telastyn

1

C # geliştirme kullandığınız IDE'den etkili bir şekilde ayrılmaz mı?

Önceki işimde çoğunlukla C #, JavaScript, Powershell, Perl, C ++ gibi dillerde kodlamak için vim kullanıyordum ve benzer bir şey yapan birkaç geliştirici vardı. Proje Visual Studio için çok büyüktü.

Bununla birlikte, çoğu C # geliştiricisi daha küçük projelerle ilgileniyor ve VS kullanmaktan oldukça mutlular.


0

Bu, C # gelişmesi hakkında ilginç bir görüş. İstediğiniz şey, eğer IDE hakkında sorularınız varsa, C # 'dan öteye gidiyor.

Söylediğiniz gibi, Python'da, kodunuzu yazmak için çeşitli düzenleyiciler kullanabilirsiniz. Bunu .NET framework ile de yapabilirsiniz. SharpDevelop gibi kullanabileceğiniz başka IDE araçları da vardır. Visual Studio, .NET Framework ile çok sıkı bir şekilde geliştirildi ve nispeten pahalı. SharpDevelop ve VS'nin "Express" sürümleri gibi araçlar, .NET'i daha fazla geliştiriciyi teşvik etmek için mevcuttur. Temel olarak tüm IDE sizin için yapar, genellikle intellisense, üretkenlik için eklentiler ve derleyicinize aktarmak için çok korkutucu görünen bir komut satırı haline gelebilecek bir araya getirmek için bir "yardımcı" olan organize bir ortam sağlar. Aynı şey Java için de geçerlidir, Eclipse gibi araçlar bizim için sadece organizasyon ve verimlilik geliştirmeleri sağlar. Kaputun altında, projeni inşa edene ya da derleyene kadar büyülü bir şey olmaz.

C # 'daki "using" ifadesinden bahsettiğinizde ve bunu Python ile karşılaştırdığınızda, kaputun altında olan aynı şey değildir. Use deyimleri, derleyici tarafından C # kodunu MSIL'ye dönüştürme çabasına yardımcı olmak için kullanılır. MSIL’de “tüm bu sınıfları bu ad alanından al” yönergesi yoktur. Zaman kodu MSIL seviyesinde olduğunda, tüm sınıflar tam isimleri ile etiketlenmiştir. Bu "kullanma" ve "alma" ifadeleri insanın okunabilirliğine yardımcı olmak içindir. Derleyici optimizasyon komutları değillerdir. Tüm bu ilk "tam olarak nitelenmiş isimlerin etiketlenmesi" başladıktan sonra, FQN'lerde bir miktar düşük seviye "küçültme" olabilir, ancak bu derleyici / tercümanın daha hızlı çalışmasına yardımcı olmak içindir.

Burada belirtilen tüm bu diller arasındaki son temel fark, bir kısmının VM'ler tarafından yorumlanması, bazılarının JIT tarzı yorumlanması ve bazılarının tam olarak derlenmesidir. Bu kullanma yönergelerinin bu derleyiciler ve tercümanlar arasında nasıl uygulandığına göre büyük ölçüde farklılık gösterir.

HTH.


“Bu“ kullanım ”ve“ ithalat ”ifadeleri insanın okunabilirliğine yardımcı olmak içindir.” - evet, bu işte kilit bir felsefi fark var. Metin düzeyinde okunabilirlik, Python tasarım ilkesi için anahtar bir ilkedir. C # kesinlikle gerek yok, ancak pratik olarak VS gibi iyi bir IDE'ye "okunabilir" olmalarına güveniyor. Bu arada, Python'daki "import", C #'daki "use" ifadesinin aksine okunabilirlikten daha fazlasıdır.
Ghopper21

0

Bence tarihsel olarak cevabın hemen hemen evet olduğunu düşünüyorum - C # geliştirmesi ve Visual Studio, Xamarin veya SharpDevelop dışındaki herhangi bir şeyde etkin bir şekilde çalışmasının sağlanması çok hoş olmayan bir deneyim oldu.

Ancak son zamanlarda bunu kolaylaştıran birçok proje ortaya çıktı, örneğin:

OmniSharp , vim, emacs, atom ve yüce eklentileri ile birlikte intellisense ve refactoring için bir temel sağlar. Aslında kullanmadım, bu yüzden ne kadar iyi çalıştığını bilmiyorum, ama umut verici görünüyor.

Yeoman ASP.NET MVC jeneratörleri , yeni bir MVC projesini başlatmaya yardımcı olur (belki başka jeneratörler de vardır).

projenize komut satırından NuGet paketlerini gerçekten ekleyebileceğiniz ve .csproj dosyalarınızı güncelletebileceğiniz bir NuGet alternatifi olan paket (bir NuGet komut satırı aracı olmasına rağmen, aslında paketleri kullanmak için projeleri güncellemek IDE'nin bir parçasıydı) entegrasyon, komut satırı araçları değil).

Paket, kaynak kodunuzu kullanmak için uyarlamanız gerektiği fikrine sahiptir - bir takımda tek bir üye olarak oturuyorsanız ve kodlama için bir metin editörü kullanmak istiyorsanız ve herkes Visual Studio kullanıyorsa, herkesi ikna etmeniz gerekir. çözümü ihtiyaçlarınıza göre uyarlamak için :(

Bu yüzden ayağa kalkıp koşabilmelisiniz, ancak alet zincirinizi verimli bir şekilde çalıştırmak için çok daha fazla iş var.


-1

Artık değil:

http://www.omnisharp.net/

OmniSharp, her biri bir amacı olan bir Açık Kaynak projeleri ailesidir - Tercih ettiğiniz YOUR editöründe harika .NET gelişimi sağlamak.

Cross Platform .NET demek eğlencelidir. Ancak birinin Visual Studio ve Windows olmadan .NET geliştirmesi mantıklı mı?

Sublime Mac'te .NET yapmak eğlenceli midir? Ubuntu ve Emacs? Windows ve Atom? Editör PLUS get Intellisense (sadece Otomatik Tamamlama değil), Referans Ekle, Doküman Formatlama ve daha pek çok özellikten yararlanmak için kullanabilirsiniz. Her yerde geliştir, her yere dağıt (ve Azure'a!)

Bunu subime3 ve osx ile test ettim

Daha fazla örnek

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


Omnisharp, C # ile yüce ve emacs gibi metin editörlerini kullanabilir. Peki neden indirildi?
mamcx
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.