让程序员早点下班对于程序员来说，每天要么在写bug，要么在修bug~除了马不停蹄的码字，做好一些细节无疑可以帮助我们早点下班。这不，国外一位前端开发者总结了一篇文章《程序员技术写作指南》，内容是如何正确写代码注释，写PR描述等等。虽然这些东西都是小事，但是如果大家都不规范，那维护代码是多么的痛苦呢？我都明白了。那么，你应该注意什么？程序员技术写作Tips1、代码注释代码注释不仅是给自己写的，也是给别人写的。尤其是后者，更要写清楚。对此，指南给出了三点注意事项：（1）写好关键信息，而不是简单的胡说八道的例子。错误的写法：red=1.2//将红色乘以1.2并重新赋值（将红色变量2赋给它）正确的写法：red*=1.2//对图像应用“偏红”效果（应用a'reddish'effect对图像的“reddish”效果）很好理解。不要重复代码，写出这段代码的深层含义，提供增量信息。(2)代码改动后，注释也要更新。有这么一行代码和注释：cities=sortWords(cities)//sortcitiesfromAtoZ（从A-Z排序城市变量）但是作者写错了。事实上，sortWords函数来自Z-ASort。不过没关系，加个reverse就好了，于是代码就变成了这样：cities=sortWords(cities)//sortcitiesfromAtoZ（从A-Z排序城市变量）cities=reverse(cities)那么问题来了，其他不知道这个过程，只看第一行注释，自然会认为城市是先按照A-Z排列，然后从Z倒序到A。这就是改代码不改注释的后果。当然，这个例子有些夸张。但是像这样的事情确实有可能造成不必要的麻烦。(3)非常规用法必须注释有时候，为了兼容各种浏览器，你可能会在代码中加入一些非常规的写法。这时候就要注意写评论了。否则，其他人可能会认为“这有什么问题”，并为您更改它...示例：functionaddSetEntry(set,value){/不要返回set.add因为它在IE11中不可链接。（不要返回"set.add",不兼容IE11)/set.add(value);被动语态的句子需要在脑海中转化为主动语态，不需要增加这个处理时间。(4)贴出解决方案的链接有时遇到问题，上网搜索解决方案，可以附上链接，方便查阅，以备不时之需。有网友表示，这个建议非常有用，因为有时候他会忘记自己当时为什么要这样写代码。2.PR描述提交代码时如何写PR描述也是一个重要的细节，关系到codereview的效率。尽管许多团队内部都有规范，但有些人就是不遵守这些规范。以下几点需要特别注意：（1）写得详细，不要写“加补丁”、“修复错误”等含糊不清的表述；正面例子：eg1。在NgOptimizedImageeg2中支持自定义srcset属性。为所有内置的ControlValueAccessors添加显式选择器（2）不要一下子提交几千行代码，尽量完成一小部分再提交，以减轻审核压力。3、报告bug时，需要提交bug报告时，尽量做到：(1)多使用截图/动图辅助问题的文字描述；(2)提供重现问题的精确步骤；(3)为您的分析提供可能的原因。4.缩微复制。对于国内的情况，这部分比较适合产品经理。微文是指当用户操作/系统出现错误时，您的网页/APP上弹出的提示。这种提示语的写法也有讲究：（1）避免使用专业术语。相信很多人都遇到过诸如“执行超时”之类的一行你看不懂的技术提示，让你想知道到底发生了什么，该怎么办。避免这种情况的最好方法是告诉用户该做什么而不解释哪里出了问题。(2)不要“责怪”用户。想象一下，打开一个网站，登录，然后被告知：“您的电子邮件/密码不正确。”这种表达下意识地不舒服，让用户觉得“愚蠢”。正确方式：“抱歉，邮箱密码组合不正确，我们可以帮您找回账号。”还有一点：尽量避免全部大写或使用感叹号，这会带来敌意。（3）适当使用幽默语气，有时强行幽默还不如不幽默。原指南还包括一些如何与人沟通的建议。客户，有兴趣的朋友欢迎点击链接阅读~
