it-swarm-vi.com

Tại sao VB rất phổ biến?

Đối với tôi, Visual Basic có vẻ vụng về, xấu xí, dễ bị lỗi và khó đọc. Tôi sẽ để người khác giải thíchtại sao . Mặc dù VB.net rõ ràng là một bước nhảy vọt lớn về ngôn ngữ về các tính năng, tôi vẫn không hiểu tại sao mọi người lại chọn mã trong VB, giả sử, C #.

Tuy nhiên, tôi vẫn thấy (dường như là vậy) phần lớn các ứng dụng web thương mại từ "cửa hàng MS" được xây dựng trong VB. Tôi có thể sửa chữa điều này, nhưng VB vẫn có vẻ phổ biến hơn nó xứng đáng.

Bất cứ ai có thể giúp trả lời bất kỳ (hoặc tất cả) các câu hỏi sau:

  • Tôi có thiếu điều gì với VB không? Có dễ học hơn, hay "thân thiện" hơn C # không? Có những tính năng nào tôi không biết?
  • Tại sao VB/VB.net được sử dụng thường xuyên ngày nay, đặc biệt là trong các dự án web?
28
aaaidan

VB có thể được sử dụng để tạo GUI (phát âm là gooey) để theo dõi địa chỉ IP. Điều này thường được sử dụng trong giải quyết tội phạm .

47
Rick J

Tôi nghĩ rằng nó phụ thuộc vào nơi bạn đến từ. Khi bắt đầu làm lập trình viên, tôi nghĩ rằng VB có thể là dễ dàng hơn để đọc hơn C #, vì nó phụ thuộc nhiều vào các từ hơn các ký hiệu, giúp dễ dàng hơn để đưa vào cho những người thường xuyên.

