Каковы Преимущества/Недостатки Использования И VB.Net и C# На Рабочем месте?

Нам, вероятно, следует надеть наши очки реальности для этого обсуждения. Здесь происходит не просто Syntactic Sugar.

Вы обнаружите, что можете очень быстро написать код на Visual Basic.NET. Во многом это связано с некоторыми функциями, которые C # еще не предоставляет: а именно с пространством имен My, которое предоставляет множество функций, которые разработчикам C # приходится часто кодировать вручную. (И это чертовски досадно, если вы спросите меня.)

Я кодирую на обоих языках каждый день. Кодировать обработчики событий для форм в Visual Basic совсем несложно, и ОЧЕНЬ очевидно, какие методы какие события обрабатывают. В C # это не всегда так ясно. С другой стороны, вы не всегда можете быть настолько откровенными в Visual Basic, как вы хотите, потому что Visual Basic делает большую часть работы за вас. У C # есть то преимущество, что он просто убирает с вашего пути и позволяет вам заняться гайками и болтами. Довольно часто это очень освобождает.

VB позволяет вам вызывать статические / общие методы для экземпляра объекта. C # не будет. Вы узнаете это на собственном горьком опыте, когда попытаетесь перенести свой код. C # будет жаловаться на недоступный код; VB все равно, так или иначе.

Но под капотом, когда вы сразу перейдете к делу, все это .NET. Все это компилируется в MSIL. Будут небольшие отличия. Visual Basic, например, не заботится о чувствительности к регистру имен, в отличие от C #. И большая проблема заключается в том, что CLR тоже. Вы поймете это, когда попытаетесь использовать отражение. Означает ли это, что вам не следует использовать VB? Нет. Просто убедитесь, что вы упорядочиваете вещи - особенно ваши пространства имен. (Пространство имен «My» и пространство имен «my» - это два совершенно разных пространства имен для C # и CLR, но они одинаковы для VB.)

Выберите язык, который делает вашу работу наиболее продуктивной, сокращает время нарастания и затраты на техническое обслуживание. Вы можете обнаружить, что это означает работу с обоими языками. (Мы делаем!)

РЕДАКТИРОВАТЬ В АДРЕС OP'S EDIT:

• Инструменты рефакторинга доступны для обоих языков.

• Инструменты автоматизированного модульного тестирования одинаково применимы.

• Сторонние элементы управления будут доступны для обоих языков. потому что они скомпилированы до MSIL.

• Что касается инструментов повышения производительности IDE, то единственное, что есть в C # на данный момент, чего нет в VB, - это StyleCop. Это может скоро измениться (и я надеюсь, что это произойдет), но я не Я не считаю это препятствием для любого воображения.

Я бы сказал, что, учитывая, что есть «некоторые разработчики VB.NET и некоторые разработчики C #», действительно очень мало пользы от принуждения всех использовать один язык. Откровенно говоря, даже разработчик VB.NET, который никогда не изучал C #, должен уметь читать код C #, имея лишь краткое введение в синтаксис, при условии, что он / она имеет разумное понимание .NET framework; и разработчик C # должен иметь возможность делать то же самое с VB.NET.

(я должен также добавить: это предполагает, что каждый имеет доступ к среде разработки, в которой языки .NET могут гармонично сосуществовать - например, VS2005, VS2008 и т. Д., В отличие от одного из Express Editions, который, насколько мне известно, не допускает многоязычных решений.)

C # и VB.net одинаковы, но имеют другой синтаксис. Вы можете легко конвертировать из C # в VB.net и обратно. VB.net имеет несколько дополнительных преимуществ, которых нет в C #, например встроенный XML.

В большинстве мест есть C #, потому что это более популярный язык.

Я начинал как разработчик VB, поэтому, естественно, я перешел на VB.Net, когда впервые работал с .Net. Фактически, мое первое приложение .Net тоже было создано на VB.Net. Но я попробовал C #, и через несколько недель он мне понравился.

Я сделал часть этого приложения на C # (некоторые библиотеки), и мне это не повредило. Теперь, хотя я ненавижу возвращаться к старому коду VB.Net и работать над ним. Я действительно хотел бы как-то изменить все это на C #.

