Czy programowanie w C # jest skutecznie nierozerwalnie związane z używanym IDE?

Jestem programistą Python uczącym się języka C #, który próbuje przestać się martwić i po prostu uwielbiam język C # za to, czym jest, zamiast ciągle porównywać go z Pythonem.

Jestem przyłapany na jednym punkcie: braku jednoznaczności na temat tego, gdzie rzeczy są zdefiniowane, jak szczegółowo opisano w pytaniu Przepełnienie stosu . W skrócie: w języku C # using foonie mówi, z jakich nazw foosą udostępniane, co jest analogiczne jak from foo import *w Pythonie - forma, która jest zniechęcana w kulturze kodowania w Pythonie, ponieważ jest niejawna, a nie bardziej jawna from foo import bar.

Uderzyły mnie odpowiedzi Stack Overflow na ten temat od programistów C #, co w praktyce oznacza, że ​​ten brak jawności nie ma tak naprawdę znaczenia, ponieważ w twoim IDE (prawdopodobnie Visual Studio) możesz po prostu najechać myszką na nazwę i zostać poinformowanym przez system, z którego pochodzi nazwa. Na przykład:

Teraz teoretycznie zdaję sobie sprawę, że oznacza to, że patrząc na edytor tekstów, nie możesz powiedzieć, skąd pochodzą typy w C # ... ale w praktyce nie uważam tego za problem. Jak często faktycznie patrzysz na kod i nie możesz używać programu Visual Studio?

To jest dla mnie odkrywcze. Wielu programistów Pythona preferuje podejście edytora tekstu do kodowania, używając czegoś takiego jak Sublime Text 2 lub vim, gdzie chodzi o kod, a także narzędzia wiersza poleceń i bezpośredni dostęp do folderów i plików oraz manipulowanie nimi. Pomysł bycia zależnym od IDE w celu zrozumienia kodu na tak podstawowym poziomie wydaje się anatemą. Wygląda na to, że kultura C # jest pod tym względem zupełnie inna. I zastanawiam się, czy muszę to zaakceptować i przyjąć w ramach mojej nauki języka C #.

Co prowadzi mnie do mojego pytania tutaj: czy programowanie w C # jest skutecznie nierozerwalnie związane z używanym IDE?

Visual Studio jest tak wygodny, że po dłuższej pracy z nim trudno jest użyć innego IDE. Ma wiele przydatnych narzędzi i kilka wtyczek, więc praktycznie ma wszystkie funkcje, których potrzebujesz.

Z drugiej strony, niezależnie od tego, jakiego języka się uczysz, zaleca się korzystanie z wiersza poleceń na początku, aby lepiej zrozumieć, jak to działa. C # nie jest wyjątkiem.

czy programowanie w C # jest faktycznie nierozerwalnie związane z używanym IDE?

Teoretycznie nie, ale praktycznie tak. Możliwe jest pisanie w C # za pomocą edytora tekstu i wiersza poleceń, ale jeśli masz Visual Studio, nigdy byś tego nie zrobił. W rzeczywistości bardzo niewielu programistów kiedykolwiek wykonało kod C # z wiersza poleceń.

BTW Jeśli czujesz się nieswojo using foo, możesz użyć całej ścieżki podczas używania typu.

Pomysł bycia zależnym od IDE w celu zrozumienia kodu na tak podstawowym poziomie wydaje się anatemą.

Nie chodzi o zrozumienie kodu: mając wystarczającą ilość czasu, zawsze możesz znaleźć odpowiednią zmienną za pomocą podstawowego edytora tekstu lub nawet na wydruku. Jeśli chodzi o zrozumienie kodu, zależność IDE absolutnie nie istnieje.

