Чи ефективно розробка C # невіддільна від IDE, який ви використовуєте?

Я програміст Python, який навчається C #, який намагається перестати хвилюватися і просто люблю C # за те, що він є, а не постійно порівнює його назад з Python.

Мене наздогнало одне питання: відсутність чіткості про те, де визначені речі, як це детально описано в цьому запитанні про переповнення стека . Коротше кажучи: у C # using fooне fooвказано, з яких імен вони стають доступними, що є аналогом from foo import *у Python - форми, яка не перешкоджає культурі кодування Python бути неявним, а не більш чітким підходом from foo import bar.

Мене дуже вразили відповіді на програму програмування C # на програму C #, яка полягала в тому, що на практиці ця відсутність явності насправді не має значення, оскільки у вашій IDE (імовірно Visual Studio) ви можете просто навести курсор на ім’я та повідомити його система, звідки походить назва. Наприклад:

Тепер, теоретично, я розумію, що це означає, коли ви шукаєте текстовий редактор, ви не можете сказати, звідки беруться типи в C # ... але на практиці я не вважаю це проблемою. Як часто ви переглядаєте код і не можете використовувати Visual Studio?

Це одкровення для мене. Багато програмістів Python віддають перевагу підходу текстового редактора до кодування, використовуючи щось на кшталт Sublime Text 2 або vim, де все стосується коду, плюс інструменти командного рядка та прямий доступ та маніпулювання папками та файлами. Ідея бути залежною від IDE для розуміння коду на такому базовому рівні видається анафемою. Здається, культура C # докорінно відрізняється. І мені цікаво, чи мені просто потрібно прийняти та прийняти це як частину мого вивчення C #.

Що призводить мене до мого питання тут: чи розробка C # невіддільна від IDE, який ви використовуєте?

Visual Studio настільки зручний, що після роботи з ним деякий час важко використовувати інший IDE. У ньому багато зручних інструментів і купа плагінів, тому практично у нього є кожна необхідна вам функція.

З іншого боку, яку б мову ви не вивчали, рекомендується використовувати командний рядок на початку, щоб ви могли краще зрозуміти, як це працює. C # не є винятком.

чи розробка C # ефективно невіддільна від IDE, який ви використовуєте?

Теоретично ні, але практично так. Можна писати на C # за допомогою текстового редактора та командного рядка, але якщо у вас є Visual Studio, ви ніколи цього не робите. Насправді дуже мало програмістів коли-небудь виконували код C # з командного рядка.

BTW Якщо вам незручно using foo, ви можете використовувати весь шлях під час використання типу.

Ідея бути залежною від IDE для розуміння коду на такому базовому рівні видається анафемою.

Це не питання розуміння вашого коду: якщо достатньо часу, ви завжди можете знайти потрібну змінну за допомогою базового текстового редактора або навіть у роздруківці. Що стосується розуміння коду, то залежності від IDE абсолютно не існує.

Ефективне розміщення посилань - це зовсім інша тема: мені подобається можливість знаходити використання змінних Java в Eclipse стільки, скільки я люблю знаходити точки декларування у Visual Studio, як для C #, так і для C ++. Я вважаю за краще витрачати свій час на кодування, а не шукати точки декларування вручну. Це схоже на заняття математикою: я можу множити багатозначні числа на аркуші паперу, але я вважаю за краще використовувати калькулятор, щоб заощадити собі хвилину-дві.

Починаючи з певного "критичного розміру" коду, хороший IDE стає дуже корисним незалежно від мови програмування. Розмір може залежати від мови до мови, але коли ви перетнете кілька тисяч рядків, IDE допомагає незалежно від вашої мови. Це пов'язано більше з обмеженнями людського розуму, ніж з певною мовою програмування: в якийсь момент ваша короткочасна пам'ять буде прив’язана до «переповнення».

Існують хитрощі, що дозволяють збільшити той критичний розмір, коли IDE стане корисним. Наприклад, ви можете дотримуватися конвенції про іменування (угорські імена в певний момент були великими у світі C ++, особливо серед практикуючих Windows). Ще один поширений трюк - кваліфікуючі змінні екземплярів, this.навіть у контекстах, де така кваліфікація не потрібна.

