Phát triển C # có hiệu quả không thể tách rời với IDE bạn sử dụng không?

Tôi là một lập trình viên Python đang học C #, người đang cố gắng ngừng lo lắng và chỉ yêu C # vì nó là gì, thay vì liên tục so sánh nó với Python.

Tôi bị cuốn vào một điểm: thiếu chứng minh về nơi mọi thứ được xác định, như chi tiết trong câu hỏi Stack Overflow này . Nói tóm lại: trong C #, using fookhông cho bạn biết tên foonào đang được cung cấp, tương tự như from foo import *trong Python - một hình thức không được khuyến khích trong văn hóa mã hóa Python vì ẩn ý hơn là cách tiếp cận rõ ràng hơn from foo import bar.

Tôi khá ngạc nhiên với câu trả lời Stack Overflow cho đến thời điểm này từ các lập trình viên C #, đó là trong thực tế việc thiếu nhân chứng này không thực sự quan trọng bởi vì trong IDE của bạn (có lẽ là Visual Studio), bạn có thể chỉ cần di chuột qua một cái tên và được nói bởi hệ thống mà tên đến từ. Ví dụ:

Bây giờ, về lý thuyết tôi nhận ra điều này có nghĩa là khi bạn đang tìm kiếm một trình soạn thảo văn bản, bạn không thể biết các loại đến từ đâu trong C # ... nhưng trong thực tế, tôi không thấy đó là một vấn đề. Bạn có thường xuyên xem mã và không thể sử dụng Visual Studio không?

Đây là sự mặc khải đối với tôi. Nhiều lập trình viên Python thích cách tiếp cận trình soạn thảo văn bản để mã hóa, sử dụng một cái gì đó như Sublime Text 2 hoặc vim, trong đó tất cả là về mã, cộng với các công cụ dòng lệnh và truy cập trực tiếp và thao tác các thư mục và tệp. Ý tưởng về việc phụ thuộc vào một IDE để hiểu mã ở mức cơ bản như vậy có vẻ như vô cảm. Có vẻ như văn hóa C # hoàn toàn khác về điểm này. Và tôi tự hỏi nếu tôi chỉ cần chấp nhận và chấp nhận điều đó như là một phần trong việc học C # của tôi.

Điều này dẫn tôi đến câu hỏi của tôi ở đây: phát triển C # có hiệu quả không thể tách rời với IDE bạn sử dụng không?

Visual Studio tiện lợi đến mức sau khi làm việc với nó một thời gian, rất khó để sử dụng một IDE khác. Nó có rất nhiều công cụ tiện dụng và một loạt các plugin có sẵn, vì vậy thực tế nó có mọi tính năng bạn cần.

Mặt khác, bất kể ngôn ngữ nào bạn học, bạn nên sử dụng dòng lệnh ngay từ đầu, để bạn có thể hiểu rõ hơn về cách thức hoạt động của nó. C # không phải là một ngoại lệ.

Phát triển C # có hiệu quả không thể tách rời với IDE bạn sử dụng không?

Về mặt lý thuyết là không, nhưng thực tế là có. Có thể viết bằng C # bằng trình soạn thảo văn bản và dòng lệnh, nhưng nếu bạn có Visual Studio, bạn sẽ không bao giờ làm điều này. Trong thực tế, rất ít lập trình viên đã từng thực thi mã C # từ dòng lệnh.

BTW Nếu bạn cảm thấy bất tiện using foo, bạn có thể sử dụng toàn bộ đường dẫn khi sử dụng một loại.

Ý tưởng về việc phụ thuộc vào một IDE để hiểu mã ở mức cơ bản như vậy có vẻ như vô cảm.

Vấn đề không phải là hiểu mã của bạn: được cung cấp đủ thời gian, bạn luôn có thể xác định đúng biến bằng trình soạn thảo văn bản cơ bản hoặc ngay cả trong bản in. Theo như sự hiểu biết về mã, sự phụ thuộc IDE hoàn toàn không tồn tại.

Định vị tài liệu tham khảo của bạn một cách hiệu quả là một chủ đề hoàn toàn khác: Tôi yêu khả năng tìm ra cách sử dụng các biến Java trong Eclipse cũng như tôi thích tìm các điểm khai báo trong Visual Studio, cho cả C # và C ++. Tôi thích dành thời gian của mình để viết mã hơn là tìm kiếm các điểm khai báo bằng tay. Điều này tương tự như làm toán: Tôi có thể nhân các số nhiều chữ số trên một tờ giấy, nhưng tôi thích sử dụng máy tính để tiết kiệm cho mình một hoặc hai phút.