Этого не произойдет.

Итак, то, что я говорю вам, не имеет значения, какой язык вы выберете (VB / C #), придерживайтесь этого. Не занимайтесь разработкой смешанного языка, если у вас нет веской причины, о которой я пока не могу придумать :)

Преимущество стандартизации на одном языке заключается в что в основном каждому нужно будет учиться на половину меньше. Я думаю, что лучше потратить время на изучение большего количества функций .NET на одном языке, чем на изучение 1/2 функций на обоих.

Что касается найма,

Это личный опыт, смешанный с знаниями на рабочем месте:

1. VB.NET может быть немного более гибким по сравнению с C #, потому что здесь нет комитета по стандартам (кроме тех, которые могут существовать в Microsoft
2. Большая часть возможностей Google для взлома кода выполняется на C #, и большинство лучших справочников предоставляют образцы кода только на C #.
3. VB.NET запятнан историей того, что VB был доступен для даже самый неспособный из разработчиков. Это несправедливо, imho, потому что VB.NET - гораздо более «настоящий» язык. Но зараза не скоро исчезнет, ​​и "настоящая" программисты до сих пор в целом его презирают.

Что касается реальной жизни - я кодирую в свое время на C # и VB.NET на работе. Я считаю, что, поскольку большая часть кода, который пишется для .NET, представляет собой вызовы объектов фреймворка, различия на самом деле довольно малы. Если вы можете объявлять переменные на обоих языках, вы на 80% будете переносимы. Если вы понимаете структуру, синтаксис языков является небольшим препятствием.

РЕДАКТИРОВАТЬ , чтобы напрямую ответить на ваш вопрос: Мы с радостью используем оба (хотя в основном VB.NET) и никогда не сталкивались с какими-либо проблемами. Мы используем Visual Studio, которая позволяет нам довольно свободно смешивать файлы / сборки кода. Я бы посоветовал вам не ограничиваться одним языком - я думаю, что некоторое разнообразие полезно для мозга.

Я считаю, что, поскольку большая часть кода, который пишется для .NET, представляет собой вызовы объектов фреймворка, различия на самом деле весьма незначительны. Если вы можете объявлять переменные на обоих языках, вы на 80% будете переносимы. Если вы понимаете структуру, синтаксис языков является небольшим препятствием.

РЕДАКТИРОВАТЬ , чтобы напрямую ответить на ваш вопрос: мы с радостью используем оба (хотя в основном VB.NET) и никогда не испытывали никаких проблем. Мы используем Visual Studio, которая позволяет нам довольно свободно смешивать файлы / сборки кода. Я бы посоветовал вам не ограничиваться одним языком - я думаю, что некоторое разнообразие полезно для мозга.

Я считаю, что, поскольку большая часть кода, который пишется для .NET, представляет собой вызовы объектов фреймворка, различия на самом деле весьма незначительны. Если вы можете объявлять переменные на обоих языках, вы на 80% будете переносимы. Если вы понимаете структуру, синтаксис языков является небольшим препятствием.

РЕДАКТИРОВАТЬ , чтобы напрямую ответить на ваш вопрос: Мы с радостью используем оба (хотя в основном VB.NET) и никогда не сталкивались с какими-либо проблемами. Мы используем Visual Studio, которая позволяет нам довольно свободно смешивать файлы / сборки кода. Я бы посоветовал вам не ограничиваться одним языком - я думаю, что некоторое разнообразие полезно для мозга.

Если вы понимаете структуру, синтаксис языков является небольшим препятствием.

РЕДАКТИРОВАТЬ , чтобы напрямую ответить на ваш вопрос: мы с радостью используем оба (хотя в основном VB.NET) и никогда не испытывали никаких проблем. Мы используем Visual Studio, которая позволяет нам довольно свободно смешивать файлы / сборки кода. Я бы посоветовал вам не ограничиваться одним языком - я думаю, что некоторое разнообразие полезно для мозга.

Если вы понимаете структуру, синтаксис языков является небольшим препятствием.

РЕДАКТИРОВАТЬ , чтобы напрямую ответить на ваш вопрос: Мы с радостью используем оба (хотя в основном VB.NET) и никогда не сталкивались с какими-либо проблемами. Мы используем Visual Studio, которая позволяет нам довольно свободно смешивать файлы / сборки кода. Я бы посоветовал вам не ограничиваться одним языком - я думаю, что некоторое разнообразие полезно для мозга.

Немного проследив за вашим вопросом и отметив ваши правки, я задаюсь вопросом, не ловите ли вы немного ...

В любом случае, я думаю, что довольно очевидно, что по крайней мере, последние сторонние инструменты отдают предпочтение C #. Я, как и другие респонденты, использую VB для работы и предпочитаю C # для других разработок. Я определенно заметил, что документация для многих сторонних надстроек / надстроек, а в некоторых случаях и самих продуктов отдает предпочтение C #. ReSharper, несмотря на то, что 4.5 имеет лучшую поддержку VB, все же гораздо более всеобъемлющий при использовании C #. А другие фреймворки, такие как Fluent NHibernate, вообще не поддерживают VB. Так что в отношении инструментов, особенно когда речь идет о новинках, я считаю, что C # выигрывает. Не говоря уже о том, что C # получил несколько новых функций в версии 3.0, которые не будут доступны до тех пор, пока VB 10 не сделает широкий выпуск.

Я все еще полностью согласен с остальными; если вы можете сделать это на C #, вы можете сделать это на VB. В конце концов, это все тот же CLR.

Мое рабочее место традиционно было магазином VB.Net, но пару лет назад было принято решение перейти на C #. Это произошло в основном потому, что разработчики VB либо ушли, либо перешли на другие должности, и большинство новых сотрудников предпочли C #. У нас все еще есть большая база устаревшего кода VB.Net, но все новые разработки ведутся на C #.

Я не думаю, что есть серьезная техническая причина для выбора одного языка над другим, поскольку они довольно эквивалентны по функциональности, но я действительно чувствую, что есть несколько веских причин для выбора одного типа разработчика над другим. Хотя я считаю, что VB и C # равны, существует досадное мнение, что разработчики на C # лучше, чем разработчики на VB. Хотя этому есть какое-то оправдание, оно преувеличено. (Это было более применимо во времена C ++ / VB.) Тем не менее, восприятие существует. Это заставляет некоторых талантливых разработчиков избегать и критиковать VB (хотя обычно они делают это по незнанию). Я действительно думаю, что труднее нанять разработчиков в магазин VB, чем наоборот, потому что разработчик C # часто отказывается использовать VB, но разработчики VB обычно не возражают против использования C #. У выбора C # перед VB есть один существенный недостаток: разработчикам на C # обычно платят больше.

По моему опыту, лучшие разработчики приветствуют использование обоих языков. Чем больше языков вы знаете, тем лучше.

но разработчики VB обычно не возражают против использования C #. У выбора C # перед VB есть один существенный недостаток: разработчикам на C # обычно платят больше.

По моему опыту, лучшие разработчики приветствуют использование обоих языков. Чем больше языков вы знаете, тем лучше.

но разработчики VB обычно не возражают против использования C #. У выбора C # перед VB есть один существенный недостаток: разработчикам на C # обычно платят больше.

По моему опыту, лучшие разработчики приветствуют использование обоих языков. Чем больше языков вы знаете, тем лучше.

Не поддавайтесь на «большинство примеров / книг написано для C #». Разработка того, как применить пример C # к VB.NET, тривиальна - вам будет труднее понять, что пытается сделать придурок, написавший этот пример / книгу, и в чем заключается их ужасное (не) соглашение о кодировании. чем вы мысленно переключите синтаксис C # на синтаксис VB.

Также я бы посоветовал не беспокоиться о том, нанимаете ли вы программистов C # или VB.NET: если они хоть немного хороши , то они выиграли Нет проблем с чтением / записью на обоих языках.

Мы используем и то, и другое, и после некоторого сопротивления со стороны некоторых (раньше мы использовали C ++) все уладилось. Как я и предполагал, самым сложным для нашей команды было (и, вероятно, остается) переход с MFC на .NET, не язык, используемый для доступа к библиотекам.

FWIW наше основное разделение - это VB.NET для кода пользовательского интерфейса и C # для кода серверной части / базы данных / вычислений.