Tôi là một lập trình viên VB trong nhiều năm và khi .NET xuất hiện, tôi vẫn làm việc trong VB.NET trong vài năm đầu (không thực sự thấy được điểm nào với C #). Một vài năm sau C # phía sau tôi và đôi khi tôi thấy rằng mã VB.NET mất nhiều thời gian hơn để tôi "giải mã" so với mã C #. Có thể vì nó dựa nhiều vào các từ hơn các ký hiệu cho một số ...

42
Fredrik Mörk

Bên dưới tôi vừa sao chép trả lời chủ đề khác :

Tôi phát triển cả hai VB và C # một cách thường xuyên, hầu hết việc kiếm tiền của tôi có liên quan đến C #. Cá nhân tôi thích VB cho hầu hết (nhưng không phải Tôi thực sự không thể kể tên bất kỳ lợi thế khó khăn nào ngoài những lợi ích được nêu ra bởi Jon. Thật ra, Herfried đã thu thập một số ít trên trang web (bằng tiếng Đức!) nhưng chúng đúng hơn kỹ thuật.

Điều thực sự làm tôi bực mình về tất cả các ngôn ngữ liên quan đến C là cú pháp ngu ngốc. Đây hoàn toàn là văn hóa nhưng là một người làm hầu hết các công việc chuyên môn của mình trong C++ và khá thành thạo về nó, tôi vẫn hoàn toàn ghét cú pháp. Và không chỉ những quirks nhỏ dễ thương của C++. Không, toàn bộ gói. Tại sao phải niềng răng? Tại sao dấu chấm phẩy (có lẽ là quyết định ngu ngốc nhất trong tất cả lịch sử lập trình)? Tại sao cú pháp kiểu C ngu ngốc? Tại sao không có từ khóa để khai báo biến (thực ra, này là quyết định ngu ngốc nhất)?

Có quá nhiều thứ thực sự khiến tôi buồn và tức giận. VB không phải là thánh, ngôn ngữ của nó có nhược điểm rất lớn. Nhưng không có gì so với những gì tôi đã nói ở trên.

Tôi nhận ra rằng hầu hết các tuyên bố này cần sự biện minh nhưng tôi đưa ra rằng điều này chỉ là do chúng ta đã quá quen với chúng. Ngoài ra, đây không phải là nơi thích hợp. Đủ để nói rằng cú pháp của C #, trong khi là lợi thế chính của nó so với VB, cũng là nhược điểm chính của nó.

Tôi không thích VB vì không gian tên My, tôi không thích nó vì chữ XML, tôi không thích nó vì gõ yếu, tôi không 'không thích nó vì các tham số tùy chọn hoặc vì câu lệnh switch tốt hơn nhiều. Không, tôi thích nó hơn vì cú pháp.


Điều đó nói rằng, tôi đã phải thừa nhận rằng VB ngày càng bị vướng bận bởi cú pháp của nó. Sự cường điệu mới nhất dường như là các truy vấn Linq được tham số hóa với các hàm lambda và tôi dễ dàng thừa nhận rằng điều này tạo ra nhiều thứ Thật đơn giản. Thật không may, cú pháp của VB cho lambdas đơn giản là quá cồng kềnh để cạnh tranh với C #. Chỉ cần xem xét cách gọi của Parallel.For trông giống như trong VB - so với C #, nơi có vẻ tự nhiên. IMHO, nhóm thiết kế VB đã đi sai hướng ở đây, thiên về bảo thủ tính nhất quán trên khả năng đọc.


Để trả lời lời buộc tội chủ quan của bạn:

Đối với tôi, Visual Basic có vẻ vụng về, xấu xí, dễ bị lỗi và khó đọc.

Bạn chắc chắn có quyền nghĩ như vậy nhưng như Marc đã nói dưới đây, bạn sẽ khó tranh luận điều này một cách khách quan. Tôi chắc chắn có thể trích dẫn một số các thành phần cú pháp C được một cách khách quan hơn dễ bị lỗi hơn bất cứ thứ gì hiện có trong VB. Trong thực tế, cú pháp VB đã được phát triển để ngăn chặn các tình huống như vậy một cách rõ ràng.

Những người vụng về, xấu xí và khó đọc là tất cả các vòng loại có thể được gắn thẻ vào gần như tất cả các ngôn ngữ mà bạn không quen thuộc. Nói một cách đơn giản: sự xấu xí là hậu quả trực tiếp của việc bạn không quen với ngôn ngữ này.

Biết một ngôn ngữ tốt có nghĩa là nhận ra các mẫu trong mã. Mã được viết tốt sẽ bởi tính thực tế có vẻ thanh lịch, trong khi mã xấu (chậm, dễ bị lỗi) sẽ xuất hiện xấu. Nó đơn giản như vậy.


Một nhận xét cuối cùng: Các bài viết được trích dẫn bởi bạn có chứa một số thông tin không chính xác và lỗi thời. Như một lời biện minh duy nhất cho một cuộc thảo luận mang tính chủ quan và cảm xúc, họ không phù hợp lắm.

27
Konrad Rudolph

Đối với tôi, Visual Basic có vẻ vụng về, xấu xí, dễ bị lỗi và khó đọc.

Đối với tôi, tiếng Anh có vẻ vụng về, xấu xí, dễ bị lỗi và khó đọc, đặc biệt được viết bởi những người có ngữ pháp kém, chính tả kém, coi thường viết hoa và chấm câu, và không có ý thức về cách tổ chức không gian và tinh thần của họ.

Không chỉ Visual Basic khó đọc hay vụng về vì cú pháp của ngôn ngữ, mà nó thường như vậy bởi vì lập trình viên không thực sự giỏi trong việc thể hiện suy nghĩ của chính mình:

If blah = 10 Then If stuff = "foo" Then t = 1 + k: s = 42: dostuff21

Phải, thật kinh khủng. Nhưng nó cũng không khó để viết mã khủng khiếp bằng các ngôn ngữ khác. Khi được viết chính xác, nó sẽ rất có ý nghĩa ngay cả khi mã được viết bằng VB:

If SelectedType = 10 And UserName = "Foo" Then
    CurrentUsers = CurrentUsers + 1
    UserConnectionID = 42
    PerformUserOperation
End If

Ít nhất đó là dễ đọc và dễ hiểu hơn. Nó vẫn CƠ BẢN. Nó thực sự phụ thuộc vào khả năng của lập trình viên thể hiện rõ ràng ý định của mình bằng cách định dạng mã theo cách dễ đọc, sử dụng các định danh được đặt tên tốt và chú ý viết mã dễ hiểu.

Điều đó nói rằng, tôi đã không chạm vào Visual Basic nhiều kể từ ngày VB3, (ví dụ như cú pháp "cũ") nhưng chỉ vì một ngôn ngữ có thể bị lạm dụng không có nghĩa là nó không thể được sử dụng chính xác để viết mã khá mạnh mẽ . Chắc chắn, có thể có một số thiếu sót, nhưng cách tiếp cận được đưa ra để giải quyết những vấn đề đó cũng cho thấy kỹ năng của một lập trình viên so với người khác.

(Phun bừa bãi On Error Resume Next đến với tâm trí như một cách không hay để khắc phục những thiếu sót của việc thiếu ngoại lệ trong VB trở lại trong những ngày trước .NET.)

15
coobird

Hầu hết các đối số của bạn chống lại VB chỉ áp dụng cho VB-Classic (liên kết thứ hai) hoặc dựa trên các đối số mờ nhạt hoặc lỗi thời

  • Ngay cả trong VBC, bạn sẽ không sử dụng GoSub ... Return, v.v.
  • Có gì sai với static? C++ cũng hỗ trợ điều này.
  • VB10 giới thiệu tiếp tục dòng ngầm định (bạn thậm chí không cần dấu chấm phẩy dư thừa như C #)
  • Các hàm cast khác nhau tồn tại trong C++ và C #. C # của (object)(expr)- Cú pháp-Cú pháp và object as type thậm chí còn khó hiểu và không nhất quán hơn.
  • Có gì xấu về with? Bạn có thể tạo các cấu trúc cây lồng nhau theo cách rất trực quan, điều không thể có trong C #.
  • Xử lý sự kiện trong VB thanh lịch hơn nhiều so với trong C #. Bạn có thể giới thiệu và xử lý các sự kiện bằng một từ khóa duy nhất (WithEvents) mà không phải khởi tạo đại biểu, eventhandler-procs, v.v. . Điều này làm cho lập trình GUI trong VB dễ phân tách hơn nhiều và bạn không cần phải tạo mã sự kiện bởi nhà thiết kế .
  • Các tham số tùy chọn được đưa vào C # mới - Do đó chúng có vẻ tốt.
  • VB.NET có cả hai các toán tử nghiêm ngặt và phím tắt-boolean.
  • Bạn do kiểm tra lỗi cú pháp tại thời điểm biên dịch trừ khi bạn chạy VB như ngôn ngữ kịch bản.
  • End If hữu ích hơn chỉ }. Khi có cấu trúc cú pháp phức tạp, tất cả các dấu ngoặc nhọn chỉ gây nhầm lẫn trong khi cụ thể End ... hỗ trợ bạn xác định khối nào chưa bị đóng.
  • XML Literals - Tập lệnh XML hiện là một phần của mã, được hỗ trợ đầy đủ bởi intellisense.

Nói chung, chỉ có một vài khác biệt khách quan giữa VB.NET và C # ngoài cú pháp. EG: Thiết kế GUI hiệu quả hơn nhiều trong VB do hệ thống sự kiện tốt hơn và IDE tốt hơn trong khi các thuật toán có thể được thể hiện tốt hơn trong C # vì cú pháp là conciser.

Phần còn lại chỉ là một câu hỏi về phong cách cá nhân của bạn. Lập trình viên C-Style cảm thấy thoải mái với C #, VB (hoặc có thể là Pascal?) - Lập trình viên phong cách sử dụng VB.

Nhưng VB-Syntax dựa trên Word, rõ ràng hơn có thể dễ đọc hơn cho người mới bắt đầu so với tất cả các ký hiệu trong C. So sánh:

If (a < 15) Xor (b = 2) And Not Condition Then

đến

if ((a < 15) ^ (b == 2) && !Condition())

Điều này không có nghĩa là một ngôn ngữ tốt hơn ngôn ngữ khác.

Biên tập : -----------------------------------------

Đối số VB sẽ dễ bị lỗi. Khi bạn sử dụng Option Strict On nó nghiêm ngặt như C # nhưng không cho phép chúng tôi mắc lỗi như vậy:

// VB would initialize with zero (C/C++ doesn't)
int countZeros;
// No confusion with loop bounds with For x = 1 To Length
for (int i = 1; i <= length; i++) {
    // Never confusing == with = 
    if (data[i] = 0) 
        countZeros++;
}
13
Dario

Về mặt lịch sử, môi trường phát triển VB là cách nhanh chóng và hiệu quả để xây dựng một số loại ứng dụng nhất định (ví dụ: ứng dụng GUI). Điều đó dẫn đến nó là một lựa chọn rất phổ biến. Tôi nghĩ VB là ngôn ngữ được sử dụng nhiều nhất trong thời hoàng kim (ví dụ VB6).

Với loại cơ sở được cài đặt đó, hầu như không ngạc nhiên khi vẫn còn rất nhiều công việc đang diễn ra trong đó.

12
dommer

Tất cả bắt đầu trước khi C # tồn tại

Trở lại năm 1999, chúng tôi đã có Visual Studio 5/6. Nếu bạn là Nhà cung cấp phần mềm độc lập hoặc công ty sử dụng Windows và cần một ứng dụng được viết có thể, ví dụ: Theo dõi thời gian của nhân viên dành cho các dự án, bạn có một vài lựa chọn:

  1. Các hình thức trong Visual Basic.
  2. MFC, ATL hoặc Win32 trong Visual C++.
  3. Các hình thức trong Truy cập 97/2000.
  4. Trang web ASP.
  5. Táo Java.

Vào thời điểm đó, chúng tôi đã ở ngay trước khi bong bóng Dot-Com nổ tung, vì vậy bất kỳ ai có thiện cảm với (4) hoặc (5) đều phải đàm phán về các lựa chọn cổ phiếu ở bất cứ điều gì tuyệt vời mà họ bị thu hút.

(3) có vấn đề với khóa và khả năng mở rộng tổng thể, nhưng tôi đã thấy rất nhiều giải pháp điều khiển truy cập sẽ Shell-out để chạy các chức năng hỗ trợ khi cần.

Vì vậy, điều đó khiến chúng ta có VB và VC++:

Trình chỉnh sửa biểu mẫu trong VB, vào thời điểm đó, rất tuyệt vời cho năng suất. Bạn có thể kéo thả các thành phần của mình - không chỉ các nút, nhãn và hộp văn bản mà cả hộp công cụ 'OLE controls' có thể tái sử dụng các thành phần như lưới thông minh, trang tính Excel hoặc IE. Việc kết nối được thực hiện phía sau hậu trường - mọi thứ đều giống như đối tượng và bạn chỉ cần nhấp đúp vào mọi thứ để thêm trình xử lý sự kiện. Điều này rất Lúc đó, tôi là thành viên của nhóm hỗ trợ nhà phát triển Visual Studio, tôi có thể nhớ cách các cuộc gọi hỗ trợ của Visual Basic chủ yếu là về thành phần nào là tốt nhất để sử dụng hoặc cách tối ưu hóa ứng dụng của họ theo những cách nhất định. không bao giờ 'làm cách nào để tạo một ứng dụng có các tính năng giao diện người dùng X, Y và Z'.

Xây dựng một giao diện người dùng phong phú trong Visual C++ là một thách thức khác. Mặc dù đã có hỗ trợ trình soạn thảo Visual cho các hộp thoại và biểu mẫu SDI/MDI, nhưng nó khá hạn chế. Sự hỗ trợ để nhúng OLE Điều khiển (ActiveX) vào MFC hoặc Win32 là một nghệ thuật đen, mặc dù ATL dễ dàng hơn một chút. một mình Điểm kết nối cần thiết cho các sự kiện tùy chỉnh trong các thành phần.

Đúng, VC++ có tốc độ thực thi, khả năng gỡ lỗi và các tùy chọn khung/thư viện/giao diện người dùng linh hoạt, nhưng hỗ trợ IDE không thể bao quát tất cả các hoạt động phổ biến nhất với những thứ như Wizards , phân cấp lớp MFC toàn diện và các dòng hỗ trợ sự cố 90 ngày/2 lần miễn phí.

IIRC, trình đóng gói ứng dụng được cung cấp với VB có thể đóng gói ứng dụng của bạn, VB thời gian chạy và các điều khiển phổ biến mới nhất DLL và cung cấp cho bạn trình cài đặt EXE độc lập mà bạn có thể đưa vào đĩa CD và đến với khách hàng. Không ai trong số này 'mà bạn đã cài đặt msvcrtXX.dll và mfcxx.dll?', điều này đã gây khó khăn cho các nhà phát triển MFC.

Vì vậy, vì lý do giao diện người dùng theo thời gian và thị trường phong phú, VB có lượng người theo dõi rất lớn.

Khi Visual J ++ và Visual Interdev tấn công vào VS6, rõ ràng Visual Basic IDE đã chiến thắng một số trận chiến với Visual C++, một IMHO công bằng. Studio .NET có trình chỉnh sửa biểu mẫu giống VB cho ngôn ngữ C # mới [~ # ~] cool [~ # ~] .

Ngôn ngữ giống Java/C/C++ mới được kết hợp với trình thiết kế giao diện người dùng được yêu thích bởi VB mọi người trong thời gian này đã đưa ra một đường di chuyển mới cho những người C++ hiện đang thực hiện với MFC/ATL/Win32. Đối với VB 3/4/5/6 những người không thích thiếu khả năng tương thích ngược 100% trong VB.net, điều này mang đến cơ hội học một ngôn ngữ mới bằng một ngôn ngữ mới môi trường quen thuộc.


Những lý do mà VB là một sản phẩm toàn diện như vậy có thể có liên quan đến nguồn gốc của Microsoft, với Basic là sản phẩm dành cho nhà phát triển hàng đầu của họ, nhưng tôi không ' t có bất kỳ trích dẫn nào tại thời điểm này.

7
JBRWilkinson

Tuy nhiên, bất kỳ ngôn ngữ nhất định nào cũng có thể là lý do để gắn bó với ngôn ngữ này: nó rất tốn kém để loại bỏ một cơ sở mã khổng lồ và thực tế là các nhà phát triển đã biết ngôn ngữ này, khiến nó sử dụng rẻ hơn các ngôn ngữ khác.

6
Brian Rasmussen

VB.NET dễ học hơn, bạn nói đúng và về tổng thể thì dễ hơn C #. Đó là điểm đầu tiên tại sao VB lại phổ biến đến vậy. Một điểm khác, và điểm lớn nhất, tôi nghĩ, là có một số lượng lớn các nhà phát triển đã làm việc với VB 6 và các phiên bản cũ hơn của ngôn ngữ này và họ dễ dàng phát triển ứng dụng với VB.net hơn để học một ngôn ngữ mới.

6
iburlakov

Như những người khác đã nói, phán đoán thẩm mỹ của bạn đối với cú pháp ngôn ngữ phụ thuộc rất nhiều vào những gì bạn biết trước đây. Trong hơn một thập kỷ, có vẻ như đây là một cuộc thi giống nhau về C, với các dấu ngoặc nhọn cho "khối", "->" cho việc xác định (Perl, php), dấu ngoặc đơn cho các đối số gọi hàm, // cho bình luận, và một dấu chấm phẩy ở mỗi đầu dòng. Một số người thậm chí đã nghĩ rằng nhờ vào 'penée unique' này, nếu bạn biết một ngôn ngữ, bạn biết tất cả, điều này thực sự vô lý. Nhưng điều này thấm nhuần ý tưởng giữa những người C++/Java đó là thẩm mỹ cú pháp đúng duy nhất và bất cứ điều gì khác đang cố gắng sao chép COBOL.

Vài năm trước tôi đã chuyển sang Ruby, và bây giờ là trăn, và tôi không thể chịu đựng thêm bất kỳ dấu chấm phẩy xấu xí nào, dấu ngoặc nhọn và các ký tự vô nghĩa rác rưởi khác. Mã nguồn có nghĩa là được đọc bởi con người. Khi tôi thử dùng studio trực quan, tôi đã chọn VB so với C #. Tôi nghi ngờ một số lập trình viên chọn C # chỉ để "trông nghiêm túc" với cú pháp giống Java của nó, nhưng thôi, rất những tính năng tương tự cũng có ... cho mắt bạn nghỉ ngơi.

6
vincent

Chà, nếu bạn đang nói về .NET, tôi có thể nghĩ ra một điều thực sự dễ dàng:

Trình soạn thảo của VB.NET trong Visual Studio tốt hơn nhiều trong việc bắt lỗi cú pháp so với C #.

Mặc dù trình chỉnh sửa của C # đã có một sự cải tiến lớn trong VS2008 SP1, nhưng vẫn có một số lỗi cú pháp mà trình soạn thảo không phát hiện ra cho đến khi bạn cố gắng biên dịch chương trình.

4
Powerlord

Phần lớn VB mức độ phổ biến bắt nguồn từ thời mà công cụ của VB thân thiện hơn nhiều so với các ngôn ngữ có sẵn khác. "Cổ điển" VB cung cấp một cách dễ dàng để xây dựng Windows các ứng dụng không cần phải học các API của Win32 hoặc bận tâm đến việc quản lý bộ nhớ thủ công. Rào cản cho các lập trình viên mới bắt đầu thấp hơn nhiều với VB so với C++, vì vậy rất nhiều người cắt răng với VB.

Ngày nay, tôi nghĩ VB một lợi thế so với C # là sự quen thuộc đối với những người đã làm việc với VB trong những năm qua. Một lợi thế khác là VB dễ đọc vì xu hướng sử dụng từ khóa thay vì ký hiệu dấu chấm câu. Là người làm việc trong VB, Java, C, C # và Python, tôi thấy rằng VB = là ngôn ngữ dễ dàng nhất để quay lại khi xem lại mã mà tôi đã viết cách đây nhiều năm. Cú pháp dài dòng hơn, thường giúp đọc mã dễ dàng hơn và Visual Studio luôn hoàn thành tốt công việc định dạng VB để dọn dẹp định dạng khi bạn nhập để mã được định dạng nhất quán (bất kể sự cẩu thả của tác giả).

Là một lưu ý phụ, tôi thấy Python cực kỳ dễ đọc và xem xét vì những lý do tương tự. Trong Python, định dạng mã được thực thi bởi trình thông dịch thay vì IDE, nhưng kết quả cuối cùng là như nhau. Python cũng ưu tiên các từ khóa để chấm câu, mặc dù có thể ít hơn so với VB.

4
gbc

Đến tên một vài:

  • dễ sử dụng
  • tên quen thuộc (cơ bản là một trong những ngôn ngữ lập trình máy tính phổ biến đầu tiên)
  • đừng đánh giá thấp Microsoft marketing
3
Toon Krijthe

Thật khó để tranh luận rằng đó là bất kỳ "dễ bị lỗi" hơn hoặc ít hơn bất kỳ ngôn ngữ nào khác. Tôi cũng nghi ngờ điểm "đại đa số web MS thương mại"; từ những gì tôi đã thấy, C # là người đi đầu trong việc phát triển .NET (với .NET là công cụ hàng đầu trong ngăn xếp MS cho những thứ không phải trình điều khiển thiết bị, v.v.).

3
Marc Gravell

VB rất dài dòng và dễ dàng làm quen so với C # là trường hợp nhạy cảm. Đối với một lập trình viên mới làm quen, điểm khởi đầu tốt nhất của nó.

3
chugh97

Một lợi thế VB.NET có trên C # (sẽ biến mất với C # 4), là các tham số mặc định và được đặt tên, một điều rất hay khi sử dụng VSTO.

3
Blake Pettersson

VB/VB.NET thuộc danh mục RAD (Phát triển ứng dụng nhanh). Bạn có thể phát triển các ứng dụng chỉ bằng các điều khiển kéo thả từ hộp công cụ và ít mã hơn.

3
NinethSense

Chà, tôi nghĩ bạn phải phân biệt giữa classic VB và VB.NET.

Tôi cảm thấy VB.NET là không rất phổ biến, nhưng Visual Basic "Classic" vẫn là1 Lý do là nó rất dễ tạo ứng dụng Windows. So sánh điều này với một ứng dụng Windows trong C++/Mfc, gần như là sự thay thế duy nhất tại thời điểm này.

Vì lý do tương tự, Delphi đã rất nổi tiếng một thời.

3
PhpFlashGuy

Tôi nghĩ một phần lý do là vì các lập trình viên asp cũ đi vào .NET như tôi đã làm rất quen thuộc với VB đã vì VB script là ngôn ngữ = ASP cổ điển được sử dụng cho hầu hết các phần. Tôi cảm thấy ít tốn thời gian hơn khi viết bằng VB trong .NET vì tôi đã biết cách nói VB. VB cũng ít khóc hơn C #. Tôi có thể đọc/ghi cả hai nhưng tôi thích VB vì dễ kết bạn nếu bạn là lập trình viên mới.

3
Eric

Tôi làm việc trong một môi trường nơi chúng tôi sử dụng cả hai. Chúng tôi đã chuyển sang C # theo hướng cổ điển ASP và VB. Theo tôi, không có sự phá vỡ thỏa thuận giữa các ngôn ngữ. Đối với hầu hết các dự án, bạn có thể thực hiện cùng một công việc với cả hai ngôn ngữ. chia sẻ quan điểm của bạn về xu hướng lỗi và tôi cũng thấy VB bị lộn xộn (không có lý do).

Như những người khác đã đề cập, VB rất đơn giản và trong lịch sử bạn có thể xây dựng các dự án rất nhanh. Điều này tồn tại trong phát triển web (được phát triển nhanh), nhưng tôi nghĩ khi mọi người nhận ra rằng C # chỉ là khi phát triển nhanh, VB sẽ mờ dần. Một lý do khác tôi nghĩ nó sẽ mờ dần là mọi thứ khác mà bạn viết mã (CSS, JavaScript) khi tạo các ứng dụng web trông giống C # hơn VB, vì vậy nó có ý nghĩa để sử dụng C #, ngay cả đối với người mới bắt đầu.

2
miccet

Cá nhân tôi thích cách các sự kiện được đính kèm trong vb.net với từ khóa 'xử lý' ... IDE/Visual Studio/cũng phản ứng nhanh hơn khi giao dịch với VB và tự động xử lý hầu hết các end-if và tương tự ... C # tất nhiên là hợp lý và gọn gàng hơn nhiều (IMHO, tôi đã làm việc với cả hai khá nhiều)

2
Petar Kabashki

Đối với khung 4.0, chỉ có một số ít thứ VB thiếu so với C #, và điều ngược lại cũng đúng.

  1. Đáng chú ý nhất là VB.NET không có từ khóa Yield, nhưng nó sẽ sớm xuất hiện trên VB.NET với khung async mới.
  2. Không có từ khóa unsafe. Tôi chưa bao giờ thấy cần thiết, nhưng chắc chắn có một số người có.
  3. Không có chuỗi nhiều dòng. Chuỗi nhiều dòng được thực hiện bằng cách sử dụng các toán tử + (hoặc di sản &) trên các dòng. Hoặc, chúng có thể được thực hiện bằng cách sử dụng cú pháp bằng chữ XML: Dim s = <s>My string... multiple lines...</s>.Value. Nó không đẹp, nhưng nếu bạn không kén chọn và thực sự muốn các chuỗi nhiều dòng thì nó hoạt động. Và, bạn có thể thực hiện phép nội suy chuỗi với nó bằng cú pháp <%= myVar %>, Điều này thật tuyệt.
  4. Không có biến có phạm vi tương đương với dynamic. Các biến động đã xuất hiện trong VB trong một thời gian dài với Option Compare Off, Nhưng đó là phạm vi tệp, vì vậy nó không tốt bằng dynamicbecse dynamic giới hạn phạm vi chỉ có biến được khai báo theo cách đó.
  5. VB thiếu một cú pháp lambda ngắn gọn. Lambdas ở đó, nhưng bạn phải sử dụng Function(x) hoặc Sub(x).

Một số tính năng VB.NET có C # không:

  1. Chữ XML, tiện dụng cho tất cả các loại, không chỉ XML.
  2. Không phân biệt chữ hoa chữ thường trong ngôn ngữ là tiếng kêu của mèo. Không có nhiều ngôn ngữ khác cho phép, nhưng điều khác biệt là tốc độ mã hóa không bao giờ phải nhấn phím shift khi bạn nhập và mã của bạn chỉ tự động định dạng theo cách bạn muốn.
  3. Mệnh đề Select thường không cần thiết có thể được bỏ qua khỏi các truy vấn Linq.
  4. Từ khóa Nothing hữu ích hơn nhiều so với null trong đó mọi thứ (loại giá trị chẵn) có thể được đặt thành Nothing và bạn có được mặc định. Không cần từ khóa default.
  5. VB.NET được biên dịch liên tục trong Visual Studio để bạn thấy lỗi ngay lập tức. Không nhấn CTRL-SHIFT-B cả ngày như trong C #.

Cửa hàng của tôi thực hiện MVC3 với Dao cạo bằng VB.NET và một khi bạn vượt qua định kiến ​​(chủ yếu là không có cơ sở), đó thực sự là một ngôn ngữ rất hay để sử dụng. Nó không thực sự dài dòng hơn C # như nhiều yêu cầu (ngoại trừ trường hợp lambdas) và đó là tính năng tương tự nhiều tính năng song song với C #. Tôi đã thấy rằng hầu hết những người ghét đều không thực sự được mã hóa trong VB.NET hiện đại trong bất kỳ khoảng thời gian nào.

2
mattmc3