文档介绍：GNU编码标准引用私有程序不要在任何情况下,为你在的GNU中的工作或者在工作中引用Unix的源代码(或者任何其它私有程序)。如果你对一个Unix程序内容有一些模糊的记忆,这并不因为着你绝对写程序来模仿它,但请试图在内部使用不同的代码行来组织它,因为这将使你工作的结果在细节上与Unix版本有所不同。例如,Unix工具通常进行了优化以使用最少的内存;如果你更希望提高速度,你的程序将会有很大的不同。你可以在内核中保存整个输入文件并且在内存中扫描而不是使用stdio。使用比Unix程序更新的、更明智的算法。不使用暂时文件。在一遍扫描而不是两遍扫描中完成任务(我在assembler(汇编器)中这样做了)。或者相反,强调简单性而不是速度。对于一些应用程序来说,今天的计算机只要使用简单的算法就够了。或者注重一般性。例如,Unix程序通常使用静态的表格和固定大小的字符串,这导致了不可改变的限制;用动态分配来代替。确认你的程序处理了输入文件为空和其它滑稽的情况。为增加扩展性而增加一种程序语言并且用那种语言完成程序的一个部分。或者把程序的一部分修改成独立的库。或者用一个简单的废物收集器而不是在释放内存的时候精确地进行跟踪,或者使用诸如obstacks这样的新的GNU工具。接受他人的奉献如果其他人发给你一段添加到你正在编写程序中的代码,我们需要准许使用它的法律文书——我们将需要从你那里取得同样的法律文书。程序的每个重要的贡献者都必须签署某种法律文书以使得我们可以给程序一个清晰的标题。仅有主要作者是不够的。所以,在把来自于他人的任何共享添加到程序中之前,告诉我们以便我们可以做出安排以获取文书。在你实际地使用贡献之前,请等待直到我们告诉你我们已经收到了签署的文书。这即适用于你发行程序之前也适用于发行之后。如果你收到了一个修正bug的补丁,并且它们做了主要的修改,我们就需要为他提供法律文书。你不需要为这里或者那里的少数几行修改提供文书,因为对于达到版权目的没有意义。还有,如果你从建议中获得的仅仅是一些想法,而不是你实际上使用的代码,你也不需要文书。例如,如果你写了一个程序的不同解决方案,你并不需要获得许可文书。我知道这是十分麻烦的;它对我们来说也十分麻烦。但如果你不等待,你就可能误入歧途,如果这个贡献者的雇主不肯签署弃权声明怎么办?你可能不得不再次把代码剔除出来!最糟糕的情况是如果你忘记告诉我们其它的贡献者,我们可能会因此而窘迫地出现在法庭上。修改日志为每个目录维护一个修改日志,以记述对这个目录下源文件的修改。这样做的目的是使得在将来寻找bug的人可以指导大致是那些修改导致了错误。通常,一个新的bug可以在最近进行的修改中被找到。更重要的事,修改日志有助于消除程序的不同部分之间在概念上的不一致性;它们可以告诉我们概念冲突产生的历史。使用Emacs命令M-xadd-change在修改日之中创建一个新的条目。一个条目应该包含一个星号、被修改的文件的名称以及被扩在括号内的、被修改了的函数、变量或者任何东西。括号之后是冒号和对你对函数或变量的修改的说明。用空行把无关的条目分隔开。如果两个条目反映了同一个修改,因而它们一同工作,那就不要在它们之间使用空行。如果后续的条目针对的是相同的文件,那么你可以忽略文件名的星号。下面是一些例子:*(insert-register):Returnnil.(jump-to-register):Likewise.*(sort-subr):Returnnil.*tex-(tex-bibtex-file,tex-file,tex-region):Restartthetexshellifprocessisgoneorstopped.(tex-shell-running):Newfunction.*(store_one_arg):Roundsizeupformove_block_to_reg.(expand_call):RoundupwhenemittingUSEinsns.*(assign_parms):。把这些说明作为注释放到代码中更好一些。这就是说为什么只要给出“Newfunction”就够了;在源代码中,与函数放在一起的注释说明了它是做什么的。然而,有时为一大堆修改写上一行文字以描述它们的整体目的是有用的。在概念上,你可以把修改日志看作解释原始版本与当前版本的不同的“undo列表”。人们可以阅读当前的版本;他们不需要修改日志告诉他们其中有什么。他们从修改日之中得到的是关于早期版本的不同的清晰解释。在你以简单的方式修改函数的调用顺序,并且你修