将局部变量名称与 c 中的参数名称相同是一种不好的做法吗？

Question

例如，在下面的代码中，局部变量 num 的范围应该只在 else 内，但这是一种不好的做法吗？

typedef enum
{
   FIRST,
   SECOND,
   THIRD,
} numbers;

void fun(int check, numbers *num)
{
    if (check)
    {
    ..........
    .......
    }
    else
    {
        numbers num;
        ............
    }
}

Answer 1

人 gcc

-Wshadow 每当局部变量或类型声明遮蔽另一个变量、参数、类型或类成员（在 C++ 中）时，或每当内建函数被遮蔽时发出警告。 请注意，在 C++ 中，编译器会在局部变量遮蔽显式 typedef 时发出警告，但不会在遮蔽结构/类/枚举时发出警告。

Answer 2

名称完全匹配是不好的做法，但是，我经常看到并使用相同但类型具有大写字母的类型：

void func(Person person) { };

类型和变量有完全不同的工作，您希望能够看到差异。 此外，您希望 IDE 能够“查找所有引用”或跳转到该类。 一些框架也依赖于大小写，来把事情做好，即使语言本身并不介意。

从纯语言的角度来看，随着程序变大，您会变得更加困惑，并且您开始尝试在 IDE 中滚动或使用“查找”或“跳转到”。 即使没有 IDE 问题，您也不会知道在任何给定时间发生了什么，并且您最终可能会编辑错误的代码部分以修复其他地方的错误。

我想在很多书中补充一点，我看到构造函数是这样写的：

private int x, y;

MyClass(int x, int y) {
  this.x = x;
  this.y = y;
}

我个人不喜欢这样，但似乎是在这两者之间进行选择，或者更改私有变量名称。 微软喜欢加下划线。

Answer 3

我会说是的，绝对不好的做法。 当然，它会起作用，因此从编译器/程序的角度来看，这种方法本身没有任何问题。 然而，随着您的项目变得越来越大和越来越复杂，保持这种做法肯定会导致更难的调试阶段、半混淆的可读性和更糟糕的文档。 如果你这样做并在几个月后拿起你的复杂软件，你会讨厌自己:)

软件中的命名是一个敏感话题，每个开发人员都有自己的标准和个人偏好。 我自己尝试编写不言自明的代码。 使用易于理解的长描述性变量/函数名称是我的首选。

您可能会在各种代码标准（例如SEI或Barr ）中找到更多关于为什么要避免某些事情的原因。