例如，在下面的代码中，局部变量num的作用域应该只在else中，但这是一种糟糕的做法吗？
typedef enum
{
FIRST,
SECOND,
THIRD,
} numbers;
void fun(int check, numbers *num)
{
if (check)
{
..........
.......
}
else
{
numbers num;
............
}
}
我会说是的，绝对是糟糕的做法。当然，它会起作用，所以从编译器/程序的角度来看，这种方法没有本质上的错误。然而，随着项目变得越来越大、越来越复杂，保持这种做法肯定会导致调试阶段更加困难，可读性半模糊，文档更糟糕。如果你这样做，几个月后拿起复杂的软件，你会恨自己：(
软件中的命名是一个敏感的话题，每个开发人员都有自己的标准和个人偏好。我自己也试着写一些不言自明的代码。使用长的描述性易于理解的变量/函数名称是我的首选。
您可能会在各种代码标准(如SEI或Barr(中找到更多的原因来解释为什么要避免某些事情。
man gcc
-Wshadow每当局部变量或类型声明遮蔽另一个变量、参数、类型或类成员时(在C++中(，或每当内置函数时发出警告被遮蔽。请注意，在C++中，如果局部变量隐藏显式typedef，编译器会发出警告，但如果它隐藏结构/类/枚举，则不会发出警告。
名称完全匹配是不好的做法，然而，我经常看到并使用相同的名称，但类型具有大写字母：
void func(Person person) { };
类型和变量有完全不同的工作，您希望能够看到差异。此外，您希望IDE能够"；查找所有引用"；，或者跳到课堂上。有些框架也依赖于外壳来把事情做好，即使语言本身并不介意。
从纯语言的角度来看，随着程序变得越来越大，你会变得更加困惑，并且你开始尝试滚动或使用"查找"；或在IDE中跳转到。即使没有IDE问题，你也不会知道在任何给定的时间发生了什么，你可能会编辑错误的代码部分来修复其他地方的错误。
我想补充一点，在很多书中，我看到构造函数是这样写的：
private int x, y;
MyClass(int x, int y) {
this.x = x;
this.y = y;
}
我个人不喜欢这样，但这似乎是在两者之间的选择，或者更改私有变量名。微软喜欢加下划线。