Cuộc tranh luận giữa VB.Net và C # [đã đóng]

Tôi đã từng ở nơi làm việc, khi bắt đầu một dự án, câu hỏi "Chúng ta nên sử dụng VB.Net hay C #".

Cấp, có lẽ ít phổ biến hơn khi phải đưa ra quyết định ngay bây giờ so với thời kỳ đầu của .Net, đặc biệt đưa ra xu hướng hội tụ ngôn ngữ, nhưng nó vẫn có thể là một cuộc tranh luận sôi nổi.

Vậy, giữa VB.Net và C #, bạn thích ngôn ngữ nào và tại sao?

Tôi thích C # hơn VB.NET vì

• tìm kiếm lập trình viên / công việc dễ dàng hơn:

• tìm kiếm sự giúp đỡ dễ dàng hơn:

^{(từ stackoverflow)}

Tôi ghét VB.NET. Những ngày tôi vẫn dùng nó là những ngày tôi hối hận. Điều đó nói rằng, thị hiếu của tôi là một phần trong tình huống và kinh nghiệm của tôi, và không nhất thiết phải có bất kỳ liên quan nào đến những gì bạn đang làm ...

Tôi nghĩ điều quan trọng là khi so sánh các ngôn ngữ phát triển liên tục như C # và VB.NET, để nhìn lại lịch sử của họ và xem họ đã đến trạng thái hiện tại như thế nào:

Những ưu điểm ban đầu của BASIC trên máy vi tính bao gồm kích thước và tính đơn giản (cú pháp nhỏ, dễ phân tích được thực hiện cho các trình thông dịch nhỏ, nhanh và hợp lý trong bộ nhớ cho chương trình và dữ liệu thực tế), một môi trường tương tác cho phép thử nghiệm và cú pháp đó là những biểu tượng và cấu trúc ngắn gọn cho một cú pháp giống như tiếng Anh rõ ràng. Tuy nhiên, nó không phù hợp với các chương trình lớn, có cấu trúc và có xu hướng khuyến khích mã spaghetti. Tuy nhiên, tính sẵn có và đơn giản của nó làm cho nó trở thành một lựa chọn tuyệt vời để giới thiệu về lập trình.

QuickBasic đã cập nhật cú pháp để cho phép các chương trình lớn có cấu trúc hơn và thêm phần biên dịch để thực thi nhanh hơn.

VisualBasic cung cấp trình xây dựng biểu mẫu mạnh mẽ, dễ sử dụng để cho phép xây dựng nhanh các ứng dụng GUI, đồng thời áp dụng cú pháp QB để sử dụng trong việc tạo kịch bản cho các UI này. Nó hoạt động tốt nhất khi được sử dụng để tạo UI cho logic cấp thấp được cung cấp dưới dạng các thành phần dựng sẵn (thường được viết bằng một số ngôn ngữ khác). Theo thời gian, cú pháp ngày càng lớn và không nhất quán khi các tính năng mới được giải quyết. Việc tập trung vào việc tạo UI trước tiên và sau đó điền vào các đoạn script hoạt động tốt cho các ứng dụng nhỏ, tập trung vào UI, nhưng có xu hướng khuyến khích lập trình sao chép và thay đổi mã spaghetti trong khi không khuyến khích sử dụng lại, cấu trúc dữ liệu phức tạp và tách mối quan tâm. Trong suy nghĩ của nhiều người, "mã VB" trở thành đồng nghĩa với "quả bóng lớn"; "Lập trình viên VB" với "hack thiếu kinh nghiệm".

