本章节主要内容侧重于确保程序的可移植性，这不仅限于各种Linux系统，而且也针对各种UNIX系统。对其他UNIX系统保持可移植性并非是故意卖弄技术或者是遵守黑客的礼节，而是一种保持未来Linux自身发展不分裂的保障手段。
另外，如果其他人试图将你的项目移植到其他非Linux系统上，一个可移植性好的项目可以让你最大限度的避开各种烦人的Email质询。
要有可移植性和稳定性，你最好只用ANSI C写程序，要不就用某种教本语言，这样能够保持可移植性的原因是他们底层的实现对于不同平台是一致的。
有资格被成为跨平台的脚本语言包括 Python、Perl、Tcl、Emacs Lisp 和 PHP。普通的老式Shell则不具有好的可移植性；因为他们在不同平台上的实现有许多细微的语法差别，而且Shell的外壳环境极易受到用户个性化设置（如alias设置）的干扰。
Java总是声称自己是跨平台的语言，但是Java在Linux上的实现还非常少而且与Linux系统的集成度还比较差。虽然Java以后成熟了将会变得非常流行，不过时下还是不要选她的好。
如果你用C写程序，请记住一定要完全遵从ANSI标准——包括函数原型，这样可以帮助你去掉跨平台模块的不一致性。老的K&R编译器已经成为了历史。
另外，不要认为一些GCC特有的特征，比如“-pipe”编译选项以及嵌套函数等，在所有平台上都有效。因为这样的选项会在其他人试图将项目移植到非Linux、非GCC系统上时起作用并被“咬”一口。
如果用C写程序，记住一定要用autoconf/automake/autoheader工具来处理各种移植性的问题，用这些工具完成系统配置信息的收集，制作makefile文件。现在许多人在打算编译源码时只希望通过“configure; make”这样简单的命令就可以得到干净利落的编译，事实上大家就是这么干的。
用C写程序，至少在每次发布之前要记得用 -Wall 编译选项重新编译一遍并去除编译中遇到的任何错误。这么做可以帮助你发现不少没有想到的错误。要是想更彻底的检查，那就用 -pedantic 选项再编译一遍。
如果是写Perl程序，可以用 perl -c 命令（或者 -T 选项）来检查代码中的错误。使用 perl -w 和“use strict”来做更严格的检查（请阅读Perl的文档获取更多的信息）。
文档发布前最好用拼写检查工具查一遍。如果你看起来没有能力拼写正确，而且也不关心文档的错字、错词，那么其他人很自然的联想到你的代码是否也同样是乱七八糟和粗心大意呢？