Я программист на Python, изучающий C #, который пытается перестать беспокоиться и просто любит C # за то, что он есть, вместо того, чтобы постоянно сравнивать его с Python.
Я поймал один момент: отсутствие ясности относительно того, где вещи определены, как подробно описано в этом вопросе переполнения стека . Вкратце: в C # using fooне говорится о том, какие имена fooстановятся доступными, что аналогично from foo import *Python - форма, которая не поощряется в культуре кодирования Python за то, что она неявная, а не более явный подход from foo import bar.
Я был довольно поражен ответами Stack Overflow на этот вопрос от программистов на C #, которые заключались в том, что на практике это отсутствие явности не имеет большого значения, потому что в вашей IDE (предположительно Visual Studio) вы можете просто навести курсор на имя и сказать система, откуда исходит название. Например:
Теперь, в теории, я понимаю, что это означает, что когда вы просматриваете текстовый редактор, вы не можете сказать, откуда берутся типы в C # ... но на практике я не считаю, что это проблема. Как часто вы на самом деле смотрите на код и не можете использовать Visual Studio?
Это откровение для меня. Многие программисты Python предпочитают подход к текстовому редактору для кодирования, используя что-то вроде Sublime Text 2 или vim, где все дело в коде, плюс инструменты командной строки и прямой доступ и манипулирование папками и файлами. Идея зависимости от IDE для понимания кода на таком базовом уровне кажется анафемой. Кажется, культура C # радикально отличается в этом вопросе. И мне интересно, нужно ли мне просто принять и принять это как часть моего изучения C #.
Это приводит меня к моему вопросу: эффективно ли развитие C # неотделимо от используемой вами среды IDE?
using MyType = MyNamespace.MyType;?global::и продолжить свой путь.usingне делает ничего доступного, чего не было раньше; это только облегчает доступ (как при меньшем наборе текста, необходимом для использования определенного класса).Ответы:
Visual Studio настолько удобен, что после некоторой работы с ним трудно использовать другую IDE. Он имеет множество удобных инструментов и множество доступных плагинов, поэтому практически у него есть все функции, которые вам понадобятся.
С другой стороны, на любом языке, который вы изучаете, рекомендуется использовать командную строку в начале, чтобы вы могли лучше понять, как она работает. C # не является исключением.
Теоретически нет, но практически да. Можно писать в C # с помощью текстового редактора и командной строки, но если у вас есть Visual Studio, вы бы никогда этого не сделали. На самом деле очень немногие программисты когда-либо выполняли код C # из командной строки.
Кстати, если вам неудобно
using foo, вы можете использовать весь путь при использовании типа.источник
Это не вопрос понимания вашего кода: при наличии достаточного времени вы всегда можете найти нужную переменную в обычном текстовом редакторе или даже в распечатке. Что касается понимания кода, зависимость IDE абсолютно не существует.
Эффективный поиск ссылок - это совершенно другая тема: мне нравится находить использование переменных Java в Eclipse так же, как мне нравится находить точки объявления в Visual Studio для C # и C ++. Я предпочитаю тратить свое время на кодирование, а не искать точки декларации вручную. Это похоже на математику: я могу умножать многозначные числа на листе бумаги, но я предпочитаю использовать калькулятор, чтобы сэкономить минуту или две.
Начиная с определенного «критического размера» кода, хорошая IDE становится очень полезной независимо от языка программирования. Размер может варьироваться от языка к языку, но как только вы пересекаете несколько тысяч строк, IDE помогает независимо от вашего языка. Это больше связано с ограничениями человеческого разума, чем с конкретным языком программирования: в какой-то момент ваша кратковременная память ограничена «переполнением».
Существуют приемы, позволяющие увеличить критический размер, когда IDE становится полезным. Например, вы можете следовать соглашению об именах (в какой-то момент венгерские имена были популярны в мире C ++, особенно среди практиков Windows). Другой распространенный трюк - определение переменных экземпляра
this.даже в тех случаях, когда такая квалификация не требуется.Эти приемы сопряжены с компромиссами: почти неизбежно они делают вашу программу менее читаемой, скрывая имена или вставляя явные ссылки, которые инкапсуляция должна была скрыть. Столкнувшись с выбором, я выбираю чистый код плюс IDE, а не менее чистый код минус IDE. Однако я полностью осознаю, что выбор других людей может отличаться от моего.
источник
thisидиосинкратическое использование - но кодирование не является изолированным искусством, и я думаю, что лучше следовать (или, по крайней мере, начинать с) нормам культуры кодирования - то есть быть «Pythonic» с Python и каким бы ни был эквивалентный путь C # с C #. Из приведенных здесь ответов и комментариев ясно, что использование хорошей IDE, такой как Visual Studio, занимает центральное место в «пути C #» (если это правильный путь).Это здорово, но это не относится к VS IDE. Смысл среды IDE, такой как VS, - быстрая поддержка разработки с помощью таких мощных инструментов, как рефакторинг и intellisense. VS очень очень хороший редактор для C # код.
Теперь C # позволяет вам кодировать в стиле, который в большей степени зависит от его IDE (вы можете использовать множество
varключевых слов и тому подобное). Некоторые люди предпочитают быть более явными, например, используя псевдонимы пространства имен, чтобы понять, к какому пространству имен принадлежит класс (какimportв Java или Python). Это больше выбор стиля кодирования, чем особенность языка.Поскольку C # статически типизирован (хотя с некоторыми динамическими расширениями, начиная с v4), всегда довольно легко узнать, на какие типы ссылаются - если они ошибочны, код не скомпилируется, и VS не единственная IDE с поддержкой C # intellisense. Это, вероятно, лучший, хотя.
Разработка C # без мощной IDE (например, VS) - это все равно, что забивать гвозди руками, когда у вас уже есть верхний гвоздодер - может быть, вам понадобится странное время, но профессионалы используют подходящий инструмент для работы ,
Я бы сказал, что то же самое, вероятно, верно и для Java. Если есть мощная IDE с инструментами intellisense и рефакторинга кода, вам, вероятно, стоит использовать ее.
Тем не менее, посмотрите на это с другой стороны - если вы не хотите использовать intellisense, проверять код времени компиляции и анализ / рефакторинг кода, то раздутая среда IDE не подходит, равно как и язык со статической типизацией. Я думаю, что все наоборот
Я думаю:
источник
Чтобы ответить на ваш вопрос: хотя среда медленно меняется, среда разработки Microsoft в значительной степени является монокультурой .
Этот подход имеет много положительных и отрицательных сторон, которые можно долго обсуждать (например, рассмотреть плюсы и минусы открытых и закрытых платформ, таких как ПК против Xbox), но в конечном итоге инструменты от Microsoft - это то, что наиболее люди используют. Компания также показала, что их принятие решений часто является своего рода процессом, «приносящим наибольшую пользу большинству наших пользователей», всегда ищущим практические компромиссы (совсем недавно - рассмотрите Typescript ). В общем, я не удивлюсь, обнаружив, что разработка C # была / сделана с учетом инструментов (VS).
источник
С одной стороны, C # - это не Python. Существуют разные методологии проектирования.
Теперь, чтобы ответить на ваш вопрос, вполне возможно использовать ваш Python-esque с помощью операторов.
Просто это определенно не норма, потому что это не так просто. Тем не менее, я думаю, вы должны меньше беспокоиться о том, чтобы точно знать, откуда именно приходит каждый класс. Хотя я не понимаю всей сути такого подхода в Python.
Кроме того, C # - это язык, который очень хорошо подходит для использования IDE, чтобы упростить его. Intellisense удивительно прост в реализации, особенно по сравнению с динамическими языками, такими как Ruby и Python. Тем не менее, вам не нужно застрять в вашей IDE. Я слышал о людях, использующих Eclipse. Конечно, есть и MonoDevelop (которым я пользуюсь довольно часто), и вы даже можете работать из командной строки. На моем сервере иногда я буду редактировать C # -файлы с помощью,
viа затем использоватьxbuildдля его перестройки ... Просто использование IDE значительно упрощает задачу по сравнению с командной строкой в типичных случаях.источник
Кто-нибудь потрудился прочитать здесь?
Подводя итог, я говорю, что чрезвычайно сложная функциональность IDE необходима, и когда-нибудь она (должна) эволюционировать в дзен возвышенного духа ....
Наше программное обеспечение - это 129 проектов, около 2 млн. LOC. Добавьте к этому масштабность платформы .NET, и, учитывая все это, я могу сказать, что IDE жизненно важен, он выходит за рамки мотивации вопроса этого потока.
Понимание кодовой базы
Период. Вы знаете виды функций, о которых мы говорим; за исключением того, что его удобство становится необходимым и необходимым для того вида кода, с которым я имею дело.
Я пишу лучший код из-за IDE. Я всегда добавляю собственные сообщения в свои тесты Nunit, потому что это легко, быстро и точно. Я предпочитаю перечисления над строками, в значительной степени из-за intellisense. Я без колебаний использую описательное / длинное наименование - многострочный оператор составлен быстро и чисто.
Но даже эта сообразительность порой слишком велика. Я часто использую старый добрый текстовый поиск.
Помощь в кодировании
Здесь я часто плачу «хватит!». Представьте себе экран, заполненный дюжиной цветов, в основном непонятных, какая-то конкретная переменная, выделенная повсюду, выделение фигурных скобок, скрывающее на самом деле фигурную скобку, повсеместно подчеркивание, потому что «оно» хочет, чтобы я писал литературу, а не код, значки контекстных меню Resharper просто нужно щелкнуть по нему! затем игнорировать его большую часть времени), всплывающее окно с справкой по сигнатурам, занимающее 2/3 экрана по горизонтали, с вертикальным отображением нескольких перегрузок, всплывающее окно из-за того, где вы случайно оставили курсор мыши .... не могу даже увидеть строку & ^!% * s * кода, над которым я работаю!
Vis.Stud. Нужно принять минимализм, чтобы я мог сосредоточиться на кодировании, а не проходить сотни (тысячи, если вы учитываете все настройки цветового кодирования и все эти плагины) настроек в проигрышной битве за восстановление здравомыслия. Ключ " Парето " был бы великолепен.
источник
Конечно нет. Почему бы вам не импортировать все пространство имен? Выбор использования интегрированной IDE или текстового редактора не имеет к этому никакого отношения. Импорт всего пространства имен не усложняет чтение кода или его использование.
Помните, C # - это типизированный язык. Если вы импортируете несколько пространств имен, имеющих один и тот же класс, вы получите ошибку компиляции.
Лично я не так часто использую объявления типов. Вместо этого я использую
varключевое слово вместо этого по причинам, которые я описываю здесь: http://blog.gauffin.org/2012/08/to-var-or-not-to-var-is-that-really-the-question/источник
msdn <classname>и нажмите на первую ссылку. Там вы получите пространство имен тоже.Насколько я понимаю, в Python «все публично» или что-то в этом роде. В C # конструктор модулей решает, что является общедоступным, а что нет, поэтому, когда вы делаете это,
importвы все равно получаете только открытый API. Это может быть причиной разницы, которую вы описываете.источник
На моей предыдущей работе я в основном использовал vim для кодирования на таких языках, как C #, JavaScript, Powershell, Perl, C ++, и довольно много разработчиков делали что-то подобное. Проект был слишком большим для Visual Studio.
Тем не менее, большинство разработчиков на C # имеют дело с гораздо меньшими проектами и очень рады использовать VS.
источник
Это интересный взгляд на разработку C #. То, что вы спрашиваете, выходит за рамки C #, если вы спрашиваете об IDE.
Как вы говорите, в Python вы можете использовать различные редакторы для написания своего кода. Вы можете сделать это с помощью .NET Framework тоже. Есть и другие инструменты IDE, которые вы можете использовать, такие как SharpDevelop. Visual Studio тесно связан с платформой .NET и является относительно дорогим. Такие инструменты, как SharpDevelop и «Экспресс» версии VS, существуют, чтобы побудить больше разработчиков использовать .NET. По сути, все, что IDE делает для вас, - это предоставляет организованную среду, обычно с intellisense, надстройками для повышения производительности и «помощником» для сборки, которая может в конечном итоге оказаться очень пугающей командной строкой для передачи вашему компилятору. То же самое относится и к Java, такие инструменты, как Eclipse, просто обеспечивают нам повышение эффективности организации и производительности. Под капотом ничего волшебного не случится, пока вы не создадите или не скомпилируете свой проект и это уважение,
Когда вы говорите об «использовании» в C # и сравниваете его с Python, это не совсем то же самое, что происходит под капотом. Операторы using используются компилятором, чтобы помочь его усилиям по преобразованию кода C # в MSIL. В MSIL нет директивы «импортировать все эти классы из этого пространства имен». К тому времени, когда код находится на уровне MSIL, все классы были помечены их полностью определенными именами. Эти выражения «использование» и «импорт» предназначены для удобства чтения человеком. Они не являются командами оптимизации компилятора. После того, как все это начальное «тегирование полностью определенных имен» продолжилось, может быть что-то вроде низкоуровневого «минимизации» для FQN, но это должно помочь компилятору / интерпретатору выполняться быстрее.
Последнее заключительное фундаментальное различие между всеми этими языками, упомянутыми здесь, состоит в том, что некоторые из них интерпретируются виртуальными машинами, некоторые интерпретируются в стиле JIT, а некоторые полностью компилируются. То, как эти директивы использования реализованы в этих компиляторах и интерпретаторах, сильно отличается.
НТН.
источник
Я думаю, что исторически ответ на этот вопрос в значительной степени, да, - разработка и эффективная разработка C # во всем, кроме Visual Studio, Xamarin или SharpDevelop, была слишком неприятным опытом.
Но в последнее время появилось много проектов, которые делают это проще, например:
OmniSharp предоставляет основу для intellisense и рефакторинга, наряду с плагинами vim, emacs, atom и sublime. Я на самом деле не использовал его, поэтому не знаю, насколько хорошо он работает, но выглядит многообещающе.
Yeoman ASP.NET MVC генераторы , помогают запустить новый проект MVC (возможно, существуют другие генераторы).
Пакет , альтернатива NuGet, где вы можете добавлять пакеты NuGet в свой проект из командной строки и обновлять файлы .csproj (хотя был инструмент командной строки NuGet, фактически обновление проектов для использования пакетов было частью IDE интеграция, а не инструменты командной строки).
Пакет подразумевает, что вы должны адаптировать свой исходный код к его использованию - поэтому, если вы сидите как один участник в команде и хотите использовать текстовый редактор для кодирования, а все остальные используют Visual Studio, вам придется убедить всех еще, чтобы адаптировать решение к вашим потребностям :(
Таким образом, вы должны иметь возможность приступить к работе, но для того, чтобы ваш набор инструментов заработал и работал эффективно, нужно выполнить еще больше работы.
источник
Уже нет:
http://www.omnisharp.net/
Я проверил это с subime3 и osx
Больше образцов на
http://blog.jonathanchannon.com/2014/11/12/csharp-first-class-citizen-sublime-text/
источник