VB.NET là một ngôn ngữ giống như VB trên nền tảng .NET, một nỗ lực (không hoàn toàn thành công) để dọn dẹp và hiện đại hóa cú pháp VB phát triển quá mức. Nó không hoàn toàn tương thích với mã VB hiện tại và không nỗ lực cung cấp khả năng tương thích với các hình thức VB (được cho là phần quan trọng nhất của VB). Điều này khiến nhiều chủ sở hữu sản phẩm VB có sự lựa chọn khó chịu khi viết lại các ứng dụng của họ một cách hiệu quả trong VB.NET (xử lý sự không tương thích tinh tế trong mọi thói quen không được kiểm tra cẩn thận) hoặc thực sự viết lại các ứng dụng của họ trong C # (xử lý một người lạ cú pháp ngoàithư viện thời gian chạy mới và thiết kế biểu mẫu). Hầu hết người dùng VB.NET là người dùng VB đã mắc kẹt với cú pháp này, nhiều người sử dụng nó như một cái nạng trong khi học C #. Kết quả là, nó ngay lập tức mang tiếng là thiên đường cho các lập trình viên bị mắc kẹt trong cách của họ, không muốn hoặc không thể mở rộng hoặc cải thiện kỹ năng của họ.

Tại thời điểm này, VB.NET tiếp tục phát triển, từ từ bỏ hành lý trong khi chọn cú pháp mới và thú vị (LINQ, XML bằng chữ). Tuy nhiên, nó vẫn giữ được hầu như không có ưu điểm ban đầu nào của BASIC: đó là một ngôn ngữ lớn, phức tạp với đường cong học tập khá dốc và cơ hội hạn chế cho thử nghiệm tương tác.