Skuteczne lokalizowanie referencji to zupełnie inny temat: uwielbiam możliwość znajdowania użycia zmiennych Java w Eclipse, tak samo jak uwielbiam znajdowanie punktów deklaracji w Visual Studio, zarówno dla C #, jak i C ++. Wolę spędzać czas na kodowaniu niż na szukaniu punktów deklaracji ręcznie. Jest to podobne do robienia matematyki: mogę pomnożyć liczby wielocyfrowe na kawałku papieru, ale wolę używać kalkulatora, aby zaoszczędzić minutę lub dwie.

Począwszy od pewnego „krytycznego rozmiaru” kodu, dobre IDE staje się bardzo przydatne bez względu na język programowania. Rozmiar może się różnić w zależności od języka, ale po przekroczeniu kilku tysięcy wierszy posiadanie IDE pomaga niezależnie od języka. Ma to więcej wspólnego z ograniczeniami ludzkiego umysłu niż z konkretnym językiem programowania: w pewnym momencie twoja pamięć krótkotrwała musi się „przepełnić”.

Istnieją sztuczki pozwalające zwiększyć rozmiar krytyczny, w którym IDE staje się przydatne. Na przykład, możesz przestrzegać konwencji nazewnictwa (w pewnym momencie węgierskie nazwy były duże w świecie C ++, szczególnie wśród praktyków Windows). Inną powszechną sztuczką jest kwalifikowanie zmiennych instancji this.nawet w kontekstach, w których taka kwalifikacja nie jest wymagana.

Te sztuczki mają swoje kompromisy: prawie nieuchronnie sprawiają, że twój program jest mniej czytelny, zasłaniając nazwy lub wstawiając wyraźne odwołania, które ma ukrywać enkapsulacja. W obliczu wyboru wybieram czysty kod plus IDE zamiast mniej przejrzystego kodu minus IDE. W pełni jednak rozumiem, że wybory innych ludzi mogą różnić się od moich.

Wielu programistów Pythona preferuje podejście edytora tekstu do kodowania, używając czegoś takiego jak Sublime Text 2 lub vim, gdzie chodzi o kod, a także narzędzia wiersza poleceń i bezpośredni dostęp do folderów i plików oraz manipulowanie nimi.

To świetnie, ale nie ma sensu VS IDE. Istotą IDE, podobnie jak VS, jest szybkie wsparcie rozwoju dzięki silnym narzędziom kodowym, takim jak refaktoryzacja i intellisense. VS jest bardzo, bardzo dobrym edytorem kodu C #.

Teraz C # pozwala kodować w stylu, który w większym stopniu zależy od jego IDE (możesz użyć wielu varsłów kluczowych i tym podobnych). Niektóre osoby wolą być bardziej wyraźne, na przykład poprzez użycie aliasów przestrzeni nazw, aby jasno określić, do której przestrzeni nazw należy klasa (jak importw Javie lub Pythonie). To bardziej wybór stylu kodowania niż funkcja języka.

Ponieważ C # jest wpisywany statycznie (chociaż z niektórymi dynamicznymi rozszerzeniami, począwszy od v4), zawsze dość łatwo jest dowiedzieć się, do jakich typów się odwołują - jeśli są błędne, kod się nie kompiluje, a VS nie jest jedynym IDE ze wsparciem dla C # intellisense. To chyba najlepsze.

Opracowywanie C # bez potężnego IDE (takiego jak VS) przypomina raczej ręczne wbijanie gwoździ, gdy masz już najwyższej klasy pistolet do paznokci - może to być dziwny czas, gdy musisz to zrobić, ale profesjonaliści używają odpowiedniego narzędzia do pracy .

Powiedziałbym, że to samo prawdopodobnie dotyczy również Javy. Jeśli istnieje potężne IDE z narzędziami Intellisense i Refactor Code, prawdopodobnie powinieneś go używać.

Jednak spójrz na to odwrotnie - jeśli nie chcesz inteligencji, kompilacji sprawdzania kodu czasowego i analizy kodu / refaktoryzacji, wówczas rozdęte IDE nie jest dobrym rozwiązaniem, a także nie jest językiem o typie statycznym. Myślę, że jest odwrotnie:

