嵌入式软件开发人员经常面临开发“好软件”或“好代码”的压力，问题是好代码的想法通常是主观的。我认为的好代码可能与你认为的好代码不同。开发人员经常考虑代码美学和代码风格，这可能会也可能不会产生好的代码。在这篇文章中，我们分享好的代码是什么样子的，以及它通常表现出来的特征。

好的代码是可读的

好的代码是人类可读的。作为一名开发人员，你应该能够阅读你的代码和你同事的代码并理解它们！虽然可读的代码看似显而易见，但是对于嵌入式软件开发人员来说，编写代码的难度令人难以置信。编写可读代码的关键是利用空白。

空白是代码周围的空白，如空格、制表符和换行符。开发人员通常认为空白是邪恶的，因为他们觉得聪明的开发人员尽可能使用最少的行。这是不正确的！优秀的开发人员使用尽可能多的空白来使他们的代码可读！

好的代码很简单

当代码简单时，它是可读的，并且不太可能有错误。当一个函数被编写或者被修改和维护时，bug可以被注入到这个函数中。函数越复杂，出错的可能性就越高。开发人员应该努力编写许多简单的功能，这些功能共同完成一个更突出、更复杂的功能。一个函数应该做一件事。

虽然保持代码简单很有意义，但在实践中很难做到。比如测量代码中每个函数的循环复杂度。循环复杂度是一种度量，它告诉开发者通过一个函数的路径数。已经证明十条或更少的路径被认为是简单的函数。除此之外，在维护期间存在或注入bug的统计概率会显著增加。

好的代码是可测试的

你通常可以识别出好的代码，因为它是可测试的代码！你经常会发现一系列的测试被自动执行来验证代码是否满足它的需求。可测试代码将表现出如下特征：

l 解耦硬件并利用依赖注入的托管依赖关系。

l 定义良好的接口，为程序的其余部分提供清晰的交互点。

l 它们很容易在主机上的自动化测试工具中执行。

开发人员可以用来确保他们拥有正确数量的测试用例的一种机制是利用循环复杂度测量！它们可以用来确保你开发了简单的功能，并且具有所需的最小数量的测试用例！由于循环复杂度测量通过一个函数的独立路径的数量，该数量也提供了测试该函数并覆盖所有路径所需的最小测试用例数量。可能仍然需要额外的测试用例来涵盖边界条件，但至少涵盖了所有路径！

测试并不能保证你的软件是高质量的，但是它可以提升软件的可靠性和质量。好的代码总是与一组好的测试相关联，这些测试有助于开发人员确保代码按照应有的方式运行。你很难找到不包含一套自动化测试用例的好代码。

结论

好的代码是可读的、简单的和可测试的。虽然可读确实需要定义或样式来确保开发人员在同一页面上，但简单和可测试则不需要。你可以度量你的代码以确定它是否简单和可测试。一旦你定义了可读的含义，你就可以使用静态分析或人工智能工具来确定它是否可读。

你可能会发现可以用来定义好代码的其他特征，例如模块化、可伸缩性等等；如果你可以调整你的过程来定义和度量它们，你会发现你可以始终如一地交付“好代码”。