这些惯例的大部分都与确保移植性，不仅仅在Linux界还包括其他Unix系统，有关。 可以移植到其他Unix上不只是专业主义的可敬形式（a worthy form of professionalism）， 而且易于理解（hackerly politeness），它还是对未来Linux本身的变化的有价值的保险。
最后，其他人将试图在非Linux系统中创建你的代码；可移植性将最大限度地 减少你将获得的恼人的，令人困惑的电子邮件消息。
为了移植性和稳定性，你应该用纯标准C（ANSI C）或可移植的脚本语言编程，脚本语言 因为只有一种跨平台实现而被确保是可以移植的。
具备这种资格的脚本语言包括Python、Perl、Tcl和Emacs Lisp。普通的老式shell 没有这种资格；它有太多的带有微妙特性的不同实现，而且shell环境受到 诸如shell别名之类的用户定制干扰。
Java给出了成为可移植语言的承诺，但对Linux可用的实现仍然凌乱而不能与Linux很好地集成。 虽然Java随着它的成熟变得更加流行，Java仍然是一种可能付出代价的选择（bleeding-edge choice），
如果你用C编程，不要有任何犹豫地使用所有标准（ANSI）特征 -- 包括函数原型，它将帮助你 发现跨模块的不一致性。老式的K&R编译器已经成为历史。
另一方面，不要假定任何GCC特有的功能，比如说`-pipe'选项或嵌套函数，是可用的。 它将在别人把它移植到非Linux、非GCC的系统的时候苏醒并咬你一口。
如果你用C编程，使用autoconf/automake/autoheader来处理移植性问题，完成系统配置探查， 以及制作你的makefiles。今天人们从源代码进行创建时希望能够输入"configure; make"并且 获得一个清晰的创建 -- 而且正是这样。
如果你用C编程，使用-Wall进行测试编译并且至少在每次发布之前清除一次错误。 它会找到今人数目的错误。为了完整，还要用-pedantic选项进行编译。
如果你用Perl编程，就用perl -c（如果可以，可能是-T）来检查你的代码。 坚持使用perl -w和'use strict'。（参见Perl文档的讨论。）