Debata VB.Net vs C # [zamknięta]

Byłem w miejscach pracy, gdzie na początku projektu pojawiło się pytanie „Powinniśmy używać VB.Net lub C #”.

To prawda, że ​​podejmowanie tej decyzji jest prawdopodobnie rzadziej niż na początku .Net, szczególnie biorąc pod uwagę tendencję do konwergencji językowej, ale wciąż może to być gorąca debata.

Pomiędzy VB.Net a C #, jaki język preferujesz i dlaczego?

Wolę C # niż VB.NET, ponieważ

• łatwiej jest znaleźć programistów / pracę:

• łatwiej jest znaleźć pomoc:

^{(z stackoverflow)}

Nienawidzę VB.NET. Dni, które wciąż spędzam, używając tego, są dniami, których żałuję. To powiedziawszy, moje gusta są częścią mojej sytuacji i doświadczenia i niekoniecznie mają związek z tym, co robisz ...

Uważam, że przy porównywaniu ciągle rozwijających się języków, takich jak C # i VB.NET, ważne jest, aby spojrzeć wstecz na ich historię i zobaczyć, jak doszli do obecnego stanu:

Pierwotne zalety BASIC na mikrokomputerach obejmowały rozmiar i prostotę (mała, łatwa do przeanalizowania składnia stworzona dla małych, dość szybkich interpreterów i pozostawione miejsce w pamięci dla rzeczywistego programu i danych), interaktywne środowisko umożliwiające eksperymenty oraz składnia które porzuciły zwięzłe symbole i struktury dla dość jasnej, angielskiej składni. Był jednak słabo przystosowany do dużych, ustrukturyzowanych programów i zachęcał do kodowania spaghetti. Mimo to jego dostępność i prostota sprawiły, że był to doskonały wybór na wprowadzenie do programowania.

QuickBasic zaktualizował składnię, aby umożliwić tworzenie bardziej rozbudowanych programów, i dodał kompilację, aby przyspieszyć wykonywanie.

VisualBasic dostarczył potężnego, łatwego w użyciu konstruktora formularzy, który umożliwia szybką budowę aplikacji GUI, przy jednoczesnym zastosowaniu składni QB do użycia w skryptowaniu tych interfejsów użytkownika. Działa najlepiej, gdy jest używany do tworzenia interfejsów użytkownika dla logiki niskiego poziomu, dostarczanej jako wstępnie zbudowane komponenty (zwykle napisane w innym języku). Z czasem składnia stawała się coraz większa i niespójna w miarę wprowadzania nowych funkcji. Skoncentrowanie się na przygotowaniu najpierw interfejsu użytkownika, a następnie wypełnieniu fragmentów skryptu działało dobrze w przypadku małych aplikacji zorientowanych na interfejs użytkownika, ale zwykle zachęcało do programowania kopiowania i wklejania oraz różnic w kodzie spaghetti, jednocześnie zniechęcając do ponownego użycia, złożonych struktur danych i rozdzielenie obaw. W umysłach wielu „kod VB” stał się synonimem „wielkiej kuli błota”; „Programator VB” z „niedoświadczonym hackiem”.

VB.NET to język podobny do VB na platformie .NET, próba (nie do końca udana) czyszczenia i modernizacji przerośniętej składni VB. Nie był on w pełni zgodny z istniejącym kodem VB i nie dołożył żadnych starań, aby zapewnić zgodność z formularzami VB (prawdopodobnie najważniejszą częścią VB). To pozostawiło wielu właścicielom produktów VB nieprzyjemny wybór skutecznego przepisywania aplikacji w VB.NET (radzenie sobie z subtelnymi niezgodnościami w każdej procedurze, która nie została dokładnie zbadana) lub faktycznego przepisywania aplikacji w języku C # (radzenie sobie z nieznanym składnia oprócznowa biblioteka środowiska wykonawczego i projektant formularzy). Większość użytkowników VB.NET była użytkownikami VB, którzy trzymali się tej samej samej składni, wielu używało jej jako kuli podczas nauki języka C #. W rezultacie od razu zyskało reputację raju dla programistów, którzy utknęli na ich drodze, nie chcąc lub nie będąc w stanie rozwinąć lub ulepszyć swoich umiejętności.

