VB.Net vs C # 토론 [닫기]


18

프로젝트를 시작할 때 "VB.Net 또는 C #을 사용해야합니까?"라는 질문이 제기 된 직장에있었습니다.

물론 언어 통합에 대한 추세를 고려할 때 .Net의 초기보다 지금 결정을 내려야하는 경우는 드물지만 여전히 논쟁의 여지가 있습니다.

VB.Net과 C # 사이에서 어떤 언어를 선호하며 왜 그런가요?


2
작업에 스패너를 던지기 위해 VB.Net 구문 지원 하는 일부 제품 (예 : VS2010의 WF 디자이너)이 있습니다.
Damovisa

여기에서 C # 프로그래머는 VB.NET 프로그래머보다 더 많은 돈을받습니다.
SeanX

제목의 "영원한"부분은 실제로 "구체적이지 않은"것으로 보였습니다. 질문 자체는 매우 유용하며 답변의 질은 악명 높은 "6 가지 지침"을 구성하는 방법을 훨씬 잘 나타냅니다.
Wizard79

VB.NET을 사용하는 사람들이 더 희귀하고 더 높은 프리미엄을 명령 할 수 있도록하는 C # 추세가 계속된다면 이것이 저절로 반전 될지 궁금합니다.
JohnFx

답변:


29

VB.NET보다 C #을 선호합니다.

  • 프로그래머 / 작업을 찾는 것이 더 쉽습니다.

대체 텍스트

  • 도움을받는 것이 더 쉽습니다.

대체 텍스트

(스택 오버 플로우에서)


3
+1 SO는 내가 선호하는 프로그래밍 도움말 소스로 Google을 빠르게 대체합니다.
익명 유형

12
문제는 C # 태그가 10 배 더 많으면 주제가 더 잘 다루거나 더 많이 사용되거나 더 많은 문제가 있음을 의미합니까? 작업 가용성 +1
JeffO

12
C #을 수행하기 위해 VB.NET 프로그래머를 고용하지 않는 고용주에 대해 조심할 것입니다.
Matt Olenik

@Anonymous : SO가 Google을 2 일째 (1 년 전) 대체했습니다. 집에있는 FireFox에는 3 개의 주요 검색 사이트 인 SO, MSDN 및 Programmer가 있습니다.
IAbstract

@IAbstract, lol, 사실입니다.
익명 타입

27

VB.NET이 싫습니다. 여전히 사용하는 날은 후회하는 날입니다. 즉, 내 취향은 내 상황과 경험의 일부이며 반드시 당신이하는 일과 관련이있는 것은 아닙니다 ...

C # 및 VB.NET과 같이 끊임없이 진화하는 언어를 비교할 때 기록을 되돌아보고 현재 상태에 어떻게 도달했는지 확인하는 것이 중요하다고 생각합니다.

마이크로 컴퓨터에서 BASIC의 원래 장점은 크기와 단순성 (작고 합리적으로 빠른 해석기를 위해 작고 해석하기 쉬운 구문과 실제 프로그램과 데이터를위한 메모리에 남은 공간), 실험을 가능하게하는 대화식 환경 및 구문을 포함했습니다. 그것은 영어와 유사한 구문을 위해 간결한 기호와 구조를 피했다. 그러나 대규모의 구조화 된 프로그램에는 적합하지 않았으며 스파게티 코드를 권장하는 경향이있었습니다. 그럼에도 불구하고 가용성과 단순성으로 인해 프로그래밍 소개에 탁월한 선택이되었습니다.

QuickBasic은 더 많은 구조화 된 프로그램을 허용하도록 구문을 업데이트했으며 더 빠른 실행을 위해 컴파일을 추가했습니다.

VisualBasic은 강력하고 사용하기 쉬운 폼 빌더를 제공하여 GUI 응용 프로그램을 신속하게 구축 할 수 있도록하면서 이러한 UI 스크립팅에 사용할 QB 구문을 채택했습니다. 사전 빌드 된 구성 요소 (일반적으로 다른 언어로 작성)로 제공되는 저수준 논리에 대한 UI를 만드는 데 가장 효과적입니다. 시간이 지남에 따라 새로운 기능이 도입되면서 구문이 점점 커지고 일관성이 떨어졌습니다. UI를 먼저 작성하고 약간의 스크립트를 작성하는 데 중점을 두는 것은 UI 중심의 소규모 앱에서는 잘 작동했지만 복사, 붙여 넣기 프로그래밍 및 스파게티 코드 변형을 권장하면서 재사용, 복잡한 데이터 구조 및 우려의 분리. 많은 사람들의 생각에 "VB 코드"는 "큰 진흙탕"과 동의어가되었습니다. "무적 해킹"이있는 "VB 프로그래머".

