浅谈编码中的缩写

目前而言，几乎所有的编程语言都是使用英文来表示，在英文中，使用缩写很普遍，比如URL(Uniform Resource Locator)能够很简单高效地向他人阐述要表达的概念。

然后，在现实的开发过程中，缩写有时候会被滥用，甚至是脱离了其高效传递信息的意思。

比如以广告跟踪数据为例，如下是部分广告跟踪信息

{	
    "pm" : [	
        "https://example.com/pm.php"	
    ],	
    "cm" : [	
        "https://example.com/cm.php"	
    ]	
}

看了上面的协议约定，你应该会这样

• 你应该无法判断pm和cm的明确意思

• 你开始思考，cm是什么缩写，pm是什么缩写。

• 最终你还是不知道什么意思，便搜找文档或者询问他人。

OK，那我们看看如果不用缩写，这样能不能传达信息呢？

改进版本1

{	
    "impression_tracking_urls" : [	
        "https://example.com/pm.php"	
    ],	
    "click_tracking_urls": [	
        "https://example.com/cm.php"	
    ]	
}

改进版本2

{	
    "tracking_urls" : {	
        "impression": [	
            "https://example.com/pm.php"	
        ],	
        "click": [	
            "https://example.com/cm.php"	
        ]	
    }	
}

不论是上面的改进版本1还是2，在不依赖文档或他人的情况下，我们应该都可以清晰的分辨出哪些是广告曝光的跟踪连接，哪些是点击后的追踪链接。

看完示例，开始具体清谈一下缩写这个内容。

什么是不好的缩写

• 字符过短，让人无法推测其完整形式

• 存在和通用认知缩写冲突，比如上面的 cm和 pm可能会被认为是 Centimeter(厘米)或 post meridiem(下午)对应的缩写。

• 不遵循缩写规则，对于词组来说，通常是取每个单词首字母；对于一个单词来说，是尽量剔除其元音字符(a,e,i,o,u)，比如MicroSoft其股票代码为 MSFT

为什么要避免不好的缩写

• 不好的缩写，表意不明，甚至是产生误解

• 不好的缩写，需要依赖于文档或者他人

• 不好的缩写使用，会导致开发者思考，效率变低。

• 不好的缩写，甚至可能会造成双方的不信任。

为什么会出现不好的缩写

其实最关键的因素还是人，这主要表现在

• 编码约定随意性

• 自身的技术约束较低，甚至是拒绝思考更优解。

• 英语水平限制

如何避免不好的书写

当然避免的关键还是人的因素，针对上面的症结，需要做如下处理

• 增强自身约束，认真对待，不随意缩写。

• 保持求索的态度，寻找更优解

• 学习英语，提升基本功。

随意缩写一时爽，后期维护泪千行。

点击阅读原文，查看更多小黑屋文章。