Ці хитрощі мають компроміси: майже неминуче вони роблять вашу програму менш читаною, затушовуючи імена, або вставляючи явні посилання, які інкапсуляція мала ховати. Зіштовхнувшись з вибором, я вибираю чистий вигляд плюс IDE над менш чистою на вигляд кодом мінус IDE. Я повністю усвідомлюю, що вибір інших людей може відрізнятися від мого.

Багато програмістів Python віддають перевагу підходу текстового редактора до кодування, використовуючи щось на кшталт Sublime Text 2 або vim, де все стосується коду, плюс інструменти командного рядка та прямий доступ та маніпулювання папками та файлами.

Це чудово, але він не вистачає точки VS IDE. Точкою IDE, як VS, є швидка підтримка розробки за допомогою сильних інструментів коду, таких як рефакторинг та інтеліссенс. VS - дуже хороший редактор для C # коду.

Тепер C # дозволяє кодувати в стилі, який більшою мірою залежить від його IDE (ви можете використовувати безліч varключових слів тощо). Деякі люди вважають за краще бути більш чіткими, наприклад, використовуючи псевдоніми простору імен, щоб зрозуміти, до якого простору імен належить клас (наприклад, importу Java чи Python). Це скоріше вибір стилю кодування, ніж особливість мови.

Оскільки C # набирається статично (хоча з деякими динамічними розширеннями, як на v4), завжди досить легко з’ясувати, на які типи посилаються - якщо вони помиляються, код не компілюється, а VS - не єдиний IDE з підтримкою C # intellisense. Це, мабуть, найкраще.

Розробка C # без потужного IDE (наприклад, VS) - це скоріше, як забивання цвяхів вручну, коли у вас вже є цвяховий пістолет верхнього ряду - можливо, вам буде час, коли це потрібно, але професіонали використовують правильний інструмент для роботи .

Я б сказав, те саме, мабуть, стосується і Java. Якщо там є потужний IDE з інструментами intellisense та refactor коду, ви, ймовірно, використовуєте його.

Однак погляньте на це навпаки - якщо ви не хочете інтелігенції, компілюйте перевірку коду часу та аналіз коду / рефакторинг, тоді роздутий IDE - це не дорога, і не є статично набраною мовою. Я думаю, що це навпаки:

