GNU 编码标准 1
1．目的 1
2．适用范围 1
3．规范内容 1
1．目的
规范GNU相关项目的代码编写规范。
2．适用范围
适合公司所有的GNU项目。
3．规范内容
3.1引用私有程序
不要在任何情况下,为你在的GNU中的工作或者在工作中引用Unix的源代码（或者任何其它私有程序）。
如果你对一个Unix程序内容有一些模糊的记忆，这并不因为着你绝对写程序来模仿它， 但请试图在内部使用不同的代码行来组织它，因为这将使你工作的结果在细节上与Unix版本有所不同。
例如，Unix工具通常进行了优化以使用最少的内存；如果你更希望提高速度，你的程序将会有很大的不同。 你可以在内核中保存整个输入文件并且在内存中扫描而不是使用stdio。使用比Unix程序更新的、 更明智的算法。不使用暂时文件。在一遍扫描而不是两遍扫描中完成任务（我在assembler（汇编器）中这样做了）。
或者相反，强调简单性而不是速度。对于一些应用程序来说，今天的计算机只要使用简单的算法就够了。
或者注重一般性。例如，Unix程序通常使用静态的表格和固定大小的字符串，这导致了不可改变的限制； 用动态分配来代替。确认你的程序处理了输入文件为空和其它滑稽的情况。为增加扩展性而增加一种 程序语言并且用那种语言完成程序的一个部分。 本文来自辣.文,论-文·网原文请找腾讯752018766
或者把程序的一部分修改成独立的库。或者用一个简单的废物收集器而不是在释放内存的时候精确地进行跟踪， 或者使用诸如obstacks这样的新的GNU工具。
3.2接受他人的奉献
如果其他人发给你一段添加到你正在编写程序中的代码，我们需要准许使用它的法律文书 --我们将需要从你那里取得同样的法律文书。程序的每个重要的贡献者都必须签署 某种法律文书以使得我们可以给程序一个清晰的标题。仅有主要作者是不够的。
所以，在把来自于他人的任何共享添加到程序中之前，告诉我们以便我们可以做出安排 以获取文书。在你实际地使用贡献之前，请等待直到我们告诉你我们已经收到了签署的文书。
这即适用于你发行程序之前也适用于发行之后。如果你收到了一个修正bug的补丁，并且 它们做了主要的修改，我们就需要为他提供法律文书。
你不需要为这里或者那里的少数几行修改提供文书，因为对于达到版权目的没有意义。 还有，如果你从建议中获得的仅仅是一些想法，而不是你实际上使用的代码，你也不需要文书。 例如，如果你写了一个程序的不同解决方案，你并不需要获得许可文书。
我知道这是十分麻烦的；它对我们来说也十分麻烦。但如果你不等待，你就可能误入歧途， 如果这个贡献者的雇主不肯签署弃权声明怎么办？你可能不得不再次把代码剔除出来！
最糟糕的情况是如果你忘记告诉我们其它的贡献者，我们可能会因此而窘迫地出现在法庭上。 2673