Bắt đầu từ một "kích cỡ quan trọng" nhất định của mã, một IDE tốt sẽ trở nên rất hữu ích bất kể ngôn ngữ lập trình. Kích thước có thể thay đổi ngôn ngữ theo ngôn ngữ, nhưng một khi bạn vượt qua hàng ngàn dòng, có một IDE giúp bất kể ngôn ngữ của bạn. Điều này có liên quan nhiều đến những hạn chế của tâm trí con người hơn là với một ngôn ngữ lập trình cụ thể: đến một lúc nào đó, bộ nhớ ngắn hạn của bạn bị ràng buộc là "tràn".

Có những thủ thuật cho phép bạn tăng kích thước quan trọng đó khi IDE trở nên hữu ích. Ví dụ: bạn có thể tuân theo quy ước đặt tên (tên Hungary rất lớn trong thế giới C ++ tại một số điểm, đặc biệt là trong số các học viên Windows). Một mẹo phổ biến khác là các biến đối tượng đủ điều kiện với this.ngay cả trong các bối cảnh không yêu cầu trình độ như vậy.

Những mánh khóe này đi kèm với sự đánh đổi: gần như chắc chắn, chúng làm cho chương trình của bạn không thể đọc được bằng cách che khuất tên hoặc chèn các tham chiếu rõ ràng mà việc đóng gói được dự định che giấu. Đối mặt với sự lựa chọn, tôi chọn mã trông sạch sẽ cộng với IDE qua mã trông kém sạch hơn trừ IDE. Tuy nhiên, tôi hoàn toàn nhận ra rằng lựa chọn của người khác có thể khác với tôi.

Nhiều lập trình viên Python thích cách tiếp cận trình soạn thảo văn bản để mã hóa, sử dụng một cái gì đó như Sublime Text 2 hoặc vim, trong đó tất cả là về mã, cộng với các công cụ dòng lệnh và truy cập trực tiếp và thao tác các thư mục và tệp.

Điều đó thật tuyệt, nhưng nó bỏ lỡ quan điểm của VS IDE. Quan điểm của một IDE như VS là hỗ trợ phát triển nhanh chóng thông qua các công cụ mã mạnh như tái cấu trúc và intellisense. VS là một trình soạn thảo rất tốt cho mã C #.

Bây giờ C # cho phép bạn viết mã theo kiểu phụ thuộc vào IDE của nó ở mức độ lớn hơn (bạn có thể sử dụng nhiều vartừ khóa và tương tự). Một số người thích rõ ràng hơn, ví dụ bằng cách sử dụng các bí danh không gian tên để rõ ràng về không gian tên mà một lớp thuộc về (như importtrong Java hoặc Python). Đó là một sự lựa chọn phong cách mã hóa nhiều hơn là một tính năng của ngôn ngữ.

Vì C # được nhập tĩnh (mặc dù với một số tiện ích mở rộng động, kể từ phiên bản 4), việc tìm ra loại nào đang được nhắc đến là khá dễ dàng - nếu chúng sai, mã sẽ không được biên dịch và VS không phải là IDE duy nhất với sự hỗ trợ cho C # intellisense. Nó có lẽ là tốt nhất mặc dù.

Phát triển C # mà không có IDE mạnh mẽ (như VS) giống như đóng đinh bằng tay khi bạn đã có một cây súng bắn đinh hàng đầu - có thể có thời gian kỳ lạ bạn cần làm, nhưng các chuyên gia sử dụng công cụ phù hợp cho công việc .

Tôi cũng nói điều tương tự cũng đúng với Java. Nếu có một IDE mạnh mẽ với các công cụ tái cấu trúc mã và mã hóa ngoài kia thì có lẽ bạn nên sử dụng nó.

Tuy nhiên, hãy nhìn nó theo cách khác - nếu bạn không muốn intellisense, biên dịch kiểm tra mã thời gian và phân tích / tái cấu trúc mã thì IDE không phải là hướng đi và cũng không phải là ngôn ngữ được gõ tĩnh. Tôi nghĩ đó là cách khác:

