У меня есть команда с людьми, которые довольно удобны в С#, но у нас есть требование написать проект на VB.net. Как трудно было бы думать в С# и на лету конвертировать в VB? Это выполнимо?
Не могли бы вы перечислить проблемы, с которыми мы можем столкнуться?
Я слышал, что у VB.net нет закрытий. Это все еще верно для .net 3.5?
Если вы приближаетесь к VB.Net с мышлением С#, лучше всего установить следующие параметры в проекте
Это существенно устраняет позднюю связывающую семантику VB.Net и заставляет ее быть строго типизированным языком. Это приблизит его к семантике семантики С# (по-прежнему не точно).
У VB.Net есть поддержка Lambda Expression (и, следовательно, Closure), начиная с версии Visual Studio 2008/.Net Framework 3.5. Не выражение, а не утверждение. Заявление lambdas не поддерживается до VS2010/.Net Framework 4.0. Хотя вы можете использовать компилятор 4.0 для downtarget 2.0 frameworks.
Поскольку С# и VB.NET используют ту же структуру и компилируют с очень похожим IL-кодом, у вас есть много бесплатно. Написание базового синтаксиса не так сложно.
Синтаксис С# больше нацелен на то, чтобы показать, что происходит, в то время как синтаксис VB часто скрывает некоторые детали, поэтому программист на С# уже знаком с некоторыми понятиями, которые, возможно, вообще не очевидны для программиста VB. В некотором роде обучение С# - лучший способ узнать, как работает VB, чем изучать сам VB...
Я часто отвечаю на вопросы VB.NET на разных форумах, в основном основанные на моем знании С#, и я до сих пор не написал ничего более, чем короткие тестовые программы в VB.NET самостоятельно.
В VB есть, конечно, некоторые причуды. Например, как оператор /, который всегда преобразует оба операнда в double или операнд =, который использует специальный код сравнения VB, а не сравнение, указанное для оператора равенства в классах .NET.
Одна область, которую VB.NET пытается попробовать и скрыть, работает с событиями; другие кратко коснулись некоторых различий, но здесь немного больше о них:
VB.NET предоставляет ключевое слово WithEvents для полей, которые вызывают события. Если поле объявлено WithEvents, вы можете добавить Handles field.Event в конец метода, подпись которого совместима с событием; этот метод будет автоматически быть делегатом события без необходимости вручную AddHandler и RemoveHandler (+= и -=).
Private WithEvents SomeField
Public Sub SomeField_SomeEvent(sender as Object, e as EventArgs) Handles SomeField.SomeEvent
Console.Writeline("SomeEvent occured")
End Sub
Сообщения о событиях и событиях повышения упрощены. VB.NET не требует, чтобы вы проверяли, является ли событие нулевым до уведомления слушателей:
Public event SomeEvent as EventHandler(of SomeEventArg)
Public Sub SomeMethod()
RaiseEvent SomeEvent(Me, new EventArgs)
End Sub
Одна "скрытая" функция событий в VB.NET обращается к базовому MulticastDelegate, чтобы сделать что-то вроде GetInvocationList() Примечание: событие имеет имя SomeEvent и код для доступа multicastdelegate вызывает невидимое поле с именем SomeEventEvent:
Public event SomeEvent as EventHandler(of SomeEventArg)
Public Sub SomeMethod()
// Note that SomeEvent MulticastDelegate is accessed by appending
// another "Event" to the end, this sample is redundant but accurate.
// If the event was named ListChanged then it would be ListChangedEvent
dim invocationList = SomeEventEvent.GetInvocationList()
End Sub
Одна из самых больших проблем, которые я обнаружил, - очевидная многословность VB. Он имеет все эти ключевые слова, такие как MustInherit, NotInheritable, MustOverride и т.д., Где С# имеет такие вещи, как sealed, abstract и virtual. Вы должны иметь End для всех (End Sub, End Function, End While, End Namespace, End Class и т.д.). И вы должны явно отмечать свойства только для чтения с помощью ключевого слова ReadOnly; просто упущение сеттера не будет летать. Также помня AndAlso и OrElse вместо более интуитивного (но не короткого замыкания) And и Or, а также таких, как Is Nothing и IsNot Nothing вместо == null или != null.
Ни одна из этих проблем не является проблемой для языка, но если вы привыкли к относительной простоте С#, код VB может выглядеть как много лишнего материала для вас.
В журнале Visual Studio появились полезные статьи в январе 2008 года.
Вас также может заинтересовать вопрос "что разрешено в VB, которое запрещено на С# (или наоборот)"
Точка, которая здесь не упоминалась, заключается в том, что инициализаторы полей в С# выполняются перед базовым конструктором, а те, что находятся в VB, выполняются между базовым конструктором и первым "реальным" выражением конструктора производного класса (после базы -конструкторный вызов, если таковой имеется). Это позволяет инициализаторам поля в производном классе использовать члены базового класса (которые, возможно, были инициализированы с использованием параметров, переданных конструктору), а также означает, что если конструктор базового класса объекта проходит где-либо раньше он возвращается, частично сконструированный объект может быть использован до того, как все инициализаторы полей будут запущены. В С# все инициализаторы полей будут выполняться до того, как базовый конструктор начнет выполнение, но ни один из инициализаторов поля не сможет использовать частично построенный объект.
PS - если кто-либо из людей Microsoft, стоящих за С#, читает это, возникла бы какая-либо особая трудность при добавлении контекстно-зависимого ключевого слова для объявлений в поле, чтобы указать, должны ли они обрабатываться до или после базового конструктора или, возможно, иметь их выполняемый каким-то специальным методом, который может быть вызван из конструктора, который может быть обернут в блок try-finally (поэтому любые выделенные таким образом IDisposables могут быть очищены), а также может использовать параметры, переданные конструктору?
Я считаю, что это удобная статья, подчеркивающая различия. Я программист vb.net, и это помогает мне понять код С#, поэтому я уверен, что он будет работать другим способом!
http://www.codeproject.com/KB/dotnet/vbnet_c__difference.aspx
Как и любой язык (человек или компьютер), вы сначала научитесь "переводить в свою голову", тогда вы начинаете "думать" на другом языке.
Чем быстрее ваша команда сможет совершить этот прыжок, тем лучше. Итак, сделайте это так же, как эксперты скажут вам, чтобы изучить человеческий язык: примеры в реальном мире и погружение.
Есть несколько программ для преобразования С# в VB.NET, доступных в Интернете, поэтому начните с написания команды на С#, конвертируйте в VB.NET и очистите ее. (Утилиты преобразования различаются по качеству и имеют некоторые ограничения, особенно с новыми языковыми функциями.)
Как только они получат зависание основной "грамматики", оставьте их в VB.NET 100%.
Я использую как каждый день, часто в разных окнах кода одновременно, так и без проблем переключение контекста или выполнение "правильной вещи" в каждом.
Кроме того, о чем уже говорил Джаред, у вас не должно быть никаких проблем при этом. Единственный источник раздражения - это странные дефолты. НАПРИМЕР. Знаете ли вы, что проекты VB.NET, по умолчанию скрывают ссылки node в explorer? (вам нужно выбрать ShowAllFiles, чтобы увидеть его).
Я не думаю, что это было бы слишком сложно. VB.NET и С# - это языки, которые близки друг к другу, только синтаксис действительно отличается. Конечно, для вашей команды потребуется некоторое время, чтобы привыкнуть к новому языку, но я не думаю, что у вас возникнут большие проблемы.
О, и у VB.NET есть замыкания. Он пропускает несколько других функций из С#, таких как ключевое слово yield, multi-statement lambdas и свойства auto, но ничего очень критического.
Я думаю, что С# для VB.NET не будет слишком болезненным, это всего лишь случай изучения нового синтаксиса. В текущих версиях возможности обоих языков довольно близки.
Другим способом (VB.NET на С#) может быть сложнее, потому что люди могут использоваться для использования пространства имен "My" и других вещей, которые могут быть добавлены, чтобы заставить разработчиков VB6 чувствовать себя как дома.
Есть некоторые тонкие отличия, которые вам придется соблюдать. Например, у VB.Net нет понятия короткого замыкания оператора if (я был исправлен, очевидно, что он это делает). Если это всего лишь краткосрочный проект, у вас, вероятно, не будет проблемы, но на разных языках есть разные подходы к решению одной и той же проблемы. Примером этого являются программисты Python, говорящие о том, как делать вещи в "питоническом" способе. Они рассказывают об этой концепции в книге Dreaming in Code, где Java-программисты пытались программировать Java, используя синтаксис python. Это приводит к тому, чтобы решить проблему до конца. Это произойдет с С# и VB.Net? Трудно сказать, что они используют базовую работу фрейма, поэтому различия не будут огромными, но это все равно поможет попытаться научиться использовать VB.NET так, как она была предназначена.
Изменить: очевидно, что это имеет понятие короткого замыкания, но это не делает это по умолчанию, где С#. Это еще раз доказывает смысл изучения того, как языковые функции могут быть полезными в долгосрочной перспективе.
Один из вариантов, если вам не нравится писать код vb.net, - это написать свой проект на С#, скомпилировать его и использовать Reflector, чтобы посмотреть, как выглядит эквивалент vb.net. В любом случае, все это сводится к MSIL!