Я развиваю в Visual Basic .Net с 2001 года, и мне это нравится, и я ненавижу это !!!
Порядок представления этих точек просто основан на порядке, в котором он пришел мне в голову ...
В vb.net с visual studio есть визуальный разрыв строки между каждым методом, свойством. Для многих людей это не очень хорошая причина отдавать предпочтение vb.net над c #, но я не понимаю, почему команда c # в Microsoft не внедрила его. Есть надстройка, которая рисует эту черту в c #, но еще раз спасибо Microsoft за команду ac # и команду visual basic, которые не общаются друг с другом.
В vb.net, когда вы создаете winform, у вас есть два комбинированных списка в Visual Studio вверху редактора, и вы можете автоматически генерировать событие при выборе события в правом комбинированном окне. Когда вы прикрепляете десятки событий каждый день, может быть очень обременительно не иметь этой функции. С c # у вас есть маленькая кнопка в верхней части сетки свойств, которая может генерировать события, но это не так быстро, как в vb.net. Более того, если вы присоединяете событие элемента управления в c # и удаляете элемент управления в форме, делегат, созданный в автоматически сгенерированном коде для обработки события, должен быть удален вручную. Еще раз спасибо Microsoft.
В vb.net, когда вы пытаетесь изменить метод, содержащий запрос linq, без изменения самого запроса, нет проблем, но в c # весь код метода блокируется. Если у вас много запросов linq или лямбда-выражений, функция редактирования и продолжения быстро станет старой доброй вещью. Хорошо, немного преувеличения ... но :)
В vb.net, когда вы создаете имя метода и нажимаете ввод, автоматически создается 'end sub'. В c # сделай сам. Хорошо, если у вас установлен resharper или devexpress, будет лучше, но почему все эти маленькие, но замечательные функции не были реализованы в c #.
В vb.net, когда у вас есть ошибки в вашем коде, ошибки автоматически отображаются, и когда вы исправляете их, эти ошибки удаляются из стека в режиме реального времени. В c # вы должны построить свой проект, чтобы понять, что вы успешно исправили или нет указанные ошибки. Почему команда C # не имеет возможности проверить в режиме реального времени ошибку, как в vb.net. С большим решением, никакая проверка ошибок в реальном времени не может быть очень хорошей оптимизацией производительности, но мне нравится видеть, как стопка ошибок исчезает, пока я ее исправляю.
Как упомянул другой человек, я думаю, что легче читать условия vb.net, если ... конец if, выберите case ... end select, но с помощью скобки рисования devexpress, забудьте про то, что я сказал.
В vb.net много визуальных ошибок в визуальной студии. Просто упомяну один из них в Visual Studio 2010, intellisens не фильтруют правильно перечисление, если у вас активирован режим «общий» вместо «все».
С vb.net вас воспринимают как глупого парня, потому что статически, более плохие программисты используют vb.net вместо c #, потому что c # труднее учиться и продвигать лучшую практику программирования.
Как уже говорилось, у программиста на c # больше шансов получить хорошую работу с большим количеством денег.
Во главе клиента, vb.net = парень, который программирует в своем подвале с большим количеством спагетти кода. c # = вау, ты очень умный Дело в том, что не потому, что вы программируете на c #, вы делаете хорошую программу, а статически, да.
Учитывая все эти моменты, я решил преобразовать весь свой код VB в C #. Я программирую со всеми лучшими практиками объектно-ориентированного проектирования, шаблонов проектирования, чистого кода со стандартами и строгим синтаксисом, и я могу программировать так в течение 50 лет, но с точки зрения сообщества, я не хороший программист. Я преобразую свой код в C # без других лучших практик, и я буду другим человеком; отличный парень, которого ты должен уважать ..... :( какая шутка ... !!! но это реальность.