Nhiều lập trình viên thích cách tiếp cận trình soạn thảo văn bản để mã hóa không thu được nhiều từ các ngôn ngữ được nhập tĩnh (như C # và Java) và vì vậy có thể tốt hơn nếu họ sử dụng các ngôn ngữ động như Python và Javascript.

Tôi nghĩ:

• Ngôn ngữ động phù hợp với các công cụ nhẹ (IDE nặng mang lại ít lợi ích hơn ở đây)
• Ngôn ngữ tĩnh phù hợp với các IDE mạnh mẽ (các công cụ có thể trợ giúp với mã với chi phí linh hoạt)

Để trả lời câu hỏi của bạn: mặc dù nó đang thay đổi từ từ, môi trường phát triển của Microsoft chủ yếu là độc canh .

Cách tiếp cận này có nhiều mặt tích cực và tiêu cực, có thể được tranh luận về chiều dài (ví dụ: xem xét ưu và nhược điểm của các nền tảng mở và đóng, chẳng hạn như PC so với Xbox), nhưng vào cuối ngày, công cụ từ Microsoft là thứ tốt nhất người sử dụng. Công ty cũng đã chỉ ra rằng việc ra quyết định của họ thường là một loại "cho giá trị nhất đối với đa số người dùng của chúng tôi" quá trình, luôn tìm kiếm sự thỏa hiệp thực tế (gần đây nhất - xem xét nguyên cảo ). Vì vậy, về cơ bản, tôi sẽ không ngạc nhiên khi thấy rằng sự phát triển của C # đã / được thực hiện với công cụ (VS) trong tâm trí.

Đối với một, C # không phải là Python .. Có các phương pháp thiết kế khác nhau.

Bây giờ, để trả lời câu hỏi của bạn, bạn hoàn toàn có thể sử dụng câu lệnh Python của mình bằng cách sử dụng các câu lệnh.

using FooBar=MyName.Foo.FooBar; 

Nó chỉ là nó chắc chắn không phải là tiêu chuẩn bởi vì nó không dễ dàng như vậy. Tuy nhiên, tôi nghĩ bạn nên bớt lo lắng về việc biết chính xác mỗi lớp đến từ đâu. Tôi không hiểu toàn bộ quan điểm của việc làm theo cách này trong Python.

Ngoài ra, C # là một ngôn ngữ cho vay rất tốt để sử dụng IDE để làm cho nó dễ dàng hơn. Intellisense rất đơn giản để thực hiện, đặc biệt là so với các ngôn ngữ động như Ruby và Python. Tuy nhiên, bạn không cần phải bị mắc kẹt với IDE của mình. Tôi đã nghe nói về những người sử dụng Eclipse. Tất nhiên cũng có MonoDevelop (mà tôi sử dụng khá nhiều) và thậm chí bạn có thể làm việc từ một dòng lệnh. Đôi khi trên máy chủ của tôi, tôi sẽ chỉnh sửa các tệp C # vivà sau đó sử dụng xbuildđể xây dựng lại nó ... Chỉ là việc sử dụng IDE giúp mọi thứ dễ dàng hơn nhiều so với dòng lệnh cho các trường hợp điển hình.

Có ai bận tâm đọc đường xuống đây không ??

Tôi tóm tắt bằng cách nói rằng chức năng IDE phức tạp ồ ạt là không thể thiếu và nó sẽ (nên) phát triển thành Zen of Sublime VimNess một ngày nào đó ....

Phần mềm của chúng tôi là 129 dự án khoảng 2 triệu LỘC. Thêm vào tính đại chúng của .NET framework và đưa ra tất cả những gì tôi có thể nói là IDE rất quan trọng, vượt qua các động lực của câu hỏi của chủ đề này.

Cái nhìn sâu sắc về cơ sở mã

Giai đoạn = Stage. Bạn biết các loại tính năng chúng ta đang nói về; ngoại trừ sự tiện lợi của nó trở nên không thể thiếu và cần thiết với loại cơ sở mã mà tôi xử lý.

Tôi viết mã tốt hơn vì IDE. Tôi luôn thêm thông điệp tùy chỉnh vào các bài kiểm tra Nunit của mình vì nó dễ dàng, nhanh chóng và chính xác. Tôi ủng hộ việc liệt kê các chuỗi do phần lớn là intellisense. Tôi không ngần ngại sử dụng mô tả / đặt tên dài - một câu lệnh nhiều dòng được soạn thảo nhanh và rõ ràng.

Nhưng ngay cả sự thông minh này cũng có quá nhiều lần. Tôi thường sử dụng tìm kiếm văn bản "tìm trong tập tin" cũ.

Mã hóa giúp

Đây là nơi tôi khóc "đủ rồi!". Hãy tưởng tượng một màn hình đầy đủ với hàng tá màu chủ yếu là che khuất, một số biến đặc biệt được tô sáng ở khắp mọi nơi, dấu ngoặc kép làm nổi bật cái niềng thực sự là gì, nguệch ngoạc ở khắp mọi nơi vì "nó" muốn tôi viết tài liệu không phải mã, biểu tượng cho các menu ngữ cảnh (bạn chỉ cần nhấp vào nó! sau đó bỏ qua phần lớn thời gian), một cửa sổ bật lên trợ giúp chữ ký kéo dài 2/3 màn hình theo chiều ngang, hiển thị theo chiều dọc một số tình trạng quá tải, một cửa sổ bật lên vì nơi bạn vừa rời khỏi con trỏ chuột .... Tôi Thậm chí không thể nhìn thấy dòng & ^!% * s * của mã tôi đang làm việc!

Vis.Stud. cần phải nắm lấy chủ nghĩa tối giản để tôi có thể tập trung vào mã hóa và không phải trải qua hàng trăm (hàng ngàn nếu bạn đếm mọi cài đặt mã màu và tất cả các plugin đó) trong các trận chiến để lấy lại sự tỉnh táo. Một " Pareto " key sẽ là tuyệt vời.

Phát triển C # có hiệu quả không thể tách rời với IDE bạn sử dụng không?

Dĩ nhiên là không. Tại sao bạn không nhập toàn bộ không gian tên? Việc lựa chọn sử dụng IDE tích hợp hoặc trình soạn thảo văn bản không liên quan gì đến điều đó. Nhập toàn bộ không gian tên không làm cho việc đọc mã hoặc sử dụng nó trở nên khó khăn hơn.

Hãy nhớ rằng, C # là một ngôn ngữ đánh máy. Nếu bạn nhập một số không gian tên có cùng lớp, bạn sẽ gặp lỗi biên dịch.

Cá nhân tôi không sử dụng khai báo kiểu theo nhiều cách. Thay vào đó, tôi sử dụng vartừ khóa thay vì các lý do mà tôi mô tả ở đây: http://blog.gauffin.org/2012/08/to-var-or-not-to-var-is-that-really-the-question/

Sự hiểu biết của tôi là trong Python, "mọi thứ đều công khai" hoặc một cái gì đó cho hiệu ứng đó. Trong C #, người thiết kế mô-đun quyết định cái gì là công khai và cái gì không, vì vậy khi bạn làm, importbạn chỉ nhận được API công khai. Đó có thể là một lý do cho sự khác biệt mà bạn mô tả.

Phát triển C # có hiệu quả không thể tách rời với IDE bạn sử dụng không?

Ở công việc trước đây, tôi chủ yếu sử dụng vim để viết mã bằng các ngôn ngữ như C #, JavaScript, Powershell, Perl, C ++ và khá nhiều nhà phát triển đã sử dụng để làm điều gì đó tương tự. Dự án này quá lớn đối với Visual Studio.

Điều đó nói rằng, hầu hết các nhà phát triển C # đối phó với các dự án nhỏ hơn nhiều và khá vui khi sử dụng VS.

Đây là một quan điểm thú vị về phát triển C #. Những gì bạn đang hỏi vượt ra ngoài C #, nếu bạn đang hỏi về IDE.

Giống như bạn nói, trong Python, bạn có thể sử dụng các trình soạn thảo khác nhau để viết mã của mình. Bạn cũng có thể làm điều đó với .NET framework. Ngoài ra còn có các công cụ IDE khác mà bạn có thể sử dụng như SharpDevelop. Visual Studio được hợp tác phát triển rất chặt chẽ với .NET framework và tương đối đắt tiền. Các công cụ như SharpDevelop và các phiên bản "Express" của VS tồn tại để lôi kéo nhiều nhà phát triển sử dụng .NET. Về cơ bản, tất cả các IDE làm cho bạn là cung cấp một môi trường có tổ chức, thường là với intellisense, các tiện ích bổ sung cho năng suất và một "trợ thủ" để lắp ráp những gì có thể trở thành một dòng lệnh trông rất đáng sợ để chuyển đến trình biên dịch của bạn. Điều này cũng đúng với Java, các công cụ như Eclipse chỉ cung cấp các cải tiến về tổ chức và năng suất cho chúng ta. Dưới mui xe, không có gì kỳ diệu xảy ra cho đến khi bạn xây dựng hoặc biên dịch dự án của mình và sự tôn trọng đó,

Khi bạn nói về câu lệnh "sử dụng" trong C # và so sánh nó với Python, nó không thực sự giống như vậy đang diễn ra dưới mui xe. Các câu lệnh sử dụng được trình biên dịch sử dụng để hỗ trợ nỗ lực chuyển đổi mã C # thành MSIL. Trong MSIL, không có lệnh "nhập tất cả các lớp này từ không gian tên" này. Theo mã thời gian ở mức MSIL, tất cả các lớp đã được gắn thẻ với tên đầy đủ của họ. Những tuyên bố "sử dụng" và "nhập khẩu" này là để hỗ trợ khả năng đọc của con người. Chúng không phải là các lệnh tối ưu hóa trình biên dịch. Sau khi tất cả "gắn thẻ tên đủ điều kiện" ban đầu này đã diễn ra, có thể có một loại "rút gọn" mức độ thấp đối với FQN nhưng điều này là để hỗ trợ trình biên dịch / trình thông dịch thực thi nhanh hơn.

Một điểm khác biệt cơ bản cuối cùng giữa tất cả các ngôn ngữ được đề cập ở đây là một số ngôn ngữ được VM giải thích, một số được diễn giải theo kiểu JIT và một số được biên dịch đầy đủ. Làm thế nào những cách sử dụng các chỉ thị này được thực hiện trên các trình biên dịch và trình thông dịch khác nhau rất nhiều.

HTH.

Tôi nghĩ rằng về mặt lịch sử, câu trả lời là khá nhiều, vâng - giúp C # phát triển và hoạt động hiệu quả trong mọi thứ bên ngoài Visual Studio, Xamarin hoặc SharpDevelop chỉ là một trải nghiệm khó chịu.

Nhưng gần đây, rất nhiều dự án đã xuất hiện giúp dễ dàng hơn, ví dụ:

OmniSharp , cung cấp một nền tảng cho intellisense và tái cấu trúc, cùng với các plugin vim, emacs, nguyên tử và tuyệt vời. Tôi chưa thực sự sử dụng nó, vì vậy tôi không biết nó hoạt động tốt như thế nào, nhưng nó có vẻ đầy triển vọng.

Yeoman ASP.NET MVC tạo , giúp bootstrap một dự án MVC mới (có thể các trình tạo khác tồn tại).

paket , một giải pháp thay thế cho NuGet nơi bạn thực sự có thể thêm các gói NuGet vào dự án của mình từ dòng lệnh và cập nhật các tệp .csproj của bạn (mặc dù có một công cụ dòng lệnh NuGet, thực sự cập nhật các dự án để sử dụng các gói là một phần của IDE tích hợp, không phải công cụ dòng lệnh).

Paket có hàm ý rằng bạn phải điều chỉnh mã nguồn của mình để sử dụng nó - vì vậy nếu bạn là thành viên duy nhất trong nhóm và muốn sử dụng trình soạn thảo văn bản để mã hóa, và mọi người khác sử dụng Visual Studio, bạn sẽ phải thuyết phục mọi người khác để điều chỉnh giải pháp cho nhu cầu của bạn :(

Vì vậy, bạn sẽ có thể đứng dậy và chạy, nhưng có rất nhiều việc phải làm để có được chuỗi công cụ của bạn và chạy hiệu quả.

Không còn nữa:

http://www.omarnarp.net/

OmniSharp là một nhóm các dự án nguồn mở, mỗi dự án có một mục tiêu - Để cho phép phát triển .NET tuyệt vời trong trình soạn thảo mà bạn chọn.

Thật thú vị khi nói Cross Platform .NET. Nhưng nó có hợp lý để ai đó phát triển .NET mà không có Visual Studio và Windows không?

Có vui không khi làm .NET trên máy Mac trong Sublime? Ubuntu và Emacs? Windows và nguyên tử? Bạn có thể sử dụng trình soạn thảo PLUS của mình để sử dụng các tính năng tuyệt vời như Intellisense (không chỉ tự động hoàn thành), Thêm tài liệu tham khảo, Định dạng tài liệu và nhiều tính năng khác. Phát triển mọi nơi, triển khai mọi nơi (và lên Azure!)

Tôi đã thử nghiệm điều này với subime3 và osx

Thêm mẫu tại

http://blog.jonathanchannon.com/2014/11/12/csharp-first- class-Citizen-sublime-text /