VB.NET은 자란 VB 구문을 정리하고 현대화하려는 시도 (전적으로 성공하지는 못함) 인 .NET 플랫폼의 VB와 유사한 언어입니다. 기존 VB 코드와 완벽하게 호환되지 않았으며 VB 형식 ( VB 의 가장 중요한 부분) 과의 호환성을 제공하려는 노력을 기울이지 않았습니다 . 이로 인해 많은 VB 제품 소유자는 VB.NET에서 응용 프로그램을 효과적으로 다시 작성하거나 (심히 조사하지 않은 모든 루틴에서 미묘한 비 호환성 처리) 실제로 C #에서 응용 프로그램을 재 작성하는 (불필요한 처리) 불쾌한 선택을 할 수있었습니다. 이외에 구문새로운 런타임 라이브러리 및 양식 디자이너). 대부분의 VB.NET 사용자는 CB를 배우는 동안 목발로 사용하는 구문 만 사용하는 VB 사용자였습니다. 결과적으로, 그것은 기술에 기꺼이 확장하거나 향상 시키려고하지 않거나 자신의 방식에 갇히게 된 프로그래머들을위한 피난처로 즉시 명성을 얻었습니다.

이 시점에서 VB.NET은 새롭고 흥미로운 구문 (LINQ, XML 리터럴)을 선택하면서 수하물을 천천히 흘리면서 계속 발전하고 있습니다. 여전히 BASIC의 원래 장점은 거의 유지하지 못합니다. 상당히 가파른 학습 곡선과 대화식 실험 기회가 제한된 크고 복잡한 언어입니다.

  • 지난 30 년 이상이 문제를 고수 한 오래된 프로그래머에게는 제한되지 않는 한 나쁜 선택이 아닙니다.
  • 새로운 프로그래머들에게 점점 더 모호한 VB 프로그램과 영어의 유사점은 이전 버전과의 호환성과 사회적 낙인에 대한 기괴한 끄덕임이 거의 없습니다.
  • 프로젝트의 경우 VB.NET은 프로젝트가 언어에 최적화 된 몇 가지 작업 중 하나에 크게 관여하지 않는 한 이상한 선택입니다. 형식이 잘못된 COM 구성 요소 (Office ...)와의 통합 (C # 4.0은이 이점을 상당히 줄이지 만 ) 또는 인라인 XML 생성

4
C # 4를 사용하면 VB.Net이 COM 통합과 관련하여 여전히 이점을 보지 못합니다. 인라인 XML 생성이 유용한 기능이라고 생각합니다. XML을 사용하지 않고 (최근 5 년간 성공했습니다!) 많은 XML을 생성해야하는 .net 프로젝트가있는 경우 XML 생성을 위해 VB 프로젝트를 만들 것입니다.
구성자

3
나는 당신의 대답을 읽는 것을 즐기고 있었지만 갑자기 멈추는 것처럼 보였습니다. 당신은 흥미로운 기본의 역사를 제공하고 나는 올바른 것으로 가정합니다. VB.NET을 싫어하는 이유 및 / 또는 C #을 좋아하는 이유를 알고 싶습니다. "새로운 프로젝트의 경우 VB.NET은 이상한 선택입니다"왜?
Tim Murphy

@Tim : VB [.NET]은 내가 싫어하는 대부분의 코드가 몇 년 전 직장에서 코드를 가져 왔거나 프로그래머가 작성한 형식화되지 않은 스파게티 코드이기 때문에 VB [.NET]를 싫어합니다. 그렇다고 다른 사람 이 싫어하는 이유는 아닙니다. 더 좋은 이유는 단순히 언어가 이전 버전과의 호환성에 너무 많은 양보를했지만 실제로 이전 버전과 호환되지 않기 때문입니다. 따라서 새로운 형식화되지 않은 스파게티 코드 를 작성하지 않으려면 ...
Shog9

20

둘 다에 익숙하지만 VB4, VB5 및 VB6에서 초기 프로그래밍 작업을 많이했습니다. .NET의 두 언어가 몇 번의 반복을 거쳐 그 기능이 상당히 수렴되었으므로 토론은 "무슨 마음에 드는 색"과 매우 유사하다고 생각합니다.

개인적으로, 나는 다른 이유로 두 가지를 좋아합니다.

VB.NET
많은 사람들이 C # 구문이 더 직관적 인 방법에 대해 이야기하지만, 그것은 매우 주관적이고 당신이 알고 시작한 것에 크게 의존합니다. 나는 당신이 완전히 객관적이라면 VB.NET 문법이 다른 언어로 사전 지식을 가지고 있지 않다면 더 직관적이라고 주장합니다. 예를 들어, C # 및 VB.NET에서 동일한 프로그램을 사용하면 프로그래밍에 대해 잘 모르는 사람이 더 해독 할 수 있다고 생각합니다. 나에게 꽤 분명한 것 같습니다.

이 구문에서 좋은 또 다른 점은 브라케팅 모델과 비교하여 닫는 구조 (END IF, END WHILE, NEXT X)에 대해 훨씬 더 명확하다는 것입니다. 코드를 좀 더 읽기 쉽게 만들고 종종 컴파일러가 정확히 어떤 라인 번호로 컴파일 오류를 일으키는 지 더 정확하게 할 수 있습니다. 문제에서 50 줄 떨어진 컴파일러 오류로 인해 누락 된 대괄호 / 세미 콜론 사냥을 한 적이 있다면 무슨 뜻인지 알 것입니다.

또한 VB.NET win 열에는 비교 / 할당 연산자로 == / = 부족합니다. 각각에 대해 별개의 운영자가 있다고해서 드물게 이점을 만들어내는 데 도움이되는 모든 사실을 발견하기는 어렵습니다.

마지막으로 프로그래밍 언어의 대소 문자 구분이 싫습니다. VB에 대한 불만 중 하나는 수하물이 너무 많다는 것입니다. 그러나 C #은 C의 대소 문자 구분에 대한 경고를 이월했습니다. 나는 같은 범위에있는 두 식별자가 경우에 따라 다른 것을 원했던 적이 없었습니다. 그것은 바쁜 일을하고 나를 느리게합니다. VB.NET은 나와 관련하여 C #보다 몇 가지 포인트를 얻습니다.

C #
프로그래머는 간결한 것을 좋아하므로 일반적으로이 구문을 선호한다고 생각합니다. 그것은 단지 미적 매력을 가지고 있습니다. 그러나 완전히 실용적인 관점에서 Java, JavaScript 및 C ++와 같은 언어와 유사하기 때문에 좋아합니다.

서버와 클라이언트 측 프로그래밍이 필요한 많은 웹 개발을 수행하기 때문에 자주 수행해야하는 C #과 JavaScript 간을 쉽게 전환 할 수 있습니다.

또한 Java 또는 C ++ 프로그래밍으로 전환 해야하는 경우 C #을 대부분 사용하면 약간의 헤드 스타트가 필요하다는 사실이 마음에 듭니다.


3
웹 개발 댓글 +1 프로젝트에 따라 VB.NET과 C #을 모두 사용하며 VB.NET과 JS보다 C #과 Javascript 간을 전환하는 것이 훨씬 쉽습니다.
Paperjam

2
'같은 범위에있는 두 개의 식별자가 경우에 따라 달라지기를 원하는 상황에는 없었습니다.' 순수한 주관적입니다. 이것이 바로 C #을 선호하는 이유 중 하나입니다. 올바르게 적용 및 결과의 경우, 세계의 모든 감각, 예를 들어 이름이 생성자의 매개 변수를 가지고 만들 수도 name와 이름의 공공 재산을 Name하고이를 통해 지정 Name = name;. 코딩 표준을 유지하는 한 동의하지 않으면 혼동 될 수 있습니다.
Aidiakapi

1
교활한 버그를 피하기 위해 코딩 표준이 필요하다는 것은 나에게 부정적인 것입니다. 해결 방법이 있다고해서 변명 할 수는 없습니다.
JohnFx

프로그래밍 언어로 조잡한 코드를 작성하는 것은 어렵습니다. 대소 문자를 구분하지 않으면 코드가 느슨해집니다. 대 / 소문자를 구분해도 속도가 느려지지 않습니다. 어떤 주장입니까? 많은 오타를 만들면 속도가 느려지고 속도가 느려지는 것이 좋습니다.
팔콘

컴파일러가 해석 할 수 없기 때문에 조잡한 코드 일뿐입니다. 모든 컴파일러가 대소 문자를 구분하지 않으면 핥아 두지 않아도됩니다. 우리의 일은 잡지에 인쇄 할 코드를 작성하는 것이 아니라 작업을 수행하는 코드를 작성하는 것입니다. "느슨한"경우는 그 한 비트를 방해하지 않습니다.
JohnFx

19

나는 C- 스타일 언어의 대괄호 구문을 BASIC- 스타일 언어의 더 "상세한"구문보다 선호합니다.

프로그래밍에 대한 나의 소개는 Turbo Pascal에 관한 것이었다. (Commodore 64에서 내가 한 어린 시절 BASIC 프로그래밍은 실제로 계산되지 않습니다.) Java를 배우고 난 뒤돌아 보지 않았고 C 스타일 구문을 선호했습니다.


4
"기본 스타일 언어의"자세한 "구문." -그래, 나는 VB를 다시 보지 않았다if something then code endif
TheLQ

1
허, 나는 누군가가 이것을 하향 조정 한 것에 놀랐다. (I는 빔 질문 대 이맥스를 수를 예상했다.)
조지 마리아

3
@ TheLQ : 그리고 또한 AndAlso!
Gerry

터보 파스칼 시절이 그리워요. 그것은 많은 재미이었다.
MetalMikester

1
대괄호 구문을 쉽게 읽을 수 있습니다. 문맥 상 특정 단어가 아닌 블록에 대한 하나의 일반적인 기호.
Michael K

12

그것들은 기능적으로 동일하고, 다른 하나에서는 할 수없는 일이 없으며, 미래에 Microsoft는 언어 팀이 균등하게 개발할 것이라고 약속했습니다.

이제 차이점은 순전히 문화적이며 개인적입니다. 이 기사는 C #과 VB.net을 사용하는 프로그래머 문화의 차이점에 대한 흥미로운 글입니다.

[참고 : 저는 C # 개발자이지만 링크 된 기사의 결론은 반드시 내 개인적인 의견을 반영하지는 않지만 토론에서 흥미로운 대안 적 접근 방식입니다.]


8
예를 들어 VB.NET에는 훌륭한 C # 기능인 반복자가 없습니다 .
Thomas Levesque

2
C #에는 VB.NET의 XML 리터럴이 없습니다 : blogs.msdn.com/b/wriju/archive/2008/02/07/… (건축상의 이유로이 기능의 팬은 아니지만 멋지다)
Steven Striga

@Thomas @WeekendWarrior : 좋은 예이지만, "함수 적으로 동일하다"고 말했습니다. 둘 다 IL로 컴파일되므로 동일한 기능 세트를 얻을 수 있습니다. 이 예제는 다른 방식으로 수행 할 수있는 기능에 대한 언어 바로 가기입니다.
Simon P Stevens

8

C와 C ++에서 .NET에 왔습니다 (약간의 Java, Ada 및 Pascal이 던져져 있음). C #은 저에게 자연스러운 진보였습니다.

VB.NET에 필요한 작업이 있었다면 분명히 거절하지 않았을 것입니다.


6

VB.NET으로 많은 작업을 수행했지만 코드에서 발생하는 일을 파악할 수있는 충분한 C #을 알고 있습니다. 현재의 환경 설정은 VB.NET입니다. (분명히) 가장 익숙하기 때문에 자세한 BASIC 구문과 C 스타일 구문 사이의 환경 설정이 없으므로 읽기 쉽고 이해할 수 있습니다.

동료의 프로그래밍 배경은 대부분 COBOL과 VB6이므로 VB.NET은 팀으로서 우리에게 더 편안한 .NET 언어 선택이었습니다. 기능적으로 동일하기 때문에 C # 학습을 필수 요건으로 만든 확실한 이유는 없었습니다.

즉, C #을 배우는 것이 가장해야 할 일 목록에 있습니다.


2
나는 같은 문제에 처해있다. :) 그리고 나는 펩시가 아닌 콜라를 선호하는 것과 같은 방식으로 VB.NET을 선호합니다. 그러나 새로운 프로젝트를 시작한다면 C #을 알고 선호하는 더 많은 프로그래머를 찾을 수 있기 때문에 C #이 최선의 선택입니다. VB에 대한 MS 전략은 VB 커뮤니티를 .NET 플랫폼으로 불러오는 것이 었습니다.
Pagotti

5

나는 C #을 선호합니다.

VB.NET 프로그래머로 시작했지만 시간이 지남에 따라 많은 새로운 기능이 C #에 먼저 들어온 후 VB.NET에 자동으로 제공된다는 것이 분명해졌습니다. 그리고 C #을 둘러싼 커뮤니티는 VB.NET보다 훨씬 활발합니다.

또한 Java 또는 유사한 언어를 배우려는 경우 C #이 더 좋습니다. 구문은 모든 C 파생 언어에서 거의 동일합니다. 구문은 당신이 어쨌든 빨리 배울 수있는 것이므로 이것이 나에게 요점은 아닙니다.


3
"기능이 C #에 먼저옵니다"항상 그런 것은 아닙니다. stackoverflow.com/questions/181188/…을 참조하십시오. (작품에 다른 스패너를 던져야 함)
자기주의 사항-이름을 생각하십시오.

내가있는 곳입니다. VB를 좋아합니다 .VB는 처음부터 시작했지만 C #은 람다 식과 같은 구문에서 더 나은 구문을 가지고 있습니다. 반면에 VB에는 C # 만 꿈꾸는 XML 리터럴이 있습니다. 무거운 XML 작업을 위해 별도의 VB 프로젝트를 중단 할 가치가 있다고 생각합니다.
Kyralessa

1
각 세대의 도구에서 "기능"인수는 약간 이동합니다. vb.net이 부족한 vs2010에서 C #이 가진 유일한 것은 반복자입니다. 반대로 vb.net은 명명 된 인덱서, 예외 필터, XML 리터럴, "보다"1000 배 더 나은 "Is"연산자 Object.ReferenceEquals, 거의 제대로 수행 된 이벤트 처리 및보다 부드러운 IDE 경험을 제공합니다. VB.net은 약간 어색하지만 필드 이니셜 라이저가 생성자 매개 변수 IDisposable를 사용하거나 ThreadStatic변수 를 사용할 필요없이 안전하게 객체를 만들 수있게 합니다. C #은 그렇지 않습니다.
supercat

5

여기에 게시 된 다른 답변 외에도 C # 프로그래머가 더 많은 돈을 지불하기 때문에 VB 대신 C #을 선택합니다. C #에 대한 더 많은 경험 = 더 많은 $$ :)

나는 두 언어가 거의 동일하고 두 언어 사이를 전환하기가 쉽다는 것을 알고 있지만 경영진이 중괄호와 세미콜론을 볼 때 VB를 사용하여 할 수없는 일을한다는 것을 받아들입니다. 그들은 그들이 그것을보고 "내가 이해할 수 있다면 그렇게하기 어려워서는 안된다"고 갈 수 있습니다.


1
나는 산업 / 지역에 따라 종종 간과되는 다소 유효한 점을 생각합니다.
익명 타입

4

최소한의 노력으로 Java와 Java를 전환 할 수 있기 때문에 C #

VB.NET은 완전히 다른 구문입니다. C #은 Java 및 기타 언어와 유사하므로 새로운 것에 빠르게 적응할 수있는 더 나은 위치를 제공합니다. C #과 VB.NET의 출력은 거의 상호 교환이 가능하므로 C #과 함께 사용하는 것이 좋습니다. 또한 회사 코드가 C # 인 경우 Java 개발자 VB보다 C #을 코딩하는 방법을 Java 개발자에게 교육 할 가능성이 높습니다. 미묘한 장점 만 있지만 미묘한 장점이 여전히 있습니다.


3

내 개인적인 취향을 제쳐두고. 요즘 우리가 사무실에서이 토론을했을 때 신입 사원 모집을하려는 사람은 VB에서 C #으로 옮겨야한다는 일반적인 합의가있었습니다.

왜? C #이 시장에서 더 널리 보급 되었기 때문에 (어쨌든), 더 쉽게 채용하고 더 쉽게 채용 할 수 있습니다.

완전히 사라진 것 같습니다. 더 많은 후보자가 있기 때문에 모집자가 원하기 때문에 사람들은 C #을 배우게됩니다.


3

다소 나이가 많은 개발자 (59 "약간 나이가 더 많습니까?") 인 저는 Commodore VIC-20에서 BASIC을 처음으로 배웠으며 Turbo Pascal (v1!)을 가르쳤으며 대학에서 COBOL을 배우고 14 년 동안 IBM에서 개발했습니다. VB5 및 VB6으로 넘어 가기 전에 Revelation BASIC (PICK BASIC의 변형)에서 중간 크기의 앱을 작성하고 Modula-2의 몇 가지 유틸리티를 작성하는 간단한 전환 기능이있는 메인 프레임. 그런 다음 .NET이 나왔습니다.

기본 배경으로 인해 VB.NET으로 시작해야한다고 생각했는데, "오래된"방식으로 일을 계속하려고했지만 견과류 (좋아요, 더 많은 견과류)를 만들어 내고있었습니다 . C에서 몇 가지 작업을 수행했기 때문에 C #에 어떻게 진행되는지 볼 수있는 소용돌이를 줄 것이라고 생각했습니다. 그리고 OMG, 그것은 어두운 터널에서 맑은 일광으로 떠오르는 것과 같았습니다! 완전히 예상치 못한. 그리고 저는 C가 "쓰기 전용"언어라는 것에 대해 혼란 스러웠습니다. "C 프로그래머가 코드를 작성한 후 6 개월 만에 자신의 코드가 무엇을했는지 알 수 없었습니다." 당시 귀엽게 들렸다 고 생각한 반 유명 소설가

따라서 C에 익숙하지 않기 때문에 C #은 훨씬 더 친숙한 기본 패러다임보다 .NET 프로그래밍을 배우는 것이 역설적으로 쉽습니다. 나는 여전히 VB6을 좋아하지만 C #을 좋아하게되었습니다. 지구상에서 최고의 프로그래밍 언어.


1
재미있는 대답, 나는 "오래된 군중이"C 번호를 통해 VB.NET에 충실 경향이 부분적으로 아이디어를 정체를 폭로 적어도이 생각
익명 유형

3

2001 년부터 Visual Basic .Net에서 개발했으며 그것을 좋아하고 싫어합니다 !!!

이 요점을 제시하는 순서는 그가 내 마음에 온 순서를 기반으로합니다 ...

Visual Studio를 사용하는 vb.net에는 각 메서드, 속성 사이에 시각적 줄 바꿈이 있습니다. 많은 사람들에게 C #보다 vb.net을 선호하는 것이 좋은 이유는 아니지만 Microsoft의 C # 팀에서 구현하지 않은 이유를 이해하지 못합니다. 이 줄을 C #에 그려주는 추가 기능이 있지만 Microsoft와 다시 대화하지 않는 AC # 팀과 Visual Basic 팀이 있습니다.

vb.net에서 winform을 만들 때 편집기 상단에 Visual Studio에 두 개의 콤보 상자가 있으며 오른쪽 콤보 상자에서 이벤트를 선택할 때 자동으로 이벤트를 생성 할 수 있습니다. 매일 수십 개의 이벤트를 첨부하면이 기능이없는 것이 매우 번거로울 수 있습니다. C #을 사용하면 속성 표 상단에 작은 버튼이있어 이벤트를 생성 할 수 있지만 vb.net과 같이 빠르지는 않습니다. 또한 C #에서 제어 이벤트를 첨부하고 양식에서 제어를 삭제하는 경우 자동 생성 코드에서 작성된 이벤트를 처리하기 위해 위임을 수동으로 삭제해야합니다. 다시 한번 감사합니다.

vb.net에서 쿼리 자체를 수정하지 않고 linq 쿼리가 포함 된 메서드를 수정하려고하면 문제는 없지만 C #에서는 모든 메서드 코드가 잠 깁니다. linq 쿼리 나 람다식이 많으면 편집 및 계속 기능이 빠르게 좋은 예가됩니다. 좋아, 약간의 과장 ...하지만 :)

vb.net에서 메소드 이름을 생성하고 Enter를 누르면 'end sub'가 자동으로 생성됩니다. C #에서는 직접하십시오. 좋아, resharper 또는 devexpress가 설치되어 있으면 더 좋을 것입니다. 그러나이 작지만 큰 기능이 모두 C #으로 구현되지 않은 이유는 무엇입니까?

vb.net에서 코드에 오류가 있으면 오류가 자동으로 표시되고 오류를 수정하면 이러한 오류가 스택에서 실시간으로 제거됩니다. c #에서는 지정된 오류를 성공적으로 수정했는지 확인하기 위해 프로젝트를 빌드해야합니다. C # 팀이 vb.net과 같이 실시간 오류를 확인하는 옵션을 제공하지 않은 이유는 무엇입니까? 큰 솔루션을 사용하면 실시간으로 오류를 확인할 수는 없어도 성능을 최적화 할 수는 없지만 오류를 수정하는 동안 오류가 발생할 수 있습니다.

다른 사람이 언급했듯이, 나는 vb.net 조건을 읽는 것이 더 쉽다고 생각합니다. if..end if, select case ... end select 그러나 devexpress painting bracket, 내가 말한 것을 잊어 버려요.

vb.net을 사용하면 Visual Studio에 많은 버그가 있습니다. Visual Studio 2010에서 하나만 언급하면 ​​"all"대신 "common"모드를 활성화 한 경우 인텔리전스가 올바르게 열거하지 않습니다.

vb.net을 사용하면 정적으로 더 나쁜 프로그래머가 c # 대신 vb.net을 사용하기 때문에 더미 사람으로 인식됩니다.

다른 말했듯이, C # 프로그래머는 더 많은 돈으로 좋은 직업을 가질 수있는 더 좋은 기회가 있습니다.

고객의 머리에 vb.net = 지하실에서 코드 스파게티를 사용하여 프로그래밍하는 사람. C # = 와우, 당신은 매우 똑똑합니다. 사실은 C #으로 프로그래밍하기 때문이 아니라 좋은 프로그램을 만들지 만 정적으로 그렇습니다.

이 모든 점을 가지고 모든 VB 코드를 C #으로 변환하기로 결정했습니다. 나는 객체 지향, 디자인 패턴, 표준 및 엄격한 구문으로 깨끗한 코드의 모든 모범 사례를 사용하여 프로그래밍하고 50 년 동안 그렇게 프로그래밍 할 수 있지만 커뮤니티의 눈에서 나는 훌륭한 프로그래머가 아닙니다. 다른 모범 사례없이 C #으로 코드를 변환하고 다른 사람이됩니다. 당신이 존중해야 할 위대한 녀석 ..... :( 무슨 농담 ... !!!하지만 현실입니다.


2

SO와 CodePlex 사이에서 어떤 언어가 더 인기가 있습니까? C # 또는 VB.Net?

때로는 무리를 따르는 것이 좋은 일입니다. 필요할 때 도움을 줄 수있는 무리이기 때문입니다. 기본적으로 C #은 Vb.Net보다 빠릅니다. Option Strict를 사용하면 평등 할 수 있다고 생각합니다. 마지막으로 VB.Net의 유형 안전성을 IL과 비교했을 때 IL에 약 15 % 더 추가되었습니다. 이것은 추가 오버 헤드로 해석됩니다. 그리고 ... 기본적으로 같은 언어를 사용하면 더 빠른 언어를 사용합니다. 내 편의가 일반적으로 사용자의 경험보다 우선해서는 안됩니다.


2

BASIC이 여전히 인기있는 유일한 이유는 Microsoft의 첫 번째 제품이었고 지난 35 년 동안 우리의 목을 down 고 있기 때문입니다. 오래 전에 죽었을 것입니다.

그 말로, 나는 두 개의 큰 규모의 .NET 프로젝트를 작업했으며 VB.Net으로 모두 수행되었습니다. 번역이 나쁜 것이거나 구조가 VB.Net에 존재하지 않았기 때문에 약간의 C #이있었습니다. VB.Net에서 볼 수있는 유일한 장점은 Visual Studio 편집기가 C #보다 훨씬 친숙하다는 것입니다 .Intellisense가 더 좋아 보이며 자동 서식도 마찬가지입니다 (C #을 사용하지 않았으므로 참고하십시오) IDE 구성에서 뭔가가 누락되었을 수 있습니다 ...)

VB.Net의 주요 단점은 VB6 코드를 쉽게 변환 할 수 있도록 .NET 1.x에서 많은 VB6-era 크랩 방식을 가져 왔다는 것입니다. 그 물건은 여전히 ​​거기에 있으며 VB6 코더는 더 중립적 인 .NET 클래스 / 메소드 / 무엇이든 사용하지 않고 "확장자"를 사용하여 새로운 코드를 코딩하고 있습니다. 상사에게 왜 아직도 그 쓰레기를 사용했는지 물어 본 적이 없습니다. "하지만 ... 작동합니다 ..."맞습니다. 이봐, 난 나쁜 년을 좋아해

웹에서 도움을 찾는 동안 방대한 솔루션이 C #에 있다는 것을 알았습니다. MSDN 포럼, 다양한 블로그 등을 확인하십시오 ... 책은 C #에 중점을 두는 경향이 있으며 VB 버전이 있으면 일반적으로 몇 개월 후에 제공됩니다 (예 : Apress의 Pro LINQ ....).

많은 언어가 Cancestry를 공유하므로 C, C ++, C #, Java, PHP 및 기타 몇 가지를 훨씬 쉽게 전환 할 수 있습니다. PHP는 여기에 약간의 확장이 있지만 C와 같은 많은 구조를 가지고 있습니다. VB? 글쎄, 그것은 거의 그 자체의 작은 것입니다.

조직의 프로젝트 리더가 최근 VB 대신 C #을 사용하여 점점 더 많은 새로운 프로젝트가 개발되고 있다고 말했습니다. .NET이 우리 조직에 소개되었을 때, 그들은 이미 진행중인 모든 VB6 코딩 때문에 VB.Net과 함께 공식적으로갔습니다. 나중에 나에게 인정 된 힘은 그것이 최선의 움직임이 아니라는 것입니다.

위의 다른 사람이 지적했듯이 VB.Net 프로젝트는 거부하고 싶지 않지만 여전히 작업장의 새로운 개발에서 천천히 사라지기를 바라고 있습니다.


1

오늘날 VB.net을 사용해야 할 이유는 거의 없습니다. 처음에는 VB 프로그래머에게 친숙한 구문을 제공하는 방법 일 뿐이지 만 기본적으로 C #의 기본 유사 리 맵핑이었습니다. 따라서 유일한 장점은보다 친숙한 구문이며, BASIC 구문도 그 유일한 한계입니다.

시간이 지남에 따라 두 언어가 함께 발전해 왔지만 my 의사 네임 스페이스 는 큰 차이가 있습니다.

C #에 익숙하지 않은 모든 .net 프로그래머에게 커뮤니티가 상당히 커지고 C와 유사한 구문이 더 많이 사용되는 언어에 공통적이기 때문에 조언합니다.


VB.NET이 존재하는 이유에 대한 또 다른 중요한 고려 사항은 ASP "Classic"/ VBScript 또는 VB6에있는 프로젝트의 업그레이드 경로가 더 쉽다는 것입니다. 기존의 큰 응용 프로그램을 이식하는 작업이 훨씬 줄었습니다.
JohnFx

1

VB 언어는 초보자가 읽기 쉽고, 첫 번째, 두 번째 및 세 번째 응용 프로그램을 작성하는 경향이 있으며, 첫 번째 응용 프로그램의 코딩 방식을 모두 알고 있습니다.

C ++, Java 등의 프로그래머는 C #으로 이동 한 반면 VB.NET 개발자는 필수 비 전통적 프로그래머 인 VBA, VB 및 BASIC 배경에서 왔습니다.


1

VB.NET 샘플보다 온라인에서 더 많은 C # 코드 샘플이있는 것 같습니다. 하나를 다른 것으로 변환하기가 그다지 좋지는 않지만, 필요하지 않은 경우 왜 귀찮게합니까?


1

C #보다 VB .Net을 선호합니다.

  • (97) ...
  • (98) C #에 대해 알기 전에 VB를 배웠기 때문입니다.
  • (99) VB .Net에서 이미 10,000 페이지를 구입했기 때문에.
  • VB에 중괄호가 없기 때문에 (100).
  • 모두가 VB를 싫어하기 때문에 (101).

0

씨#. C와 Java를 수행했기 때문에 C #이 더 읽기 쉽다고 생각합니다. VB.NET은 이전 VB 프로그래머를위한 것이기 때문에 C #은 저를위한 것입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.