为什么变量中的数据类型编码风格不好

Question

我是一个新团队。我对他们的编码指南感到震惊。

示例：

 strName
 iCount
 structRectangle
 listCustomers
 retVal (for the return value... that is really biting me... how someone can do this)

他们要求在变量之前使用参数编写数据类型，这样开发人员每次都知道变量的数据类型，而不会向上滚动到声明。

那是真的，但我的论点是，一个方法不应该超过30行（否则将代码放在另一个方法中），这适合于共同的24＆＃34;屏幕...

但我并不完全相信，因为.NET中有Action<T>, Dynamic, Func<T>之类的东西。这也迫使我采取同样的方式行动＆＃34; actionCustomers＆＃34;对于持有方法的代表获取客户列表。

您可以给我什么建议作为替代方案，例如＆＃34; actionCustomers＆＃34;哪个会让团队的论点无用？

Answer 1

我建议您采用您编码的团队的编码风格。他们采用自己的风格来处理自己的系统性问题。除非你能够判断他们的代码（你似乎不是这样）或者你可以在代码风格上诉诸更高的权威（你的帖子似乎不太可能），那么，如果你想保住你的工作并证明你和＃ 39;作为团队合作者，你需要遵守你已经给予的规则。

  

为什么变量中的数据类型编码风格不好？

不是。一种名为Systems Hungarian Notation的相对古老的形式实际上编码了这种类型，由于很多原因而受到很多批评，包括冗余，不一致和可读性差。但那不是你正在处理的事情。我有时会发现在我的对象名称中包含数据类型是有帮助的，因为我还没有完全决定我要使用哪个容器（list，no，set，no，dict ......并且通常按顺序排列。）

Answer 2

当您不使用IDE时，此编码样式非常有用。

我经常使用Notepad ++打开旧的代码文件（只是为了阅读并转换为更新的代码，无需打开大型项目来读取单个文件）而且没有这种编码风格，每次看到变量时，我都要在文档中搜索其名称只是为了找出它的类型。这伤害了我的时间安排A LOT。

长话短说：你可能不喜欢旧学校的方法，但它们存在是因为人们需要它们。你永远不会知道有一天你想要它。

Answer 3

  

将函数类型编码到名称中（所谓的匈牙利语   符号）是脑损伤 - 编译器无论如何都知道类型   检查那些，它只会让程序员感到困惑。

Linus Thorvalds ，Linux内核编码样式

我真的很喜欢这句话。