过时的编码实践

当我编写代码时,我有时会想知道我是以最好的方式做事还是按照一直以来的方式做事.我正在做的事情是否有意义？

例如,在函数顶部声明所有变量.如果我尝试在我开始使用它的地方宣布它两次或更低,我的IDE会在设计时向我发出警告 - 那么最重要的是什么？似乎将变量声明在它们被使用的块的正上方更有意义.

另一个是匈牙利表示法.我讨厌所有与特定对象相关的变量都散布在我的智能感知中.

随着框架和IDE的现代化进步,是否有一些不再适用的编码实践和其他现在可能完全错误的编码实践？

1> Jon Skeet..：

---

不要将变量声明在它们将被使用的块之上 - 在第一次使用时,在可用的最窄范围内声明它们,假设在您的语言中是可行的.

匈牙利表示法将取决于您的语言/平台的约定.它还取决于您使用的匈牙利品种 - 合理的(我仍然不喜欢)或只重申已有类型信息的版本.

需要注意的一件事是:当你学习一门新语言时,请确保你同时使用它的成语,特别是命名约定.这将有助于您的代码适应新语言,而不是旧的(可能不相关的)代码.我发现它也有助于我思考新语言,而不是反对它.

但是,肯定值得定期重新编写编码实践.如果你无法确定为什么这是一个好主意,试试一段时间没有它......

---

+1不是因为它的John Skeet(无论是谁,pshhhha)但是因为第3段是真正的宝石,其余的是通常的东西.

---

(我意识到你可能在开玩笑,但这是一个真正的问题.)我真的希望事实并非如此.如果人们根据名字而不是质量来支持我,我怎么能被鼓励改善呢？

2> Brian R. Bon..：

---

意外分配保护:

在一些较新的语言(如C#)中不需要将左值放在右侧.

在C#中,以下内容无法编译:

if (variable = 0)

所以在C#中没有必要这样做:

if (0 == variable)

这种做法在C/C++程序中非常常见,以避免意外分配,这些分配是为了进行比较.

---

多个返回点:

禁止多个返回点的实施主要是因为您不想忘记删除变量.

相反,如果您只使用RAII,则无需担心.

免责声明:仍然有充分的理由尽量减少多个返回点,有时只有一个返回点很有用.

---

头文件

在大多数现代语言中,您不会将代码分离为声明和定义.

---

C++定义了多个头文件包含

在C++中,您经常使用:

#ifdef _MYFILE_H_
#define _MYFILE_H_

//code here

#endif

这有时会导致类似下面的事情:

#ifdef _MYFILE_H_
#define _WRONGNAME_H_

//code here

#endif

如果您的编译器支持它,更好的方法是:

#pragma once

---

C变量声明

使用C,您必须在代码块的顶部声明所有变量.即使是更高版本的C也不需要这个,但人们仍然这样做.

---

匈牙利表示法:(阅读,包含一些独特的信息)

匈牙利表示法仍然可以很好.但我并不是指那种匈牙利符号.

在C之前有这样的事情是非常重要的:

int iX = 5;
char szX[1024];
strcpy(szX, "5");

因为您可以完全键入不安全的函数,例如:

printf("%i", iX);

现在,如果我要调用字符串x,我的程序就会崩溃.

当然,对此的修复是仅使用类型安全函数.因此,只要你这样做,你就不需要匈牙利语.

但乔尔在他看来仍然是一个好主意.

3> Neil N..：

---

我过去常常将所有行号分开10,以100或1000的间隔开始每个逻辑上独立的代码片段

10 Print "Hello"
20 Gosub 100
30 'Peeks and Pokes

出于显而易见的原因,我不再像这样编码.

---

你现在用的间隔是多少？

4> Mr. Shiny an..：

---

短标识符:许多老式编码员使用简短,神秘的标识符.简洁是一种有用的美德,但考虑到一个好的IDE具有自动完成功能,描述性名称远比易于键入的名称好.

5> Mr. Shiny an..：

---

短线:有人坚持80列文字.我们其他人都有真正的监视器,不介意一条线是否长于80个字符.它可以提高可读性以获得更长的线条.

---

哇,人们还在打码？我的意思是,除了文章或博客文章的片段之外,我不认为我实际上已经打印了超过十年的实际源代码.

---

FFS在其输出上获得一个带有自动换行的编辑器.你没有在文字处理器的每一行结束时返回.