• Đối với các lập trình viên cũ đã gắn bó với nó hơn 30 năm qua, đó không phải là một lựa chọn tồi, miễn là họ không giới hạn bản thân mình.
• Đối với các lập trình viên mới, sự giống nhau ngày càng mơ hồ, các chương trình VB để tiếng Anh là hầu như không đáng để gật đầu kỳ lạ để tương thích ngược và sự kỳ thị xã hội.
• Ví mới dự án , VB.NET là một sự lựa chọn kỳ lạ trừ khi dự án được rất nhiều liên quan với một trong số ít các nhiệm vụ ngôn ngữ được tối ưu hóa cho: hội nhập với các thành phần COM kém gõ (Văn phòng ...) (mặc dù C # 4.0 làm giảm lợi thế này đáng kể ) hoặc tạo XML nội tuyến.

Tôi quen thuộc với cả hai, nhưng đã làm rất nhiều công việc lập trình ban đầu của tôi trong VB4, VB5 và VB6. Bây giờ cả hai ngôn ngữ trong .NET đã trải qua một vài lần lặp lại và hội tụ khá nhiều khả năng của chúng, tôi nghĩ rằng cuộc tranh luận là hết sức ngớ ngẩn, gần giống với "màu sắc yêu thích của bạn."

Cá nhân, tôi thích cả hai vì những lý do khác nhau.

VB.NET
Rất nhiều người nói về cách cú pháp C # trực quan hơn, nhưng điều đó rất chủ quan và dựa nhiều vào những gì bạn bắt đầu biết. Tôi sẽ lập luận rằng nếu bạn hoàn toàn khách quan thì cú pháp VB.NET có thể trực quan hơn nếu bạn không thừa nhận kiến ​​thức trước đó bằng ngôn ngữ khác. Ví dụ, được đưa ra cùng một chương trình trong C # và VB.NET mà bạn nghĩ sẽ giải mã được nhiều hơn cho người không có kiến ​​thức về lập trình. Có vẻ khá rõ ràng với tôi.

Một điều khác cũng hay về cú pháp này, đó là rõ ràng hơn nhiều về các cấu trúc đóng (END IF, END WHILE, NEXT X) so với mô hình ngoặc. Nó làm cho mã dễ đọc hơn một chút và thường cho phép trình biên dịch chính xác hơn về số dòng chính xác gây ra lỗi biên dịch. Nếu bạn đã từng bị thiếu dấu ngoặc / săn dấu hai chấm vì lỗi trình biên dịch cách dòng vấn đề 50 dòng thì bạn hiểu ý tôi là gì.

Ngoài ra, trong cột win VB.NET theo ý kiến ​​của tôi là thiếu == / = như các toán tử so sánh / gán. Những lợi ích hiếm có của việc có một toán tử riêng biệt cho mỗi loại sẽ không bao giờ bù đắp tất cả (đôi khi) khó khám phá ra các bộ phận mà nó giúp tạo ra.

Cuối cùng, tôi ghét sự nhạy cảm trong trường hợp lập trình ngôn ngữ. Một trong những khiếu nại về VB là nó có quá nhiều hành lý, nhưng C # chuyển chim hải âu của nhạy trường hợp C. Tôi chưa bao giờ ở trong một tình huống mà tôi muốn hai định danh trong cùng một phạm vi chỉ khác nhau theo từng trường hợp. Nó chỉ làm cho công việc bận rộn và làm chậm tôi xuống. VB.NET được một số điểm trên C # trong vấn đề này đối với tôi.

Các lập trình viên C # thích ngắn gọn, đó là lý do tại sao tôi nghĩ họ thường thích cú pháp này. Nó chỉ có tính thẩm mỹ nhất định. Tuy nhiên, từ góc độ hoàn toàn thực tế, tôi thích nó vì nó rất giống với các ngôn ngữ như Java, JavaScript và C ++.

Kể từ khi tôi làm được rất nhiều phát triển web mà đòi hỏi cả hai lập trình server và client side, tôi tìm thấy nó dễ dàng hơn để tinh thần chuyển đổi giữa C # và JavaScript như tôi thường xuyên phải làm.

Ngoài ra tôi như một thực tế rằng, đối với hầu hết các phần, rằng nếu tôi đã phải chuyển sang làm Java hay ++ lập trình C, tôi sẽ có một chút của một khởi đầu nếu tôi đang sử dụng C # hầu hết thời gian.

Tôi thích cú pháp ngoặc của các ngôn ngữ kiểu C hơn cú pháp "dài dòng" hơn của các ngôn ngữ kiểu BASIC.

giới thiệu tôi đến lập trình là với Turbo Pascal. (Các bit của BASIC lập trình tôi đã làm trên Commodore 64, như một đứa trẻ, không thực sự đếm.) Sau khi học Java Tôi chưa bao giờ nhìn lại và có cú pháp C-phong cách ưa thích.

Chúng có chức năng giống nhau, không có gì bạn có thể làm ở cái khác mà bạn không thể làm ở cái kia và trong tương lai Microsoft đã cam kết rằng các nhóm ngôn ngữ sẽ phát triển đồng đều nên điều này không thể thay đổi.

Sự khác biệt bây giờ hoàn toàn là văn hóa và cá nhân. Bài viết này rất thú vị khi đọc về sự khác biệt giữa các nền văn hóa của các lập trình viên sử dụng C # và VB.net

_{[Lưu ý: Mặc dù bản thân tôi là người phát triển C #, kết luận của bài viết được liên kết không nhất thiết phản ánh ý kiến ​​cá nhân của tôi, đó chỉ là một cách tiếp cận thay thế thú vị trong cuộc tranh luận]}

Tôi đã đến .NET từ C và C ++ (với một chút Java, Ada và Pascal được đưa vào) vì vậy C # là sự tiến triển tự nhiên đối với tôi.

Nếu một công việc xuất hiện theo yêu cầu VB.NET, tôi chắc chắn sẽ không từ chối.

Tôi đã thực hiện rất nhiều công việc với VB.NET, nhưng tôi hiểu đủ C # để có được ý chính về những gì đang xảy ra trong mã. Sở thích hiện tại của tôi là VB.NET vì tôi quen thuộc với nó (rõ ràng), nhưng tôi thực sự không có sở thích nào giữa cú pháp BASIC dài dòng và cú pháp kiểu C, cả hai đều rất dễ đọc và dễ hiểu đối với tôi.

Hầu hết nền tảng lập trình đồng nghiệp của tôi là COBOL và VB6, vì vậy VB.NET là lựa chọn ngôn ngữ .NET thoải mái hơn cho chúng tôi với tư cách là một nhóm. Không có lý do vững chắc nào cho chúng tôi khiến việc học C # trở thành một yêu cầu vì chúng giống nhau về mặt chức năng.

Điều đó nói rằng, học C # chắc chắn là trong danh sách những việc cần làm của tôi.

Tôi thích C #.

Tôi đã bắt đầu với tư cách là lập trình viên VB.NET nhưng với thời gian trôi qua, rõ ràng có khá nhiều tính năng mới sẽ xuất hiện đầu tiên trên C # và sau đó là VB.NET (ví dụ: thuộc tính tự động). Và cộng đồng xung quanh C # sống động hơn nhiều so với VB.NET.

Ngoài ra, nếu bạn có ý định học Java hoặc ngôn ngữ tương tự, C # là điểm khởi đầu tốt hơn - cú pháp gần như giống nhau trong tất cả các ngôn ngữ có nguồn gốc C. Mặc dù điều này sẽ không phải là điểm bùng phát đối với tôi vì cú pháp là thứ bạn có thể học nhanh chóng bằng mọi cách.

Ngoài các câu trả lời khác được đăng ở đây, tôi sẽ chọn C # trên VB vì các lập trình viên C # được trả nhiều tiền hơn. Thêm kinh nghiệm với C # = thêm $$ :)

Tôi biết cả hai ngôn ngữ gần như giống nhau và thực sự dễ dàng để chuyển đổi giữa hai ngôn ngữ, nhưng tôi nghĩ khi quản lý nhìn vào một loạt các dấu ngoặc nhọn và dấu hai chấm, họ chấp nhận thực tế chúng ta đang làm một việc gì đó mà họ không thể làm được, với VB. Họ có thể nhìn vào đó và nói "ồ, điều đó không khó lắm nếu tôi có thể hiểu được".

C # vì tôi có thể chuyển đổi giữa nó và Java với nỗ lực tối thiểu

VB.NET là cú pháp hoàn toàn khác nhau. C #, tương tự như Java và các ngôn ngữ khác cho tôi một vị trí tốt hơn để nhanh chóng thích nghi với những điều mới. Vì đầu ra của C # và VB.NET hầu như có thể hoán đổi cho nhau, nên có ý nghĩa với C #. Ngoài ra, nếu mã của công ty bạn bằng C #, nhiều khả năng bạn có thể đào tạo một nhà phát triển Java cách mã hóa C # so với VB của nhà phát triển Java. Chỉ có những lợi thế tinh tế, nhưng tinh tế vẫn là một lợi thế.

Đặt sở thích cá nhân của tôi sang một bên. Là một người đang tuyển dụng (và đang cố gắng tuyển dụng) gần đây, khi chúng tôi có cuộc tranh luận này trong văn phòng, sự đồng thuận chung là chúng tôi nên tìm cách chuyển sang C # từ VB.

Tại sao? Bởi vì C # phổ biến hơn trên thị trường (dù sao xung quanh chúng ta), cho phép chúng tôi tuyển dụng dễ dàng hơn và được tuyển dụng dễ dàng hơn.

Có vẻ như nó đã đi vòng tròn đầy đủ; mọi người học C # vì nhà tuyển dụng muốn nó, vì có nhiều ứng viên hơn.

Là một nhà phát triển hơi lớn tuổi (già hơn 59 "?", Tôi đã học BASIC đầu tiên trên một chiếc Commodore VIC-20, tự học Turbo Pascal (v1!), Tiếp tục học COBOL ở trường đại học và dành 14 năm để phát triển trên IBM máy tính lớn, với các chuyển hướng ngắn gọn viết một ứng dụng có kích thước trung bình trong Khải huyền BASIC (một biến thể của PICK BASIC) và một vài tiện ích trong Modula-2, trước khi chuyển sang VB5 và VB6. Và sau đó đến .NET.

Vì nền tảng cơ bản của tôi, tôi nghĩ rằng tôi nên bắt đầu với VB.NET, chỉ để thấy rằng tôi đã cố gắng làm mọi thứ theo cách "cũ" và nó đang khiến tôi phát điên (không sao, nhiều hạt hơn ). Là tôi đã thực hiện một số công việc trong C, tôi nghĩ rằng tôi sẽ tạo cho C # một vòng xoáy để xem điều đó diễn ra như thế nào. Và OMG, giống như nổi lên từ một đường hầm tối tăm thành ánh sáng ban ngày rõ ràng! Hoàn toàn bất ngờ. Và tôi đã từng tạo ra những tiếng ồn chê bai về việc C là một ngôn ngữ "chỉ viết" - "thật khó hiểu khi một lập trình viên C không thể hiểu được mã của chính anh ta đã làm gì 6 tháng sau khi anh ta viết nó", một quan sát được thực hiện bởi tiểu thuyết bán nổi tiếng mà tôi nghĩ lúc đó nghe có vẻ dễ thương.

Vì vậy, do hơi lạ lẫm với C, C # dễ dàng hơn đối với tôi khi học lập trình .NET so với mô hình cơ bản quen thuộc hơn nhiều. Tôi vẫn thích VB6, nhưng đã yêu C #. Ngôn ngữ lập trình tốt nhất trên hành tinh.

Tôi phát triển trong Visual Basic .Net từ năm 2001 và tôi yêu nó và tôi ghét nó !!!

Thứ tự trình bày những điểm này chỉ dựa trên thứ tự mà anh ấy nghĩ đến ...

Trong vb.net với visual studio, có một ngắt dòng trực quan giữa mỗi phương thức, thuộc tính. Đối với nhiều người, đó không phải là lý do chính đáng để thích vb.net hơn c # nhưng tôi không hiểu tại sao nhóm c # tại Microsoft không triển khai nó. Có một bổ trợ vẽ đường này trong c # nhưng một lần nữa Microsoft lại có nhóm ac # và nhóm cơ bản trực quan không nói chuyện với nhau.

Trong vb.net, khi bạn tạo một winform, bạn có hai combobox trong studio trực quan ở đầu trình chỉnh sửa và bạn có thể tự động tạo sự kiện khi chọn một sự kiện trên combobox bên phải. Khi bạn đính kèm hàng tá sự kiện mỗi ngày, sẽ rất khó để không có tính năng này. Với c #, bạn có một nút nhỏ ở đầu lưới thuộc tính có thể tạo sự kiện nhưng nó không nhanh như trong vb.net. Hơn nữa, nếu bạn đính kèm sự kiện kiểm soát trong c # và xóa điều khiển trên biểu mẫu, đại biểu được tạo trên mã được tạo tự động để xử lý sự kiện phải được xóa theo cách thủ công. Cảm ơn bạn một lần nữa Microsoft.

Trong vb.net, khi bạn cố gắng sửa đổi một phương thức có chứa truy vấn linq mà không sửa đổi chính truy vấn đó, không có vấn đề gì nhưng trong c #, tất cả mã phương thức đều bị khóa. Nếu bạn có nhiều truy vấn linq hoặc biểu thức lambda, tính năng chỉnh sửa và tiếp tục sẽ nhanh chóng trở thành một thứ tốt. Ok, một chút cường điệu ... nhưng :)

Trong vb.net, khi bạn tạo tên phương thức và nhấn enter, 'end sub' sẽ được tạo tự động. Trong c #, hãy tự làm. Ok, nếu bạn đã cài đặt lại hoặc hủy cài đặt, nó sẽ tốt hơn nhưng tại sao tất cả các tính năng nhỏ nhưng tuyệt vời này không được triển khai trong c #.

Trong vb.net, khi bạn có lỗi trên mã của mình, các lỗi sẽ tự động được hiển thị và khi bạn sửa nó, các lỗi này sẽ được xóa khỏi ngăn xếp trong thời gian thực. Trong c #, bạn phải xây dựng dự án của mình để nhận ra rằng bạn đã sửa thành công hoặc không sửa các lỗi được chỉ định. Tại sao nhóm c # không đặt tùy chọn để xác minh lỗi thời gian thực như trong vb.net. Với giải pháp lớn, không có xác minh lỗi thời gian thực có thể là một tối ưu hóa hiệu suất rất tốt nhưng tôi thích thấy một đống lỗi không xuất hiện trong khi tôi sửa nó.

Giống như những người khác đã đề cập, tôi nghĩ rằng điều kiện vb.net dễ đọc hơn nếu ... cho dù, chọn trường hợp ... kết thúc chọn nhưng với khung vẽ tranh, hãy quên những gì tôi đã nói.

Với vb.net, có rất nhiều lỗi trong studio hình ảnh. Chỉ cần đề cập đến một trong studio hình ảnh 2010, các intellisens không lọc liệt kê chính xác nếu bạn có chế độ "chung" được kích hoạt thay vì "tất cả".

Với vb.net, bạn được coi là một anh chàng ngốc bởi vì về mặt tĩnh, nhiều lập trình viên xấu hơn sử dụng vb.net thay vì c # vì c # khó học hơn và thúc đẩy thực hành lập trình tốt hơn.

Giống như những người khác đã nói, lập trình viên c # có cơ hội tốt hơn để có một công việc tốt với nhiều tiền hơn.

Trong đầu của khách hàng, vb.net = anh chàng lập trình trong tầng hầm của mình với một chuỗi spaghetti mã. c # = wow, bạn rất thông minh. Thực tế là không phải vì bạn lập trình trong c #, mà bạn tạo ra một chương trình tốt mà là tĩnh, đúng vậy.

Với tất cả những điểm này, tôi đã chọn chuyển đổi tất cả mã vb của mình trong c #. Tôi lập trình với tất cả các thực tiễn tốt nhất về hướng đối tượng, mẫu thiết kế, mã sạch với các tiêu chuẩn và cú pháp chặt chẽ và tôi có thể lập trình như vậy trong 50 năm nhưng từ con mắt của cộng đồng, tôi không phải là một lập trình viên giỏi. Tôi sẽ chuyển đổi mã của mình trong c # mà không có thực tiễn tốt nhất nào khác và tôi sẽ là một người khác; một anh chàng tuyệt vời mà bạn phải tôn trọng ..... :( thật là một trò đùa ... !!! nhưng đó là thực tế.

Đây là một cách để xem xét: Giữa SO và CodePlex, ngôn ngữ nào phổ biến hơn? C # hay VB.Net?

Đôi khi, theo đàn là một điều tốt bởi vì đó là đàn sẽ có thể giúp bạn khi bạn cần. Theo mặc định, C # sẽ nhanh hơn Vb.Net. Tôi tin rằng sử dụng Option Strict có thể cân bằng nó mặc dù. Lần cuối cùng tôi so sánh IL giữa hai loại, an toàn loại của VB.Net cuối cùng đã tăng thêm khoảng 15% cho IL. Điều này chuyển thành chi phí thêm. VÀ ... đưa ra các ngôn ngữ về cơ bản giống như vậy, tôi sẽ sử dụng ngôn ngữ nhanh hơn. Sự thuận tiện của tôi không nên ghi đè lên trải nghiệm người dùng của tôi nói chung.

Tôi muốn nói rằng lý do duy nhất BASIC vẫn còn phổ biến là nó là sản phẩm đầu tiên của Microsoft và họ đã đẩy nó xuống cổ họng của chúng tôi trong 35 năm qua. Đáng lẽ ra nó đã chết từ lâu rồi.

Như đã nói, tôi đã làm việc trên hai dự án .NET khá lớn và cả hai đều được thực hiện với VB.Net - mặc dù có một chút C # vì bản dịch là một con chó cái hoặc cấu trúc không tồn tại trong VB.Net. Ưu điểm duy nhất tôi thấy với VB.Net là trình soạn thảo Visual Studio thân thiện với nó hơn (theo kinh nghiệm của tôi) so với C # - Intellisense có vẻ tốt hơn và tự động định dạng (lưu ý rằng vì tôi chưa sử dụng C # nhiều như vậy, tôi có thể thiếu một cái gì đó trong cấu hình của IDE ...)

Một nhược điểm lớn trong VB.Net là họ đã mang rất nhiều cách tào lao thời kỳ VB6 trở lại trong .NET 1.x để dễ dàng chuyển đổi mã VB6. Công cụ đó vẫn còn ở đó và các lập trình viên VB6 đang mã hóa mã mới bằng cách sử dụng ... "phần mở rộng" đó thay vì sử dụng các lớp / phương thức .NET trung tính / bất cứ điều gì. Tôi không biết bao nhiêu lần tôi đã hỏi ông chủ của mình tại sao ông vẫn sử dụng thứ nhảm nhí đó. "Nhưng ... Nó hoạt động ..." Phải. Này, tôi thích chó cái.

Trong khi tìm kiếm trợ giúp trên web, tôi đã tìm thấy phần lớn các giải pháp là trong C # - hãy xem các diễn đàn MSDN, nhiều blog khác nhau, v.v ... Sách có xu hướng tập trung vào C # và nếu có phiên bản VB, thì đó là phiên bản VB. thường đến vào tháng sau (ví dụ: Pro LINQ .... từ Apress.)

Nhiều ngôn ngữ chia sẻ tổ tiên C, giúp chuyển đổi giữa C, C ++, C #, Java, PHP và một số ngôn ngữ khác dễ dàng hơn nhiều. PHP là một chút kéo dài ở đây, nhưng nó có rất nhiều cấu trúc giống như C. VB? Chà, đó là chuyện nhỏ của riêng nó và đó là điều đó.

Một nhà lãnh đạo dự án trong tổ chức của tôi gần đây đã nói với tôi rằng ngày càng có nhiều dự án mới được phát triển bằng C # thay vì VB - CUỐI CÙNG. Khi .NET được giới thiệu trong tổ chức của chúng tôi, họ ít nhiều đã chính thức đồng hành với VB.Net vì tất cả các mã VB6 đã diễn ra. Sức mạnh mà sau này được thừa nhận với tôi rằng đó không phải là động thái tốt nhất của họ.

Như một người khác ở trên đã chỉ ra, tôi sẽ không nói không với một dự án VB.Net, nhưng tôi vẫn hy vọng rằng nó sẽ dần bị xóa khỏi sự phát triển mới hơn tại nơi tôi làm việc.

Chà, ngày nay không có lý do thực sự nào để sử dụng VB.net. Ban đầu, nó chỉ là một cách để cung cấp cho các lập trình viên VB một cú pháp quen thuộc, nhưng về cơ bản là ánh xạ lại giống như CIC của CIC. Vì vậy, lợi thế thực sự duy nhất của nó là một cú pháp quen thuộc hơn và cú pháp BASIC của nó cũng là giới hạn duy nhất thực sự của nó.

Theo thời gian hai ngôn ngữ phát triển cùng nhau, sự khác biệt đáng kể duy nhất là my không gian tên giả.

Tôi sẽ khuyên mọi lập trình viên .net không quen thuộc với C # để tìm hiểu nó, vì cộng đồng khá lớn và cú pháp giống như C là phổ biến đối với hầu hết các ngôn ngữ được sử dụng nhiều hơn.

VB ngôn ngữ dễ đọc hơn đối với người mới, họ có xu hướng viết ứng dụng đầu tiên, thứ hai và thứ ba trong đó và tất cả chúng ta đều biết ứng dụng đầu tiên của chúng ta được mã hóa như thế nào - thật khủng khiếp.

Các lập trình viên từ C ++, Java và vv đã chuyển sang C # trong khi các nhà phát triển VB.NET đến từ nền tảng VBA, VB và BASIC, các lập trình viên phi truyền thống cần thiết.

Dường như có nhiều mẫu mã C # trực tuyến hơn các mẫu VB.NET. Không giống như tất cả những gì khó chuyển đổi cái này sang cái khác, nhưng tại sao phải bận tâm nếu bạn không phải làm vậy.

Tôi thích VB .Net hơn C #,

• (97) ...
• (98) vì tôi đã học VB trước khi tôi biết về C #.
• (99) vì tôi đã mua một cuốn sách 10.000 trang trên VB .Net.
• (100) vì VB không có niềng răng.
• (101) vì mọi người đều ghét VB.

C #. Chỉ vì tôi đã thực hiện C và Java, vì vậy tôi cảm thấy rằng C # dễ đọc hơn đối với tôi. C # là dành cho tôi, vì VB.NET dành cho các lập trình viên VB trước đây.