这是一个创建于 2350 天前的主题，其中的信息可能已经有所发展或是发生改变。
我在用 C 语言做一个 linux 上的编辑器，目前的阶段在实现快捷键绑定，也就是 vim 里的 binkey。
现在有个两个问题困扰到我：
1, 如果我假定用户自定义的快捷键不超过约 50 个，我的实现可以很简单。
因为这样就可以用一个数组容纳，做常规的线性查找，不用哈希表。
2, 如果我假定 function keys 对应的转义序列长度不超过 8 个。我的实现可以更简单。
容我解释一下 function keys，其实就是就是键盘上的 F1 ~ F12，类似的还有 HOME,PGUP 之类，在 linux 上它们没有对应的 ascii 码，而是 ESC 打头的转义序列，所以一般编辑器内部是把它们当做 sequence 类型的快捷键处理的。
我翻了 terminfo 数据库，发现在籍的 function keys 的转义序列长度都不超过 8 字节。因为我的编辑器恰好只在 x64 上运行，用一个 long long 类型容纳，有具体的编程技巧可以避免很多（真的很多）细节上的麻烦。
我自己编写程序的原则是，编程技巧只应该锦上添花的用，不会为了性能牺牲架构和程序的健壮性。
但怎么把握健壮的度，像上面两个假定，我自己很难取舍。采用的话，代码会更简洁和可读，但总觉得悬着心，不采用的话，我推测代码量会从 300 行增加到 800 行以上，我不是觉得费事，而是觉得无谓。
这是我自己的项目，不用迭代开发，至少在这种简单的功能上，想一开始就做决策。
我看了 Bash 和 Zsh 的源码，bash 用的是单链表，似乎它也认为快捷键不会很多，zsh 用的则是哈希表，从不少的代码细节能看出来，zsh 是很在意健壮性的。
想知道各位的观点，最好不要讨论商业压力下的产品软件，而是谈谈优秀设计的软件，或者分享你在这方面的宝贵经验。
现在有个两个问题困扰到我：
1, 如果我假定用户自定义的快捷键不超过约 50 个，我的实现可以很简单。
因为这样就可以用一个数组容纳，做常规的线性查找，不用哈希表。
2, 如果我假定 function keys 对应的转义序列长度不超过 8 个。我的实现可以更简单。
容我解释一下 function keys，其实就是就是键盘上的 F1 ~ F12，类似的还有 HOME,PGUP 之类，在 linux 上它们没有对应的 ascii 码，而是 ESC 打头的转义序列，所以一般编辑器内部是把它们当做 sequence 类型的快捷键处理的。
我翻了 terminfo 数据库，发现在籍的 function keys 的转义序列长度都不超过 8 字节。因为我的编辑器恰好只在 x64 上运行，用一个 long long 类型容纳，有具体的编程技巧可以避免很多（真的很多）细节上的麻烦。
我自己编写程序的原则是，编程技巧只应该锦上添花的用，不会为了性能牺牲架构和程序的健壮性。
但怎么把握健壮的度，像上面两个假定，我自己很难取舍。采用的话，代码会更简洁和可读，但总觉得悬着心，不采用的话，我推测代码量会从 300 行增加到 800 行以上，我不是觉得费事，而是觉得无谓。
这是我自己的项目，不用迭代开发，至少在这种简单的功能上，想一开始就做决策。
我看了 Bash 和 Zsh 的源码，bash 用的是单链表，似乎它也认为快捷键不会很多，zsh 用的则是哈希表，从不少的代码细节能看出来，zsh 是很在意健壮性的。
想知道各位的观点，最好不要讨论商业压力下的产品软件，而是谈谈优秀设计的软件，或者分享你在这方面的宝贵经验。
 |
1
zhujinliang 2018-07-15 13:24:44 +08:00 via iPhone
根据 HID 定义，扫描码最多 255 种情况，ctrl、alt、shift、win/cmd 如果不区分左右，最多 16 种组合，综上，开一个 256*16=4k 的数组，搞定🌚
|
 |
2
billlee 2018-07-15 13:46:10 +08:00
用 C++, 这样链表和散列表的代码量就没区别了
|
 |
3
ipwx 2018-07-15 14:02:55 +08:00 via iPhone
接楼上的评论，你需要面向对象…（如果你平时积累 c 的数据结构“类”，你照样可以写得很开心。什么你不会写 c 面向对象？！）
|
 |
4
kongque2016 OP @zhujinliang 编辑器运行在 terminal 上，read(0, xx)只能读出 ascii 键值或者 ESC 打头的转义序列。
|
 |
5
jm00 2018-08-04 08:26:07 +08:00 via Android
考虑到所有可能性，但是也别把明知道不可能的范围写进去，还找借口说“万一呢”
|
Select Language