[转]中文技术文档写作规范

中文技术文档写作规范

注: 此规范转自阮一峰的个人博客: http://www.ruanyifeng.com/blog/2016/10/document_style_guide.html, 去掉了一些图片.


很多人说, 不知道怎么写文档, 都是凭着感觉写.

网上也很少有资料, 教你写文档. 这已经影响了中文软件的发展.

英语世界里, 文档非常受重视, 许多公司和组织都有自己的文档规范, 清楚地规定写作要求, 比如微软, MailChimp, Apple, Yahoo, docker, Struts 等等(维基百科有一份完整的清单). 中文的也有不少, 但都不令人满意, 要么太简单, 要么不太适用.

我就动手, 参考上面的规范, 也结合自己的实践, 总结了一份简单的<<中文技术文档的写作规范>>.

  1. 标题
  2. 文本
  3. 段落
  4. 数值
  5. 标点符号
  6. 章节结构

我希望, 这样可以抛砖引玉, 让更多人重视文档, 进而真正出现大家普遍接受的文档规范.

下面是关于写作风格的一个片段. 欢迎提交 IssuePR 补充.

=================================

写作风格

(摘自<<中文技术文档的写作规范>>)

如果使用了被动语态, 应考虑更改为主动语态.

错误: 假如此软件尚未被安装, 

正确: 假如尚未安装这个软件, 

不使用非正式的语言风格.

错误: Lady Gaga 的演唱会真是酷毙了, 从没看过这么给力的表演!!!

正确: 无法参加本次活动, 我深感遗憾. 

用对"的", "地", "得".

她露出了开心的笑容. 
(形容词+的+名词)

她开心地笑了. 
(副词+地+动词)

她笑得很开心. 
(动词+得+副词)

使用代词时(比如"其", "该", "此", "这"等词), 必须明确指代的内容, 保证只有一个含义.

错误: 从管理系统可以监视中继系统和受其直接控制的分配系统. 

正确: 从管理系统可以监视两个系统: 中继系统和受中继系统直接控制的分配系统. 

名词前不要使用过多的形式词.

错误: 此设备的使用必须在接受过本公司举办的正式的设备培训的技师的指导下进行. 

正确: 此设备必须在技师的指导下使用, 且指导技师必须接受过由本公司举办的正式设备培训. 

句子的长度尽量保持在20个字以内;20~29个字的句子, 可以接受;39~39个字的句子, 语义必须明确, 才能接受;多于40个字的句子, 在任何情况下都不能接受.

错误: 本产品适用于从由一台服务器进行动作控制的单一节点结构到由多台服务器进行动作控制的并行处理程序结构等多种体系结构. 

正确: 本产品适用于多种体系结构. 无论是由一台服务器(单一节点结构), 还是由多台服务器(并行处理结构)进行动作控制, 均可以使用本产品. 

同样一个意思, 尽量使用肯定句表达, 不使用否定句表达.

错误: 请确认没有接通装置的电源. 

正确: 请确认装置的电源已关闭. 

避免使用双重否定句.

错误: 没有删除权限的用户, 不能删除此文件. 

正确: 用户必须拥有删除权限, 才能删除此文件. 

(正文完)

从技术文档写作的一个细节问题说起

技术文档经常会碰到中英文混合的问题, 那么在中英文混合时有什么注意事项吗? 恐怕很多人从来没有思考过这个问题. 我之前也从未考虑过这个问题, 直到有一次我参与了英文技术文档的翻译与校对, 才意识到了一些问题.

具体说是两次, 由 oschina 所组织的, 一次是校对, 一次是翻译, 都参与了一部分, 不过已经记不得是哪次意识到这个问题了.

一个经常被忽视的问题就是, 英文单词与中文字词之间实际上是要有空格的.

一个正确的示例: 中文中夹着 english 的情况.

一个错误的示例: 中文中夹着english的情况.

看到区别了吗? 前者是有空格的, 后者则没有.

如果你看一些正规专业出版社出品的一些技术图书, 比如人民邮电出版社的 O’Reilly 系列, 你翻开看看, 你会发现正文中有中英文混合的情况下都是有空格的.

有人可能会说, 好像也没多大区别呀, 中文和英文之间本来就有足够的区分度, 何必去加那些空格呢? 有人说不定还更喜欢那种紧凑的风格.

就我个人而言, 我觉得确实有空格的看上去更舒服一些, 之前一直没有意识到这个问题, 但还是能隐隐感觉到某些书的排版就是比其它一些要好, 尽管当时说不出为什么, 现在想想, 可能就是这些细节上的差异所导致的.

其实不单单是英文与中文间有空格, 认真观察下, 你会发现很多数字与中文间也是有空格的, 种种细节上的差异最终导致了观感上的差距.

也难怪人们会说: 功夫在细节上. 当一个人不放过任何的细节时, 才算是把用户体验真正放到了心上.

当然, 个人偏好有时像"甜豆腐脑与咸豆腐脑"之争, 是争论不清的. 抛开个人偏好不谈, 这其实还涉及到一个规范的问题.

既然出版社都这么处理, 所以这也许早已经形成了一个规范, 可能是行业中约定俗成的, 甚至也可能是国家层面的指导规范. 那么, 对于我们这些后来者来说, 其实个人偏好已经不重要了, 重要的是遵循共同的规范.

特别是在一个团队中时, 过于强调个人偏好反而是有害的, 因为会导致整体风格的混乱与不统一.