Programming languages 让代码持久的技巧

有时我真的想知道我的代码是否是“可持久的”。我尽一切努力让它“持久”，避免在写作或解决问题时依赖事物。像“编程技巧”和假设之类的东西，如果我重写或添加代码，这些东西将来可能会改变。有时候很容易，有时候很难，但这都是作为一个程序员的一部分，让东西更好、更快、更容易地工作

话虽如此，您能否从您的个人经验中推荐一些技巧，以便在HLL中编写更好的持久代码？应该避免什么，拥抱什么

---

谢谢大家!

避免你最近读到和想到的任何事情

这是一个有趣的语言特征，设计模式等等。 ，我想这对我有帮助 降低我的代码复杂性

---

出于某种原因，这以后总是会咬到我。最好将其放在辅助项目中，一旦证明是一个好主意，就在生产代码中使用，而不是仅仅看起来像一个。

看看坚实的原则。比如说

对我来说，这很像发送电子邮件或任何信件

代码“完成”后，我会重新阅读，并在脑海中浏览所有场景

之后是测试

我见过的最好的开发人员都能通读代码，把所有基本的东西都搞定。然后通过单元测试解决更多的问题

---

还有，评论。我认为在汇编编程中，他们谈论“只写一次，从不读”代码。如果不注释汇编代码，则无法对其进行维护。HLL需要有用的注释。

在我看来，让程序进化并没有什么错。曾经有一段时间，我总是想预见每一个可能的变化，但我知道，大多数时候，这是不可能的。然而，抽象比实现细节存在的时间更长。因此，我的建议是将应用程序尽可能多地分离为许多组件（类和函数），接口尽可能抽象（隐藏实现细节）。这样，当某些东西不得不改变时（不可避免地会发生），改变很可能被隔离在源代码的一小部分中。

有时，让代码持久的关键不是尝试在前面构建一些永恒的杰作，而只是继续做一些真正有用的东西。甚至可以接受预先做出某些假设，只要它们都有明确的文档记录，可能是通过注释、断言或单元测试。这提醒了我：编写大量的单元测试，以便随着代码的不断发展，不断测试关于其行为的假设

不要以为你写的任何东西都会随着年龄的增长而保持不变。依靠不断的重构，并集中精力使之尽可能简单。

Bit rot

在编译旧项目时，我最常遇到的问题是

• 缺少依赖项-最好列出您所依赖的任何库，包括从中获取的URL。您的包含路径可能与5年前不同
• 编译器更改-这些通常不太麻烦，通常可以通过C/C中的#define来修复++
• 数据大小的变化——当从16位移动到32位时，这是一个令人讨厌的变化。尽量不要假设变量的大小
• 神秘的构建过程——对于某些项目，构建资源、库等时可能会有一些模糊的构建步骤。请确保这些步骤都有很好的文档记录
• 过于聪明的代码——我见过这样的代码，它假设机器的内存小于X兆字节，因此使用指针的顶部位来保存数据。别做那种事
• 错误检查-当事情发生故障时，良好的错误检查将帮助您更快地找出原因

---

我试着记住以下几点：
• 代码可能比任何人预期的都要长，或者比任何人预期的都要短（我曾经离开过一个项目，他们完全用另一种语言重新编写了我的应用程序——但是新开发人员很高兴，因为我留下了大量的评论！）
• 如果你回到你的代码，你会发现它是可怕的。总是这样。在你忘记它是如何工作之前发表评论
• 意识到其他人会看你的代码，认为它是垃圾，因为你没有很好地遵循面向对象编程，然后在你身上重构整个东西。然后，重构程序的人会来向你寻求帮助，因为它不起作用，你会发现，为了可靠原则而重新编写程序的人完全删除了应用程序的所有功能，这就是你首先破坏可靠原则的全部原因（对不起，这是一个咆哮…）

---

无论哪种方式，我都会添加大量的评论。注释将解决上述所有问题，并使代码持续更长时间。我建议在冗长方面出错。
我发现以下提示很有用：
• 使用有意义的变量/成员/类/函数名，即使键入时手指受伤

• 准确、简洁地注释每个类和函数、过程（除非是样板文件，例如set/get方法）。如果这不可能或不容易，那么您的函数/子函数可能太复杂

• 保持功能/程序小-5-10行。这有助于使它们易于验证、测试、调试、记录和使用

• 当你检查你的代码时（通常是在bug修复或进一步开发的过程中），如果你觉得有什么不对劲，记录问题或修复它。通常，稍后您会发现一个bug，并且它会与之相关，或者您将以违反某些假设的方式使用代码，文档将对您有所帮助

• 将整个过程中所做的更改记录在工作日志中