W tym momencie VB.NET nadal ewoluuje, powoli zrzucając bagaż, jednocześnie wybierając nową i interesującą składnię (LINQ, literały XML). Mimo to nie zachowuje prawie żadnej z pierwotnych zalet BASIC: jest to duży, złożony język z dość stromą krzywą uczenia się i ograniczoną możliwością interaktywnych eksperymentów.

• Dla starych programistów, którzy trzymali się tego przez ponad 30 lat, nie jest to zły wybór, pod warunkiem, że nie ograniczają się do niego.
• Dla nowych programistów coraz bardziej niejasne podobieństwo programów VB do angielskiego nie jest warte dziwnych ukłonów w stronę wstecznej kompatybilności i piętna społecznego.
• W przypadku nowych projektów VB.NET jest dziwnym wyborem, chyba że projekt jest mocno zaangażowany w jedno z niewielu zadań, dla których język jest zoptymalizowany: integracja ze źle napisanymi komponentami COM (Office ...) (chociaż C # 4.0 znacznie zmniejsza tę przewagę ) lub wbudowane generowanie XML.

Znam oba te elementy, ale wiele z moich wczesnych prac programistycznych wykonałem w VB4, VB5 i VB6. Teraz, gdy oba języki w .NET przeszły przez kilka iteracji i dość mocno zbiegły się w swoich możliwościach, myślę, że debata jest wręcz głupia, podobna do „jaki jest twój ulubiony kolor”.

Osobiście lubię oba z różnych powodów.

VB.NET
Wiele osób mówi o tym, jak składnia C # jest bardziej intuicyjna, ale jest to bardzo subiektywne i oparte w dużej mierze na tym, co zacząłeś od poznania. Twierdziłbym, że gdybyś był całkowicie obiektywny, składnia VB.NET jest prawdopodobnie bardziej intuicyjna, jeśli nie zakładasz wcześniejszej znajomości innego języka. Na przykład, biorąc pod uwagę ten sam program w C # i VB.NET, który Twoim zdaniem byłby bardziej zrozumiały dla kogoś, kto nie ma wiedzy o programowaniu. Wydaje mi się to całkiem jasne.

Inną rzeczą, która jest miła w tej składni, jest to, że jest o wiele bardziej wyraźna w zamykaniu struktur (END IF, END WHILE, NEXT X) w porównaniu do modelu bracketingu. To sprawia, że ​​kod jest nieco bardziej czytelny i często pozwala kompilatorowi być bardziej precyzyjnym w tym, który numer wiersza powoduje błędy kompilacji. Jeśli kiedykolwiek wybrałeś się na polowanie na brakujący nawias klamrowy / średnik z powodu błędu kompilatora 50 linii od problemu, wiesz o co mi chodzi.

Ponadto w kolumnie wygranej VB.NET moim zdaniem brakuje == / = jako operatorów porównania / przypisania. Rzadkie korzyści z posiadania odrębnego operatora dla każdego nigdy nie zrównają wszystkich (czasami) trudnych do wykrycia słabych punktów, które pomaga stworzyć.

Wreszcie, nienawidzę rozróżniania wielkości liter w językach programowania. Jednym z zarzutów dotyczących VB jest to, że ma on tyle bagażu, ale C # przeniósł albatros wrażliwości na wielkość liter C. Nigdy nie byłem w sytuacji, w której chciałbym, aby dwa identyfikatory w tym samym zakresie różniły się tylko przypadkiem. To tylko sprawia, że ​​praca jest zajęta i spowalnia mnie. VB.NET otrzymuje w tym względzie kilka punktów nad C #.

Programiści C # uwielbiają być zwięzli, dlatego myślę, że generalnie preferują tę składnię. Ma tylko pewien urok estetyczny. Jednak z całkiem praktycznej perspektywy podoba mi się, ponieważ jest tak podobny do języków takich jak Java, JavaScript i C ++.

Ponieważ zajmuję się tworzeniem stron internetowych, które wymagają programowania zarówno po stronie serwera, jak i klienta, łatwiej jest mi mentalnie przełączać się między C # i JavaScript, co często jest mi wymagane.

Podoba mi się również to, że w większości przypadków, gdybym kiedykolwiek musiał przejść do programowania w Javie lub C ++, miałbym trochę przewagi, gdybym korzystał z C # przez większość czasu.

Wolę składnię nawiasową języków w stylu C niż bardziej „pełną” składnię języków w stylu BASIC.

Moje wprowadzenie do programowania było z Turbo Pascal. (Trochę programowania BASIC, które zrobiłem na Commodore 64, jako dziecko, tak naprawdę się nie liczy.) Po nauce języka Java nigdy nie oglądałem się za siebie i wolałem składnię w stylu C.

Są funkcjonalnie takie same, nie ma nic, co można zrobić w jednym, czego nie można zrobić w drugim, a w przyszłości Microsoft obiecał, że zespoły językowe będą rozwijać się równo, więc jest to mało prawdopodobne, aby zmiana była równoważna.

Różnice są teraz czysto kulturowe i osobiste. Ten artykuł jest interesującą lekturą na temat różnic między kulturami programistów używających C # i VB.net

_{[Uwaga: Chociaż sam jestem programistą C #, konkluzja powiązanego artykułu niekoniecznie odzwierciedla moją osobistą opinię, jest to tylko interesujące alternatywne podejście w debacie]}

Przyszedłem do .NET z C i C ++ (z odrobiną Javy, Adi i Pascala), więc C # był dla mnie naturalnym postępem.

Gdyby pojawiło się zadanie wymagające VB.NET, na pewno bym go nie odrzucił.

Wykonałem dużo pracy z VB.NET, ale rozumiem wystarczającą liczbę C #, aby uzyskać sedno tego, co dzieje się w kodzie. Moje obecne preferencje to VB.NET, ponieważ najbardziej go znam (oczywiście), ale tak naprawdę nie mam preferencji między pełną składnią BASIC a składnią w stylu C, obie są dla mnie bardzo czytelne i zrozumiałe.

Większość mojego programowania współpracuje z COBOL i VB6, więc VB.NET był dla nas, jako zespołu, wygodniejszym wyborem języka .NET. Nie było dla nas solidnego powodu, który wymagałby nauki języka C #, ponieważ są one funkcjonalnie takie same.

To powiedziawszy, nauka C # jest zdecydowanie na mojej liście rzeczy do zrobienia.

Wolę C #.

Zaczynałem jako programista VB.NET, ale z czasem stało się jasne, że całkiem sporo nowych funkcji pojawia się najpierw w C #, a potem w VB.NET (np. Właściwość automatyczna). A społeczność otaczająca C # jest znacznie bardziej ożywiona niż VB.NET.

Dodatkowo, jeśli zamierzasz nauczyć się języka Java lub podobnego języka, C # jest lepszym punktem wyjścia - składnia jest prawie taka sama we wszystkich językach pochodnych C. Chociaż nie byłoby to dla mnie punktem zwrotnym, ponieważ składnia jest czymś, czego można się szybko nauczyć.

Oprócz innych odpowiedzi zamieszczonych tutaj, wybrałbym C # zamiast VB, ponieważ programiści C # otrzymują więcej. Więcej doświadczenia z C # = więcej $$ :)

Wiem, że oba języki są prawie takie same i bardzo łatwo można przełączać się między nimi, ale myślę, że kiedy zarząd patrzy na kilka nawiasów klamrowych i średników, akceptuje fakt, że robimy coś, czego nie mogą zrobić, z VB. Net mogą spojrzeć na to i powiedzieć „och, to nie musi być takie trudne, jeśli mogę to zrozumieć”.

C #, ponieważ mogę przełączać się między nim a Javą przy minimalnym wysiłku

VB.NET ma zupełnie inną składnię. C #, podobny do Java i innych języków daje mi lepszą pozycję do szybkiego dostosowywania się do nowych rzeczy. Ponieważ dane wyjściowe C # i VB.NET są praktycznie wymienne, sensowne jest używanie C #. Ponadto, jeśli kod Twojej firmy znajduje się w języku C #, bardziej prawdopodobne jest, że będziesz w stanie nauczyć programistę Java, jak kodować C #, niż VB programisty Java. Są tylko subtelne zalety, ale subtelność jest nadal zaletą.

Odkładając na bok moje osobiste preferencje. Jako osoba, która ostatnio rekrutowała (i próbowała zostać rekrutowana), kiedy mieliśmy tę debatę w biurze, panowała ogólna zgoda co do tego, że powinniśmy przejść do C # z VB.

Dlaczego? Ponieważ C # był bardziej rozpowszechniony na rynku (w każdym razie wokół nas), co pozwala nam łatwiej rekrutować i łatwiej rekrutować.

Wygląda na to, że zatoczyło pełne koło; ludzie uczą się języka C #, ponieważ rekruterzy tego chcą, ponieważ jest więcej kandydatów.

Będąc nieco starszym deweloperem (czy 59 jest „nieco” starszy?), Nauczyłem się języka BASIC najpierw na Commodore VIC-20, nauczyłem się Turbo Pascal (v1!), Zacząłem uczyć się języka COBOL na studiach i spędziłem 14 lat pracując nad IBM mainframe, z krótkimi zmianami piszącymi średnie aplikacje w Revelation BASIC (wariant PICK BASIC) i kilkoma narzędziami w Modula-2, przed przejściem do VB5 i VB6. A potem przyszedł .NET.

Ze względu na moje podstawowe doświadczenie, pomyślałem, że powinienem zacząć od VB.NET, ale okazało się, że próbowałem robić rzeczy „staro” i doprowadzało mnie to do szału (okej, więcej orzechów). Ponieważ wykonałem trochę pracy w C, pomyślałem, że dam C # wir, aby zobaczyć, jak to się potoczy. I OMG, to było jak wynurzenie się z ciemnego tunelu do czystego światła dziennego! Całkowicie nieoczekiwany. Wydawałem z siebie obraźliwe odgłosy na temat tego, że C jest językiem „tylko do zapisu” - „tak trudno zrozumieć, że programista C nie mógł zrozumieć, co zrobił jego własny kod 6 miesięcy po jego napisaniu” na wpół sławny powieściopisarz, który wydawał mi się wtedy słodki.

Z racji tego, że trochę nie znałem C, nauka języka C # była paradoksalnie łatwiejsza w nauce programowania .NET niż w znacznie bardziej znanym paradygmacie Basic. Nadal lubię VB6, ale pokochałem C #. Najlepszy język programowania na świecie.

W Visual Basic .Net rozwijam się od 2001 roku, uwielbiam go i nienawidzę !!!

Kolejność prezentacji tych punktów jest oparta na kolejności, w jakiej przyszedł mi do głowy ...

W vb.net ze studiem wizualnym istnieje wizualny podział linii między każdą metodą, właściwością. Dla wielu osób nie jest to dobry powód, aby preferować vb.net niż c #, ale nie rozumiem, dlaczego zespół c # w Microsoft nie wdrożył go. Istnieje dodatek, który rysuje tę linię w c #, ale jeszcze raz dziękuje Microsoftowi, aby mieć zespół ac # i zespół Visual Basic, którzy nie rozmawiają ze sobą.

W vb.net, kiedy tworzysz formularz win, masz dwa combobox w Visual Studio na górze edytora i możesz automatycznie generować zdarzenie automatycznie po wybraniu zdarzenia na prawym combobox. Gdy dołączasz dziesiątki wydarzeń każdego dnia, może to być bardzo kłopotliwe, jeśli nie masz tej funkcji. Dzięki c # masz mały przycisk u góry siatki właściwości, który może generować zdarzenia, ale nie jest szybki jak w vb.net. Ponadto, jeśli dołączysz zdarzenie sterujące w c # i usuniesz formant w formularzu, uczestnik utworzony w automatycznie wygenerowanym kodzie do obsługi zdarzenia musi zostać usunięty ręcznie. Jeszcze raz dziękuję Microsoft.

W vb.net, gdy próbujesz zmodyfikować metodę zawierającą zapytanie linq bez modyfikacji samego zapytania, nie ma problemu, ale w języku c # cały kod metody jest zablokowany. Jeśli masz wiele zapytań linq lub wyrażeń lambda, funkcja edycji i kontynuacji szybko stanie się dobrą starą rzeczą. Ok, trochę przesady ... ale :)

W vb.net, gdy utworzysz nazwę metody i stukniesz Enter, automatycznie utworzy się „end sub”. W c #, zrób to sam. Ok, jeśli masz zainstalowany resharper lub devexpress, będzie lepiej, ale dlaczego wszystkie te małe, ale wspaniałe funkcje nie zostały zaimplementowane w języku c #.

W vb.net, kiedy masz błędy w kodzie, są one automatycznie wyświetlane, a kiedy je poprawisz, błędy te są usuwane ze stosu w czasie rzeczywistym. W c # musisz zbudować swój projekt, aby zdać sobie sprawę, że pomyślnie poprawiłeś określone błędy lub nie. Dlaczego zespół c # nie ma opcji weryfikacji błędu w czasie rzeczywistym, tak jak w vb.net. Dzięki dużemu rozwiązaniu żadna weryfikacja błędu w czasie rzeczywistym nie może być bardzo dobrą optymalizacją wydajności, ale uwielbiam widzieć, jak stos błędów znika, gdy go poprawiam.

Jak wspomniała inna osoba, myślę, że łatwiej jest odczytać warunek vb.net, jeśli… i jeśli, wybierz przypadek… zakończ wybierz, ale z nawiasami malarskimi devexpress, zapomnij o tym, co powiedziałem.

Dzięki vb.net w studiu wizualnym jest wiele błędów. Wystarczy wspomnieć o jednym w Visual Studio 2010, intellisensy nie filtrują poprawnie wyliczenia, jeśli aktywowano tryb „common” zamiast „all”.

Dzięki vb.net jesteś postrzegany jako manekin, ponieważ statystycznie więcej złych programistów używa vb.net zamiast c #, ponieważ c # jest trudniejszy do nauczenia się i promowania lepszej praktyki programowania.

Jak inni mówili, programista c # ma większą szansę na dobrą pracę z większymi pieniędzmi.

W głowie klienta, vb.net = facet, który programuje w swojej piwnicy za pomocą spaghetti kodu. c # = wow, jesteś bardzo inteligentny. Faktem jest, że to nie dlatego, że programujesz w języku c #, że tworzysz dobry program, ale statycznie tak.

Po tych wszystkich punktach postanowiłem przekonwertować cały mój kod VB w C #. Programuję ze wszystkimi najlepszymi praktykami zorientowanymi obiektowo, wzorami projektowymi, czystym kodem ze standardami i ścisłą składnią i mogę programować w ten sposób przez 50 lat, ale z perspektywy społeczności nie jestem dobrym programistą. Przekształcę mój kod w c # bez żadnych innych dobrych praktyk i będę inną osobą; świetny facet, którego musisz szanować .....: co za żart ... !!! ale to prawda.

Oto jak na to spojrzeć: Który język jest bardziej popularny między SO a CodePlex? C # lub VB.Net?

Czasami podążanie za stadem jest dobrą rzeczą, ponieważ to stado będzie w stanie Ci pomóc, gdy będziesz go potrzebować. Domyślnie C # będzie szybszy niż Vb.Net. Myślę, że użycie Option Strict może to zrównoważyć. Ostatnim razem, gdy porównywałem IL między tymi dwoma, bezpieczeństwo typu VB.Net ostatecznie zwiększyło IL o około 15%. Przekłada się to na dodatkowe koszty ogólne. I ... biorąc pod uwagę języki, które robią to samo, wezmę ten szybszy. Moja wygoda nie powinna nadpisywać ogólnie mojego doświadczenia użytkownika.

Chciałbym powiedzieć, że jedynym powodem, dla którego BASIC jest nadal popularny, jest to, że był to pierwszy produkt Microsoftu i od 35 lat pchają go sobie do gardła. Powinno było umrzeć dawno temu.

Powiedziawszy to, pracowałem nad dwoma dużymi projektami .NET i oba zostały wykonane za pomocą VB.Net - chociaż było trochę C #, ponieważ albo tłumaczenie było dziwką, albo konstrukcja nie istniała w VB.Net. Jedyną zaletą, jaką widzę w VB.Net, jest to, że edytor Visual Studio jest dla niego znacznie bardziej przyjazny (przynajmniej z mojego doświadczenia) niż w C # - Intellisense wydaje się lepszy, podobnie jak automatyczne formatowanie (zauważ, że ponieważ nie użyłem C # tyle, może brakuje mi czegoś w konfiguracji IDE ...)

Główną wadą VB.Net jest to, że wprowadzili wiele bzdur z ery VB6 z powrotem w .NET 1.x, aby ułatwić konwersję kodu VB6. Te rzeczy wciąż tam są, a kodery VB6 kodują nowy kod, używając tych ... „rozszerzeń” zamiast używać bardziej neutralnych klas / metod .NET / cokolwiek innego. Nie wiem, ile razy pytałem mojego szefa, dlaczego wciąż używa tego badziewia. „Ale… To działa…” Tak. Hej, lubię suka.

Szukając pomocy w Internecie, znalazłem większość rozwiązań w języku C # - sprawdź fora MSDN, różne blogi itp. Książki mają tendencję do skupiania się na języku C #, a jeśli jest wersja VB, to zwykle pojawia się w kilka miesięcy później (np. Pro LINQ .... od Apress.)

Wiele języków ma wspólne pochodzenie w języku C, co znacznie ułatwia przełączanie między C, C ++, C #, Java, PHP i kilkoma innymi. PHP jest tutaj trochę skomplikowane, ale ma wiele konstrukcji podobnych do C. VB? Cóż, to właściwie jego mała rzecz i to wszystko.

Lider projektu w mojej organizacji powiedział mi niedawno, że coraz więcej nowych projektów jest opracowywanych przy użyciu C # zamiast VB - WRESZCIE. Kiedy .NET został wprowadzony w naszej organizacji, mniej więcej oficjalnie zaczęli korzystać z VB.Net z powodu całego kodowania VB6, które już trwało. Moce, które później mi przyznano, że to nie był ich najlepszy ruch.

Jak ktoś wcześniej wskazał, nie powiedziałbym „nie” projektowi VB.Net, ale nadal mam nadzieję, że będzie on powoli eliminowany z nowszych rozwiązań w moim miejscu pracy.

Cóż, dzisiaj nie ma praktycznie żadnego powodu do korzystania z VB.net. Na początku był to tylko sposób, aby dać programistom VB znaną składnię, ale zasadniczo był to podobny do BASICa remapowanie C #. Tak więc jego jedyną prawdziwą zaletą jest bardziej znana składnia, a składnia BASIC jest również jej prawdziwym ograniczeniem.

Z biegiem czasu oba języki ewoluowały obok, jedyną znaczącą różnicą jest my pseudo przestrzeń nazw.

Poradziłbym każdemu programistowi .net, który nie zna C #, aby się tego uczył, ponieważ społeczność jest dość większa, a składnia podobna do C jest wspólna dla większości częściej używanych języków.

VB język jest łatwiejszy do odczytania dla początkujących, zwykle piszą w nim swoją pierwszą, drugą i trzecią aplikację, a wszyscy wiemy, jak są zakodowane nasze pierwsze aplikacje - strasznie.

Programiści z C ++, Java itp. Przenieśli się do C #, podczas gdy programiści VB.NET pochodzą z VBA, VB i BASIC, co jest istotnym, nietradycyjnym programistą.

Wydaje się, że jest więcej próbek kodu C # online niż próbek VB.NET. Nie tak trudno jest przekonwertować jeden na drugi, ale po co męczyć się, jeśli nie musisz.

Wolę VB .Net niż C #,

• (97) ...
• (98), ponieważ nauczyłem się VB, zanim jeszcze wiedziałem o C #.
• (99), ponieważ kupiłem już 10 000 stronicową książkę w VB .Net.
• (100), ponieważ VB nie ma nawiasów klamrowych.
• (101) ponieważ wszyscy nienawidzą VB.

DO#. To tylko dlatego, że zrobiłem C i Java, więc uważam, że C # jest dla mnie bardziej czytelny. C # jest dla mnie, podobnie jak VB.NET dla byłych programistów VB.