Багато програмістів, які віддають перевагу підходу текстового редактора до кодування, не отримують стільки від статично набраних мов (як C # та Java), і тому може бути краще, якщо вони дотримуються динамічних, таких як Python та Javascript.

Я думаю:

• Динамічні мови підходять для легких інструментів (вагомі IDE тут надають меншу користь)
• Статичні мови підходять для потужних IDE (інструменти можуть допомогти з кодом ціною гнучкості)

Щоб відповісти на ваше запитання: хоча це повільно змінюється, середовище розробки Microsoft значною мірою є монокультурою .

Цей підхід має багато позитивів і негативів, про які можна міркувати довго (наприклад, врахуйте плюси і мінуси відкритих і закритих платформ, таких як ПК проти Xbox), але в кінці дня інструментарій від Microsoft - саме те, що найбільше люди використовують. Компанія також показала, що їх прийняття рішень часто є своєрідним "процесом, який надає найбільшу цінність більшості наших користувачів", завжди шукаючи практичних компромісів (останнім часом - розгляньте Typescript ). В основному, я би не здивувався, виявивши, що розробка C # була / робиться з урахуванням інструментарію (VS).

Для одного, C # не Python. Існують різні методики проектування.

Тепер, щоб відповісти на ваше запитання, цілком можливо використовувати ваш Python-esque за допомогою операторів.

using FooBar=MyName.Foo.FooBar; 

Просто це, безумовно, не є нормою, оскільки це не так вже й просто. Однак, я думаю, вам варто менше турбуватися про те, щоб точно знати, звідки саме походить кожен клас. Я не розумію цілого сенсу робити це так у Python.

А також, C # - це мова, яка дуже добре підходить для використання IDE, щоб зробити це простіше. Intellisense надзвичайно простий у виконанні, особливо порівняно з динамічними мовами, такими як Ruby та Python. Однак вам не доведеться приставати до свого IDE. Я чув про людей, які використовують Eclipse. Також, звичайно, є MonoDevelop (який я досить багато використовую), і ви навіть можете працювати з командного рядка. Іноді на моєму сервері я буду редагувати файли C #, viа потім використовувати xbuildдля його відновлення ... Просто використання IDE значно покращує порівняно з командним рядком типові випадки.

Хтось турбується читати тут вниз ??

Підводячи підсумок, кажу, що масово складний функціонал IDE є незамінним, і він (повинен) перетворитися на дзен Sublime VimNess якогось дня ....

Наше програмне забезпечення - це 129 проектів близько 2 млн. Локальних місць. Додайте масивність рамки .NET і, враховуючи це, все, що я можу сказати, це IDE є життєво важливим, що переходить мотивацію питання цього потоку.

Ознайомлення з базою кодів

Період. Ви знаєте види особливостей, про які ми говоримо; за винятком того, що його зручність стає незамінною та важливою у тому, з яким кодом я маю справу.

Я пишу кращий код через IDE. Я завжди додаю власні повідомлення до своїх тестів Nunit, тому що це легко, швидко та точно. Я віддаю перевагу перерахуванням рядків, що значною мірою обумовлено інтелігенцією. Я не соромлюсь використовувати описові / довгі імена - багаторядковий вислів складається швидко і чисто.

Але навіть ця кмітливість часом занадто велика. Я часто використовую добрий-старий пошук тексту в «файлах».

Довідка з кодування

Ось де я часто кричу "досить!". Уявіть, що на екрані є з десяток кольорів здебільшого затемнення, якась певна змінна, що виділяється скрізь, підтяжка підсвічуючи затемненням того, що насправді є дужкою, чітко підкреслюється скрізь, оскільки "це" хоче, щоб я писав літературу не код, а піктограми для контекстних меню Resharper (ви просто треба клацнути по ньому! потім ігнорувати його більшу частину часу), підпис підпису, що охоплює 2/3 екрана по горизонталі, вертикально відображаючи кілька перевантажень, спливаюче вікно, через те, що ви щойно трапилися залишити курсор миші .... I не можу навіть побачити рядок & ^!% * s * коду, над яким я працюю!

Віс.Студ. потрібно охопити мінімалізм, щоб я міг зосередитись на кодуванні, а не проходити сотні (тисячі, якщо рахувати кожен параметр кольорового кодування та всі ці плагіни) налаштувань у програшній битві за повернення розуму. Ключ « Парето » був би чудовим.

чи розробка C # ефективно невіддільна від IDE, який ви використовуєте?

Звичайно, ні. Чому б ви не імпортували весь простір імен? Вибір використання інтегрованої IDE або текстового редактора не має нічого спільного з цим. Імпорт цілого простору імен не ускладнює читання коду чи його використання.

Пам'ятайте, що C # - це набрана мова. Якщо ви імпортуєте кілька просторів імен, які мають один клас, ви отримаєте помилку компіляції.

Я особисто жодним чином не використовую декларації типу. Натомість я використовую varключове слово замість тих причин, які я тут описую: http://blog.gauffin.org/2012/08/to-var-or-not-to-var-is-that-really-the-question/

Я розумів, що в Python "все є загальнодоступним" або щось в цьому плані. У C # дизайнер модулів вирішує, що є загальнодоступним, а що ні, тому коли ви робите, importви все одно отримуєте лише публічний API. Це може бути причиною різниці, яку ви описуєте.

чи розробка C # ефективно невіддільна від IDE, який ви використовуєте?

На своїй попередній роботі я в основному використовував vim для кодування такими мовами, як C #, JavaScript, Powershell, Perl, C ++, і досить багато розробників використовували щось подібне. Проект був просто занадто великий для Visual Studio.

Однак, більшість розробників C # мають справу зі значно меншими проектами і дуже раді використовувати VS.

Це цікавий погляд на розвиток C #. Те, що ви запитуєте, виходить за межі C #, якщо ви запитуєте про IDE.

Як ви кажете, в Python ви можете використовувати різні редактори для написання свого коду. Це можна зробити і з .NET Framework. Існують також інші інструменти IDE, якими ви можете користуватися, наприклад, SharpDevelop. Visual Studio дуже тісно співпрацює з рамкою .NET і коштує відносно дорого. Такі інструменти, як SharpDevelop та "Express" версії VS існують, щоб залучати більше розробників до використання .NET. По суті, все, що IDE робить для вас, - це організоване середовище, як правило, інтелігенція, додатки для продуктивності та "помічник" для збирання того, що в кінцевому підсумку може бути дуже страшним виглядом командного рядка для передачі вашому компілятору. Те саме стосується Java, такі інструменти, як Eclipse, просто забезпечують організацію та підвищення продуктивності. Під кришкою нічого магічного не відбувається, поки ви не складете або не складете свій проект, і це поважайте,

Якщо ви говорите про оператор "using" в C # і порівнюєте його з Python, це насправді не те саме, що відбувається під кришкою. Використовувані оператори використовуються компілятором для сприяння зусиллям з перетворення коду C # в MSIL. У MSIL немає директиви "імпортувати всі ці класи з цього простору імен". За тим, що код знаходиться на рівні MSIL, усі класи позначені тегами їх повноцінно названими іменами. Ці заяви про "використання" та "імпорт" допомагають читати людині. Вони не є командами оптимізації компілятора. Після того, як все початкове "тегування повнокваліфікованих імен" було продовжено, може виникнути якась "мінімізація" низького рівня до FQN, але це допоможе компілятору / інтерпретатору виконати швидше.

Однією остаточною принциповою відмінністю всіх цих мов, про які йдеться тут, є те, що деякі з них інтерпретуються VM, деякі інтерпретуються стилем JIT, а деякі повністю компілюються. Те, як ці директиви використовуються для цих компіляторів та інтерпретаторів, сильно відрізняється.

HTH.

Я думаю, що історично відповідь - це дуже багато, так - підвищення C # розробки та ефективний запуск у будь-якому, що знаходиться поза Visual Studio, Xamarin або SharpDevelop, було просто занадто неприємним досвідом.

Але останнім часом з’явилося багато проектів, що полегшує процес, наприклад:

OmniSharp , забезпечує основу для інтелігенції та рефакторингу, разом із плагінами vim, emacs, atom та sublime. Я його фактично не використовував, тому не знаю, наскільки добре він працює, але він виглядає багатообіцяючим.

Генератори MVC Yeoman ASP.NET допомагають завантажувати новий проект MVC (можливо, існують інші генератори).

пакет , альтернатива NuGet, де ви можете фактично додати пакети NuGet до свого проекту з командного рядка та оновити файли .csproj (хоча там був інструмент командного рядка NuGet, фактично оновлення проектів для використання пакетів було частиною IDE інтеграція, а не інструменти командного рядка).

Пакет має на увазі те, що ви повинні адаптувати свій вихідний код до його використання, тому, якщо ви є одним членом команди та хочете використовувати текстовий редактор для кодування, а всі інші користуються Visual Studio, вам доведеться переконати всіх інше, щоб адаптувати рішення до ваших потреб :(

Таким чином, ви повинні мати можливість вставати та працювати, але для ефективної роботи ланцюжка інструментів потрібно порівняно більше зробити.

Більше:

http://www.omnisharp.net/

OmniSharp - це сім'я проектів з відкритим кодом, кожен з яких має одну мету - забезпечити чудову розробку .NET у ВАШЕМ редакторі на вибір.

Приємно сказати, що Cross Platform .NET. Але чи розумно хтось розвивати .NET без Visual Studio та Windows?

Чи приємно робити .NET на Mac у Sublime? Ubuntu та Emacs? Windows та Atom? Ви можете використовувати PLUS-редактор для використання таких чудових функцій, як Intellisense (не лише автозаповнення), Додати довідку, форматувати документ та багато іншого. Розвивайте де завгодно, розміщуйте в будь-якому місці (і в Azure!)

Я перевірив це з subime3 та osx

Більше зразків на

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