不考虑外部文档的可用性，由于硬拷贝文档可能会放错地方，源代码清单应该能够独立存在。外部文档应该由规范、设计文档、更改请求、错误历史记录和使用的编码标准组成。
内部软件文档的一个难题是确保注释的维护与更新与源代码同时进行。尽管正确注释源代码在运行时没有任何用途，但这对于必须维护特别复杂或麻烦的软件片段的开发人员来说却是无价的。
以下几点是推荐的注释方法：
如果用 C# 进行开发，请使用 XML 文档功能。有关更多信息，请参见：XML 文档。 修改代码时，总是使代码周围的注释保持最新。 在每个例程的开始，提供标准的注释样本以指示例程的用途、假设和限制很有帮助。注释样本应该是解释它为什么存在和可以做什么的简短介绍。 避免在代码行的末尾添加注释;行尾注释使代码更难阅读。不过在批注变量声明时，行尾注释是合适的;在这种情况下，将所有行尾注释在公共制表位处对齐。 避免杂乱的注释，如一整行星号。而是应该使用空白将注释同代码分开。 避免在块注释的周围加上印刷框。这样看起来可能很漂亮，但是难于维护。 在部署之前，移除所有临时或无关的注释，以避免在日后的维护工作中产生混乱。 如果需要用注释来解释复杂的代码节，请检查此代码以确定是否应该重写它。尽一切可能不注释难以理解的代码，而应该重写它。尽管一般不应该为了使代码更简单以便于人们使用而牺牲性能，但必须保持性能和可维护性之间的平衡。 在编写注释时使用完整的句子。注释应该阐明代码，而不应该增加多义性。 在编写代码时就注释，因为以后很可能没有时间这样做。另外，如果有机会复查已编写的代码，在今天看来很明显的东西六周以后或许就不明显了。 避免多余的或不适当的注释，如幽默的不主要的备注。 使用注释来解释代码的意图。它们不应作为代码的联机翻译。 注释代码中不十分明显的任何内容。 为了防止问题反复出现，对错误修复和解决方法代码总是使用注释，尤其是在团队环境中。 对由循环和逻辑分支组成的代码使用注释。这些是帮助源代码读者的主要方面。 在整个应用程序中，使用具有一致的标点和结构的统一样式来构造注释。 用空白将注释同注释分隔符分开。在没有颜色提示的情况下查看注释时，这样做会使注释很明显且容易被找到。
格式格式化使代码的逻辑结构很明显。花时间确保源代码以一致的逻辑方式进行格式化，这对于您和必须解密源代码的其他开发人员都有帮助。
以下几点是推荐的格式化方法。
建立标准的缩进大小(如四个空格)，并一致地使用此标准。用规定的缩进对齐代码节。 在发布源代码的硬拷贝版本时使用 monotype 字体。 在括号对对齐的位置垂直对齐左括号和右括号，如：
for (i = 0; i < 100; i++)
{
}还可以使用倾斜样式，即左括号出现在行尾，右括号出现在行首，如：
for (i = 0; i < 100; i++){
}无论选择哪种样式，请在整个源代码中使用那个样式。
沿逻辑结构行缩进代码。没有缩进，代码将变得难以理解，如：
If Then
If Then
Else
End If
Else
End If缩进代码会产生出更容易阅读的代码，如：
If Then
If Then
Else
End If
Else
End If为注释和代码建立最大的行长度，以避免不得不滚动源代码编辑器，并且可以提供整齐的硬拷贝表示形式。 在大多数运算符之前和之
