发现一个查单词缩写的网站，妈妈再也不用担心我给变量命名了！

好东西，抱起 api 就逃 👏

http://www.abbreviations.com/abbr_api.php

好东西，经常为缩写难看而纠结，以后可以增加选择何种缩写纠结了 OwQ

坐等 Alfred Workflow

爽！这下子可以提升代码比格。恩😄

感谢分享，收下了~

感谢分享

准备开发一个 Vim 插件自动缩短当前单词……专治 java 程序员：

course_selection_header.setLayout(course_selection_headerLayout);
->
{course selection header set Layout course selection header Layout}

=>

{crs selection h set Layout crs selection h Layout}

-> crs_selection_h.setLayout(crs_selection_hLayout);

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

private void course_management_buttonActionPerformed(java.awt.event.ActionEvent evt)

=>

private void crs_mgmt_bActnPerformed(java.awt.event.ActionEvent evt)

不过好像并没有多大用处， course 缩写成 crs 很有可能下一个维护代码的看不懂，所以估计还要增加一个自动还原当前单词的功能……

哪怕是 response 这种长单词，我都希望还是写原文，
一个是现在轻量级编辑器也有提示，或自动补全，
二是像 @htfy96 说的便于日后维护，有些缩写是有歧义的。
--
然后最讨厌连 count 和 length 甚至 list 都缩写的… 乱七八糟的…

这样会不会 以后难以识别自己写的变量名

@abelyao 是的。建议不要缩写。 nodeJS 不少人把 error, response ，缩写成 err, res ，我也觉得不大好。一旦上下文变长的话就开始有歧义了。

@fatea res 是有很多歧义的一个缩写… response / result / resource 都有人缩写为 res ，而这三个词极有可能出现在同一份代码环境中，比如前端开发…

res 确实有毒，很多时候要去上面看一眼是传进来的(req, res)，还是 SQL 出来的 result

写 java 没有多少句是自己写完的，大多是自动补全

到时候自己都不认识自己的变量了怎么办，这东西还是好记最重要

oc 程序员说你们慢聊

这个结果前两个我就不同意
后四个顶多勉强接受

还是写完整吧....

Nice ！

遇到过变量命名从 a 用到 z 以后，再从 aa 到 zz 的同学。整个一个十字路口遇到红灯从 99 倒数到 00 然后再从 99 开始的即视感。后来发现把他的代码混淆过以后再反编译，出来的结果比直接看还好懂些。

写程序时还得停下来跑去查单词，强迫症要不得。很多时候我把四五个长单词合在一起当作变量名。这么短的就受不了了？

可是不缩写又是保留字 哈哈

@abelyao
@welly
@fatea
@abelyao
@gimp
@zonghua
@Cavolo
@zhujinliang
@dd99iii
变量名缩写有它的优点：

* 从输入速度来说，即使自动补全很强大，长度为 2-3 的缩写手打速度也要快一些，长度为 4 的缩写也不见得慢。
* 从可读性来说，如果 (上下文提示足够明确 || 这种缩写很常见 || 是只用在短函数内部的局部变量)，那么可读性不见得更差，而且用整个单词作变量名不见得可读性就好，拿 Hasekll 来说，下面两种说明，你们觉得哪种可读性更好呢？

```hs
putCircle :: (Eq a, Show a) => Int -> Int -> [a] -> [[a]] -> [[a]]
putCircle :: (Eq variable, Show variable) => Int -> Int -> [variable] -> [[variable]] -> [[variable]]
```

缩写能让格式齐整，反而会让可读性更好，举个不太恰当的例子：

```python
len = 0
tmp = 0
cnt = 0
var = NULL
buf = NULL
ptr = NULL

length = 0
temp = 0
count = 0
variable = NULL
buffer = NULL
pointer = NULL

# 当然也可以用插件弄成下面这种形式，但是修改起来很蛋疼
length = 0
temp = 0
count = 0
variable = NULL
buffer = NULL
pointer = NULL
```

简而言之，缩写不是糟粕，滥用才是。否则，为什么很多地方还是用 max, min, sum, fst, snd 等做函数名，而不是全称呢？

@arbipher @nicegoing 只是举个例子，本来这些缩写也就仅供参考

v2ex 吞空格真是让人恼火，谁知道为什么要吞空格吗？

试了下，没啥卵用…… 实际代码开发中命名最困难的是业务相关的变量，而不是程序上的。

还可以的，但是不是所有单词都可以缩写

写多长都没关系，大不了混淆一下不就好了

如果有一个开发字典来规范所有的缩写的话，在公司里用缩写也没什么不好，重点是，很多 team 并没有啊。
于是各种不一样的缩写，最后徒增维护成本。

对于一个维护过像 class biao() class tu() 这样的代码的人，极力推荐变量名要语义清晰，并且规范...

我喜欢写完整的，

不过有时候 一行不够， 恰好多出一两个字符， 变成两行了。。。就开始强迫症了，，到底要不要缩写呢 要不要缩写呢。。。

你自己写的时候都要查工具了，那么你觉得其他读你代码的人（包括一个月后的你自己）有几个能猜出来 cir 是代表 circle 的？

我习惯把 content 缩写为 cnt ， count 缩写为 n ，而且这样的缩写都是临时变量，不会超过一屏。

谁来挖一个 sublime 的坑

敲砖打碗坐等 workflow

@nisnaker cnt 一般是 count 的缩写吧 你这样缩写会害人的

@onlyxuyang

我习惯把 content 缩写为 cnt ， count 缩写为 n ， [而且这样的缩写都是临时变量，不会超过一屏] 。

我只会害到不看上下文就改代码的人，这样的人，害就害了。

即时按你所说，你们那边习惯把 count 缩写为 cnt ，难道就不用去看 cnt 在哪里赋值的么？

@nisnaker review code 和实际调试 bug 时当然不一样…… 随便啦 话说 content 我一般就写 content 哈哈哈

按照楼主这个网站的思路，收集整理了一批缩写，做了一个 Dictionary App 的字典：
https://github.com/fangpeishi/Abbreviations

mark

好东西