프로젝트를 시작할 때 "VB.Net 또는 C #을 사용해야합니까?"라는 질문이 제기 된 직장에있었습니다.
물론 언어 통합에 대한 추세를 고려할 때 .Net의 초기보다 지금 결정을 내려야하는 경우는 드물지만 여전히 논쟁의 여지가 있습니다.
VB.Net과 C # 사이에서 어떤 언어를 선호하며 왜 그런가요?
프로젝트를 시작할 때 "VB.Net 또는 C #을 사용해야합니까?"라는 질문이 제기 된 직장에있었습니다.
물론 언어 통합에 대한 추세를 고려할 때 .Net의 초기보다 지금 결정을 내려야하는 경우는 드물지만 여전히 논쟁의 여지가 있습니다.
VB.Net과 C # 사이에서 어떤 언어를 선호하며 왜 그런가요?
답변:
VB.NET보다 C #을 선호합니다.
(스택 오버 플로우에서)
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의 원래 장점은 거의 유지하지 못합니다. 상당히 가파른 학습 곡선과 대화식 실험 기회가 제한된 크고 복잡한 언어입니다.
둘 다에 익숙하지만 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 #을 대부분 사용하면 약간의 헤드 스타트가 필요하다는 사실이 마음에 듭니다.
name
와 이름의 공공 재산을 Name
하고이를 통해 지정 Name = name;
. 코딩 표준을 유지하는 한 동의하지 않으면 혼동 될 수 있습니다.
나는 C- 스타일 언어의 대괄호 구문을 BASIC- 스타일 언어의 더 "상세한"구문보다 선호합니다.
프로그래밍에 대한 나의 소개는 Turbo Pascal에 관한 것이었다. (Commodore 64에서 내가 한 어린 시절 BASIC 프로그래밍은 실제로 계산되지 않습니다.) Java를 배우고 난 뒤돌아 보지 않았고 C 스타일 구문을 선호했습니다.
if something then code endif
그것들은 기능적으로 동일하고, 다른 하나에서는 할 수없는 일이 없으며, 미래에 Microsoft는 언어 팀이 균등하게 개발할 것이라고 약속했습니다.
이제 차이점은 순전히 문화적이며 개인적입니다. 이 기사는 C #과 VB.net을 사용하는 프로그래머 문화의 차이점에 대한 흥미로운 글입니다.
[참고 : 저는 C # 개발자이지만 링크 된 기사의 결론은 반드시 내 개인적인 의견을 반영하지는 않지만 토론에서 흥미로운 대안 적 접근 방식입니다.]
VB.NET으로 많은 작업을 수행했지만 코드에서 발생하는 일을 파악할 수있는 충분한 C #을 알고 있습니다. 현재의 환경 설정은 VB.NET입니다. (분명히) 가장 익숙하기 때문에 자세한 BASIC 구문과 C 스타일 구문 사이의 환경 설정이 없으므로 읽기 쉽고 이해할 수 있습니다.
동료의 프로그래밍 배경은 대부분 COBOL과 VB6이므로 VB.NET은 팀으로서 우리에게 더 편안한 .NET 언어 선택이었습니다. 기능적으로 동일하기 때문에 C # 학습을 필수 요건으로 만든 확실한 이유는 없었습니다.
즉, C #을 배우는 것이 가장해야 할 일 목록에 있습니다.
나는 C #을 선호합니다.
VB.NET 프로그래머로 시작했지만 시간이 지남에 따라 많은 새로운 기능이 C #에 먼저 들어온 후 VB.NET에 자동으로 제공된다는 것이 분명해졌습니다. 그리고 C #을 둘러싼 커뮤니티는 VB.NET보다 훨씬 활발합니다.
또한 Java 또는 유사한 언어를 배우려는 경우 C #이 더 좋습니다. 구문은 모든 C 파생 언어에서 거의 동일합니다. 구문은 당신이 어쨌든 빨리 배울 수있는 것이므로 이것이 나에게 요점은 아닙니다.
Object.ReferenceEquals
, 거의 제대로 수행 된 이벤트 처리 및보다 부드러운 IDE 경험을 제공합니다. VB.net은 약간 어색하지만 필드 이니셜 라이저가 생성자 매개 변수 IDisposable
를 사용하거나 ThreadStatic
변수 를 사용할 필요없이 안전하게 객체를 만들 수있게 합니다. C #은 그렇지 않습니다.
여기에 게시 된 다른 답변 외에도 C # 프로그래머가 더 많은 돈을 지불하기 때문에 VB 대신 C #을 선택합니다. C #에 대한 더 많은 경험 = 더 많은 $$ :)
나는 두 언어가 거의 동일하고 두 언어 사이를 전환하기가 쉽다는 것을 알고 있지만 경영진이 중괄호와 세미콜론을 볼 때 VB를 사용하여 할 수없는 일을한다는 것을 받아들입니다. 그들은 그들이 그것을보고 "내가 이해할 수 있다면 그렇게하기 어려워서는 안된다"고 갈 수 있습니다.
다소 나이가 많은 개발자 (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 #을 좋아하게되었습니다. 지구상에서 최고의 프로그래밍 언어.
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 #으로 코드를 변환하고 다른 사람이됩니다. 당신이 존중해야 할 위대한 녀석 ..... :( 무슨 농담 ... !!!하지만 현실입니다.
SO와 CodePlex 사이에서 어떤 언어가 더 인기가 있습니까? C # 또는 VB.Net?
때로는 무리를 따르는 것이 좋은 일입니다. 필요할 때 도움을 줄 수있는 무리이기 때문입니다. 기본적으로 C #은 Vb.Net보다 빠릅니다. Option Strict를 사용하면 평등 할 수 있다고 생각합니다. 마지막으로 VB.Net의 유형 안전성을 IL과 비교했을 때 IL에 약 15 % 더 추가되었습니다. 이것은 추가 오버 헤드로 해석됩니다. 그리고 ... 기본적으로 같은 언어를 사용하면 더 빠른 언어를 사용합니다. 내 편의가 일반적으로 사용자의 경험보다 우선해서는 안됩니다.
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 프로젝트는 거부하고 싶지 않지만 여전히 작업장의 새로운 개발에서 천천히 사라지기를 바라고 있습니다.
오늘날 VB.net을 사용해야 할 이유는 거의 없습니다. 처음에는 VB 프로그래머에게 친숙한 구문을 제공하는 방법 일 뿐이지 만 기본적으로 C #의 기본 유사 리 맵핑이었습니다. 따라서 유일한 장점은보다 친숙한 구문이며, BASIC 구문도 그 유일한 한계입니다.
시간이 지남에 따라 두 언어가 함께 발전해 왔지만 my
의사 네임 스페이스 는 큰 차이가 있습니다.
C #에 익숙하지 않은 모든 .net 프로그래머에게 커뮤니티가 상당히 커지고 C와 유사한 구문이 더 많이 사용되는 언어에 공통적이기 때문에 조언합니다.
C #보다 VB .Net을 선호합니다.