为什么不推荐在同一解决方案中混用VB.Net和C#?

当我注意到下面有一个好奇的评论时,我正在读这个问题 :

不确定问题是什么:你可以在一个解决方案中使用VB.NET和C#项目(虽然我不建议这样做)。

我这样做了很多,因为我们有传统的VB.Net代码,新代码是用C#编写的。 这真的不推荐吗? 为什么不?

除了在一个“解决方案”中增加两种语言的复杂性之外,没有任何理由可以避免这种情况。

在我看来,您的方案(使用旧产品,但添加新function)是在单个解决方案中使用这两种语言的正当理由。

不推荐它的唯一原因是一致性。 大多数开发人员在处理应用程序时更喜欢使用单一语言。 使用单一语言也意味着您的开发人员只需要知道一种语言而不是知道VB.NET和C#(即使两者非常相似)。

如果你需要混合传统的VB.NET和C#,没有理由不这样做。

这是“使用你可以使用的最好的工具”。 不建议项目中混合使用C#和VB(显然“它不会编译”的原因),但是如果您认为开发团队可以更快地运行并且更易于维护,那么继续在VB中编写旧代码是没有意义的时尚使用C#。

过去几个月我们一直在我的办公室这样做(在类似的遗留代码情况下)并且还没有遇到任何重大问题(超出由于上下文切换而可能失去的开发时间),并且我们从使用我们都觉得更舒服的语言。

有关任务切换的更多信息,请访 我真的觉得我们每天看到的好处是我们对C#的舒适程度超过偶尔不得不重新回到传统池中的成本。

这只是个人选择的问题。 如果您对这两种语言都感到满意,那么您肯定可以在同一解决方案中使用它们。

在解决方案中使用单一语言似乎很容易维护。 因此它是优选的。

在解决方案中混合代码可以快速实现真正的混乱,它从不清楚你从哪里调用什么方法,以保持它的美观。 在单独的解决方案中开发,它将使您的项目更容易跟踪,并确保您不会混淆项目中的语言

你为什么想这么做? 如果您有遗留代码要使用的内容,则将代码保存在自己的组件中,不要将其与新代码混合使用。 不建议这样做,因为它不会促进“清洁代码”。 它可以使您找到难以阅读和维护的解决方案。