https://www.backblaze.com/blog/10-rules-for-how-to-write-cross-platform-code/

摘译如下:

1. 同时设计开发多个平台, 不要移植.

考虑到平台的差异, 同时开发可能会慢5%左右. 但是移植的工作量完全说不准, 所有粗暴的设计决策都可能导致不可移植.

2. 把界面部分放到独立的代码中, 只逻辑部分进行跨平台开发.

各平台的美学观点不一样, 跨平台的界面代码无法让大家都满意. 幸好只针对一个平台设计界面的难度要小很多.

3. 使用标准C类型, 不是平台特定类型.

标准C类型可能最可移植的类型了, 特别是C99增加了uint8_t,uint16_t,uint32_t这些类型之后.

4. 只使用内建的编译器标记(宏)不要自己发明

平台相关代码和特性相关代码不一样,平台相关代码直接与平台相关,它不需要自己定义宏标记,再从构建脚本(Makefile/config.h等)中重新定义它. 平台相关代码只能在相关平台下编译,类似(_WIN32),不应该定义一个WINDOWS_OS,再当有定义WIN32时设置它为有效.

5. 必要时,开发一个简单的,跨平台的基础代码, 隐藏平台相关的代码.

平台中重复出现的平台相关代码, 可以提取到一个跨平台基础代码库中, 这样开始可能会略慢一点, 但之后的实现就更准确有效.

6. 在所有API上,使用Unicode, 特别是UTF-8

各平台的内码都不完全一样, 所以系统内部使用Unicode, 特别是UTF-8可以提供一个可交换的层次, 更好的是现在大多数平台对Unicode或UTF-8提供了直接支持.

7. 不要使用应用框架来跨平台

C/C++自己可以跨平台(以编译的形式), 并不需要一个特定的应用框架跨平台. 第三方库真正的用途是增加功能, 比如openssl. 这条与规则2 分离界面实现相关. 使用一个跨平台的界面框架开始编码, 很可能得到一个丑陋的基本功能程序.
引入一个巨大的应用框架还可以引入它自己自身的问题, 很可能得不偿失.

8. 所有平台使用所有代码, 不要使用一个脚本去分离编译.

没有什么问题不能通过一个预编译脚本解决,但它引入了不必要的复杂程度, 从开始设计跨平台相关的内容. 使用原汁原味的C/C++,能让程序变得简单. 让一个C/C++文件可以直接编译, 不要引入太多的规则.

9. 所有程序员都应在所有平台上编译.

不要把程序员分成windows程序员, linux程序员, mac程序员, 这样他们就看不到跨平台代码的必要性, 让所有程序员都可以在所有目标平台上编译, 可以让所以跨平台问题最快发现.

10 解雇那些不按规则的程序员

最好的程序员也可以偶尔犯错, 但是日复一日持续产出有问题代码并不光荣.