我没有考虑这一点——我对 C# 和 VB 很满意,但两者都不是专家。但是,由于我们正在将 C# 作为标准,因此我团队中的一些人表示打算这样做。
12 回答
地狱没有。纯粹是浪费时间。
仅当语言启用了其他语言中不可用的功能时,我才会使用 VB over C#(或 C# over VB)。
例如,在 VB 中对 COM 互操作对象进行后期绑定调用比在 C# 中要容易得多(尽管这在 C# 4.0 中会有所改变)。
话虽如此,我会坚持使用您的团队使用的语言,或者您喜欢的语言(如果可以的话)。
听起来像是灾难的秘诀,或者至少是无数个没有实际收获的 WTF 时刻。
无论语言如何,.net 程序集都是兼容的(无论如何最后都是 IL),因此没有任何好处。
我会在 C# 中感到舒服,这不应该花太长时间。用VB编写然后转换只是浪费时间IMO。
此外,如果他们不熟悉该语言,需要阅读一些 C# 代码时会发生什么?
我不会这样做。我会开始使用 C#。
从程序员的意图到任何一种语言的源代码都比从一种语言到另一种语言更容易。
您应该使用您打算使用的语言。
还有其他未提及的注意事项。值得注意的是,如果您使用自动化软件将 VB 代码转换为 C#,您可以指望存在大量转换问题。不要让任何人引诱您对转换所需的工作量产生错误的信心:VB.NET 和 C# 之间的距离比您想象的要大。从一种语言转换到另一种语言会给您的日程安排带来大量工作,并且可能会以意想不到的方式重写您的部分代码。
从做过的人那里拿走。
如果您没有真正令人信服的理由将现有代码移植到 C#,那么将其保留在该语言中并简单地用 C# 编写更新的代码可能更具成本效益。此外,如果您的开发人员对新语言的更改并不完全满意,您可能不得不处理他们中的一些人可能会感到的不适。不管我们同意与否,有些员工可能对此感觉非常强烈以至于他们会离开,当你不得不更换他们时,这将产生巨大的成本。
只是我的两分钱。
我会反对这种做法。
如果打算将 C# 作为标准,为什么还要等待开始使用它?我还发现很难想象转换永远不会发生。当谈到关键时间并且在转换和添加/修复功能之间进行选择时,转换可能是第一个去的。
在它的脉络中,这是一个人的问题。为什么首先要迁移到 C#?你确定每个人都同意这是标准吗?
作为 VB 的忠实粉丝,我会说这本质上是一个非常糟糕的主意。如果正在使用 C#,请用 C# 编写。
实际上,.NET 可以很容易地在一个项目中混合多种语言,只要它被分成多个程序集。先验没有任何东西反对这种做法。但是,一旦将一种语言作为项目中的标准建立,所有开发人员都应该坚持下去。
转换是浪费时间和金钱,因为不存在自动、无错误的转换工具(我知道),所以它总是涉及一些手动后处理。这不应该是可以接受的。此外,在您了解 VB 的情况下学习 C# 非常简单,不应造成抵消转换代码成本的障碍。
我不会推荐它。恕我直言,这只会使工作加倍。
如果您需要两个不同的应用程序相互通信,我建议使用 Web 服务或某种开放格式 (XML) 来传输数据。这样您就可以同时保留 VB 和 C# 应用程序。
我更喜欢 C#,但如果大多数开发人员都是 VB.NET 人员,你为什么要转向 C#?这将是一条学习曲线,不会提高生产力。此外,我假设大多数是 VB.NET 人员,如果做得不好,那么您将面临一场巨大的公关噩梦。
我们采用的方法是 VB.NET 人员在 VB.NET 中开发,C# 人员在 C# 中开发,我们很幸运拥有定义良好的模块,这些模块可以在 IL 级别进行交互而不会出现任何问题。
不,不!拒绝吧。
我的老板曾经建议过,因为许多工程师(注意..结构工程师,而不是程序员)都知道 VB6 并且对 VB 很熟悉,但他想使用 C# 作为标准。
我立刻想给他装上一些东西,让他有点理智,但我克制住了自己,平静地和他讨论了选择。我终于能够说服他——虽然 .NET 是 .NET——带有 VB6 片段的 VB.NET 与 C#.NET 是不一样的,用户肯定会为了“易于编码”而挤进去。
有足够的差异——至少对我们来说——C# 的学习曲线值得花时间,而不是从一种 .NET 语言转换为另一种语言的编码曲线。