更新时间：2024-03-27 23:33
可移植性是软件质量之一，良好的可移植性可以提高软件的生命周期。代码的可移植性主题是软件；可移植性是软件产品的一种能力属性，其行为表现为一种程度，而表现出来的程度与环境1密切相关。（注1：环境包括软件环境，硬件环境和系统的组织环境）。软件可移植性指与软件从某一环境转移到另一环境下的难易程度。为获得较高的可移植性，在设计过程中常采用通用的程序设计语言和运行支撑环境。尽量不用与系统的底层相关性强的语言。
特性
其质量子特性有：适应性、易安装性、共存性、易替换性和依从性。
可移植性并不是指所写的程序不作修改就可以在任何计算机上运行，而是指当条件有变化时，程序无需作很多修改就可运行。
你不要把“我不会碰到这种情况”这句话说得太早。直到MS—视频教程'＞windows出现之前，许多MS—DOS程序员还不怎么关心可移植性问题。然后，忽然之间，他们的程序不得不在一个看起来不同的操作系统上运行。当Power PC流行起来后，Mac机的程序员不得不去应付一个新的处理器。任何一个在同版本的UNIX下维护过程序的人所了解的可移植性的知识，恐怕都足以写成一本书，更别说写成一章了。
假设你用基本ALBATR—OS(Anti-lock Braking and Tire Rotation operating system)的Tucker C来编写防抱死刹车软件，这听起来好象是一个最典型的不可移植软件。即便如此，可移植性仍然很重要：你可能需要把它从Tucker C的7．55c版本升级到8．O版本，或者从ALBATR—OS的3．o版本升级到3．2a版本，以修改软件中的某些错误；你也可能会出于仿真测试或宣传的目的，而把它(或其中一部分)移植到MS-Windows或UNIX工作站上；更为可能的是，在它尚未最终完工之前，你会把它从一个程序员手中交到另一个程序员手中。
可移植性的本意是按照意料之中的方式做事情，其目的不在于简化编译程序的工作，而在于使改写(重写!)程序的工作变得轻易。假如你就是接过别人的程序的“倒霉蛋”，那么原程序中的每一处出乎意料之外的地方都会花去你的时间，并且将来可能会引起微妙的错误。假如你是原程序的编写者，你应该注重不要使你的程序中出现出乎接手者意料之外的代码。你应该尽量使程序轻易理解，这样就不会有人抱怨你的程序难懂了。此外，几个月以后，下一个“倒霉蛋”
很可能就会是你自己了，而这时你可能已经忘记了当初为什么用这样复杂的一种方式来写一个for循环。
使程序可移植的本质非常简单：假如做某些事情有一种既简单又标准的方法，就按这种方法做。
使程序可移植的第一步就是使用标准库函数，并且把它们和ANSI/ISO C标准中定义的头文件放在一起使用，详见第11章“标准库函数”。
第二步是尽可能使所写的程序适用于所有的编译程序，而不是仅仅适用于你所使用的编译程序。假如你的手册提醒你某种功能或某个函数是你的编译程序或某些编译程序所特有的。你就应该谨慎地使用它。有许多关于c语言编程的好书中都提出了一些关于如何保持良好的可移植性的建议。非凡地，当你不清楚某个东西是否会起作用时，不要马上写一个测试程序来看看你的编译程序是否会接受它，因为即使这个版本的编译程序接受它，也不能说明这个程序就有很好的可移植性(C++程序员比c程序员应该更重视这个问题)。此外，小的测试程序很可能会漏掉要测试的性能或问题的某些方面。
第三步是把不可移植的代码分离出来。假如你无法确定某段程序是否可移植，你就应该尽快注释出这一点。假如有一些大的程序段(整个函数或更多)依靠于它们的运行环境或编译方式，你就应该把其中不可移植的代码分离到一些独立的“．c”文件中。假如只在一些小的程序段中存在可移植性问题，你可以使用#ifdef预处理指令。例如，在MS-DOS中文件名的形式为“ ools eadme”，而在UNIX中文件名的形式为“/tools/readme”。假如你的程序需要把这样的
文件名分解为独立的部分，你就需要查找正确的分隔符。假如有这样一段代码
#ifdef unix
#define FILE_SEP_CHAR'/'
#ifdef __MSDOS__
define FILE SEP CHAR'\'
#endif
你就可以通过把FILE_SEP_CHAR传递给strchr()或strtok()来找出文件名中的路径部分。尽管这一步还无法找出一个MS-DOS文件的驱动器名，但它已经是一个正确的开头了。
最后，找出潜在的可移植性问题的最好方法之一就是请别人来查找!假如可以的话，最好请别人来检查一下你的程序lint