Wielu programistów, którzy wolą kodowanie od edytora tekstu, nie czerpie zbyt wiele z języków o typie statycznym (takich jak C # i Java), więc lepiej byłoby, gdyby trzymali się dynamicznych, takich jak Python i JavaScript.

Myślę:

• Dynamiczne języki pasują do lekkich narzędzi (ciężkie IDE dają tutaj mniejsze korzyści)
• Języki statyczne pasują do potężnych IDE (narzędzia mogą pomóc w kodzie kosztem elastyczności)

Aby odpowiedzieć na twoje pytanie: choć powoli się zmienia, środowisko programistyczne Microsoft było w dużej mierze monokulturą .

Podejście to ma wiele pozytywnych i negatywnych stron, o których można długo argumentować (np. Rozważ zalety i wady otwartych i zamkniętych platform, takich jak komputery PC czy Xbox), ale na koniec narzędzia Microsoft są tym, co najbardziej ludzie używają. Firma pokazała również, że podejmowane przez nich decyzje są często rodzajem procesu „jak największej wartości dla większości naszych użytkowników”, zawsze szukając praktycznych kompromisów (ostatnio - rozważ Typescript ). Zasadniczo więc nie zdziwiłbym się, gdybym stwierdził, że rozwój C # został / jest zrobiony z myślą o oprzyrządowaniu (VS).

Po pierwsze, C # to nie Python. Istnieją różne metodologie projektowania.

Teraz, aby odpowiedzieć na twoje pytanie, można całkowicie użyć eski Pythona za pomocą instrukcji.

using FooBar=MyName.Foo.FooBar; 

To po prostu zdecydowanie nie jest normą, ponieważ nie jest to takie proste. Myślę jednak, że powinieneś mniej martwić się o to, skąd dokładnie pochodzi każda klasa. Nie rozumiem jednak sensu robienia tego w ten sposób w Pythonie.

Ponadto C # jest językiem, który bardzo dobrze nadaje się do używania IDE w celu ułatwienia. Intellisense jest niezwykle prosty do wdrożenia, szczególnie w porównaniu do języków dynamicznych, takich jak Ruby i Python. Nie musisz jednak utknąć w swoim IDE. Słyszałem o ludziach używających Eclipse. Jest też oczywiście MonoDevelop (którego używam całkiem sporo), a nawet możesz pracować z poziomu wiersza poleceń. Czasami na moim serwerze będę edytować pliki C #, via następnie używać xbuilddo ich odbudowy ... Po prostu użycie IDE sprawia, że ​​jest to o wiele łatwiejsze niż w wierszu poleceń dla typowych przypadków.

Ktoś zawracał sobie głowę czytaniem tutaj?

Podsumowując, stwierdzam, że ogromnie złożona funkcjonalność IDE jest niezbędna i kiedyś (powinna) ewoluować do Zen Sublime VimNess pewnego dnia ...

Nasze oprogramowanie to 129 projektów o wielkości około 2 mln LOC. Dodaj do tego masywność frameworku .NET i biorąc pod uwagę to wszystko, co mogę powiedzieć, to, że IDE jest niezbędne, wykraczając poza motywy pytania tego wątku.

Wgląd w bazę kodu

Kropka. Znasz rodzaje funkcji, o których mówimy; z wyjątkiem tego, że jego wygoda staje się niezbędna i niezbędna w przypadku rodzaju kodu, z którym mam do czynienia.

Piszę lepszy kod z powodu IDE. Zawsze dodam niestandardowe wiadomości do moich testów Nunit, ponieważ jest to łatwe, szybkie i dokładne. Wolę wyliczenia niż ciągi znaków, które w dużej mierze wynikają z inteligencji. Nie waham się używać opisowego / długiego nazewnictwa - oświadczenie składające się z wielu wierszy jest szybkie i czyste.

Ale nawet ta inteligencja bywa czasem zbyt duża. Często używam starego, dobrego wyszukiwania tekstu „znajdź w plikach”.

Pomoc w kodowaniu

Oto, gdzie często płaczę „dość!”. Wyobraź sobie pełny ekran z tuzinem kolorów głównie zaciemniających, niektóre szczególne zmienne podświetlone wszędzie, nawiasy klamrowe zaciemniające to, czym tak naprawdę jest nawias klamrowy, podkreślający wszędzie, ponieważ „chce”, żebym pisał literaturę, a nie kod, ikony menu kontekstowego Resharper (ty po prostu trzeba go kliknąć !, a następnie zignorować go przez większość czasu), wyskakujące okienko pomocy na 2/3 ekranu w poziomie, pionowo wyświetlające kilka przeciążeń, wyskakujące okienko z powodu miejsca, w którym akurat opuściłeś kursor myszy .... I cant nawet widział & ^!% linii * s * kodu pracuję nad!

Vis.Stud. musi przyjąć minimalizm, abym mógł skupić się na kodowaniu i nie przechodzić przez setki (tysiące, jeśli liczyć każde ustawienie kodowania kolorów i wszystkie wtyczki) ustawień w przegranej walce o odzyskanie rozsądku. Klucz „ Pareto ” byłby świetny.

czy programowanie w C # jest faktycznie nierozerwalnie związane z używanym IDE?

Oczywiście nie. Dlaczego nie zaimportowałbyś całej przestrzeni nazw? Wybór użycia zintegrowanego IDE lub edytora tekstowego nie ma z tym nic wspólnego. Zaimportowanie całej przestrzeni nazw nie utrudnia czytania kodu ani korzystania z niego.

Pamiętaj, że C # jest językiem pisanym na maszynie. Jeśli zaimportujesz kilka przestrzeni nazw o tej samej klasie, pojawi się błąd kompilacji.

Ja osobiście nie używam deklaracji typu w jakikolwiek sposób. Zamiast tego używam varsłowa kluczowego z powodów, które opisuję tutaj: http://blog.gauffin.org/2012/08/to-var-or-not-to-var-is-that-really-the-question/

Rozumiałem, że w Pythonie „wszystko jest publiczne” lub coś w tym rodzaju. W języku C # projektant modułów decyduje o tym, co jest publiczne, a co nie, więc i tak importdostajesz tylko publiczny interfejs API. To może być powód opisywanej różnicy.

czy programowanie w C # jest faktycznie nierozerwalnie związane z używanym IDE?

W mojej poprzedniej pracy głównie używałem vima do kodowania w językach takich jak C #, JavaScript, Powershell, Perl, C ++ i wielu programistów robiło coś podobnego. Projekt był zbyt duży dla Visual Studio.

To powiedziawszy, większość programistów C # zajmuje się znacznie mniejszymi projektami i bardzo chętnie korzysta z VS.

To jest interesujące spojrzenie na rozwój C #. To, o co pytasz, wykracza poza C #, jeśli pytasz o IDE.

Jak mówisz, w Pythonie możesz używać różnych edytorów do pisania kodu. Możesz to zrobić również w środowisku .NET. Istnieją również inne narzędzia IDE, z których można korzystać, takie jak SharpDevelop. Program Visual Studio jest bardzo ściśle opracowany we frameworku .NET i jest stosunkowo drogi. Istnieją narzędzia takie jak SharpDevelop i wersje „Express” VS, aby zachęcić większą liczbę programistów do korzystania z .NET. Zasadniczo wszystko, co robi dla ciebie IDE, to zorganizowane środowisko, zwykle z intellisense, dodatkami zwiększającymi produktywność i „pomocnikiem” w gromadzeniu, co może okazać się bardzo przerażającym wierszem poleceń, który można przekazać do kompilatora. To samo dotyczy Java, narzędzia takie jak Eclipse zapewniają nam ulepszenia organizacyjne i produktywności. Pod maską nie dzieje się nic magicznego, dopóki nie zbudujesz lub nie skompilujesz projektu i tego szacunku,

Kiedy mówisz o instrukcji „using” w C # i porównujesz ją do Pythona, tak naprawdę nie dzieje się tak samo pod maską. Instrukcje kompilatora są używane przez kompilator, aby pomóc mu w przekształceniu kodu C # w MSIL. W MSIL nie ma dyrektywy „importuj wszystkie te klasy z tej przestrzeni nazw”. Według kodu czasowego na poziomie MSIL wszystkie klasy zostały oznaczone ich w pełni kwalifikowanymi nazwami. Te instrukcje „za pomocą” i „importuj” mają na celu zwiększenie czytelności dla ludzi. Nie są to polecenia optymalizacji kompilatora. Po tym całym początkowym „tagowaniu w pełni kwalifikowanych nazw” może istnieć rodzaj „minify” niskiego poziomu w FQN, ale ma to pomóc kompilatorowi / tłumaczowi w szybszym wykonywaniu.

Ostatnią zasadniczą różnicą między wszystkimi wymienionymi tutaj językami jest to, że niektóre z nich są interpretowane przez maszyny wirtualne, niektóre są interpretowane w stylu JIT, a niektóre są w pełni skompilowane. Sposób, w jaki te dyrektywy są implementowane w tych kompilatorach i interpretatorach, jest bardzo różny.

HTH.

Wydaje mi się, że historycznie odpowiedź brzmi, tak - efektywne uruchomienie C # i efektywne działanie w czymkolwiek poza Visual Studio, Xamarin lub SharpDevelop było po prostu zbyt nieprzyjemnym doświadczeniem.

Ale ostatnio pojawiło się wiele projektów, które to ułatwiają, np .:

OmniSharp , stanowi podstawę dla intellisense i refaktoryzacji, a także wtyczki vim, emacs, atom i wysublimowane. Nie korzystałem z niego, więc nie wiem, jak dobrze działa, ale wygląda obiecująco.

Generatory Yeoman ASP.NET MVC , pomagają w ładowaniu nowego projektu MVC (być może istnieją inne generatory).

pakiet , alternatywa dla NuGet, w której można faktycznie dodawać pakiety NuGet do projektu z wiersza polecenia i aktualizować pliki .csproj (chociaż było narzędzie wiersza polecenia NuGet, w rzeczywistości aktualizowanie projektów w celu użycia pakietów było częścią IDE integracja, a nie narzędzia wiersza poleceń).

Z pakietu wynika, że ​​musisz dostosować swój kod źródłowy do korzystania z niego - więc jeśli siedzisz jako pojedynczy członek zespołu i chcesz użyć edytora tekstu do kodowania, a wszyscy inni używają Visual Studio, musisz przekonać wszystkich jeszcze raz dostosuj rozwiązanie do swoich potrzeb :(

Powinieneś być w stanie rozpocząć pracę, ale jest jeszcze dużo pracy, aby efektywnie uruchomić łańcuch narzędzi.

Nigdy więcej:

http://www.omnisharp.net/

OmniSharp to rodzina projektów Open Source, z których każdy ma jeden cel - umożliwienie doskonałego rozwoju .NET w wybranym edytorze.

Fajnie jest mówić o platformie .NET. Ale czy ktoś może rozwijać .NET bez Visual Studio i Windows?

Czy fajnie jest robić .NET na Macu w Sublime? Ubuntu i Emacs? Windows i Atom? Możesz użyć swojego edytora PLUS, aby korzystać ze wspaniałych funkcji, takich jak Intellisense (nie tylko autouzupełnianie), dodawać odwołania, formatować dokument i wiele innych. Programuj w dowolnym miejscu, wdrażaj w dowolnym miejscu (i na platformie Azure!)

Testowałem to z subime3 i osx

Więcej próbek na

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