编写代码时，对边界问题的处理如何才算是适度？

我在用 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 是很在意健壮性的。

想知道各位的观点，最好不要讨论商业压力下的产品软件，而是谈谈优秀设计的软件，或者分享你在这方面的宝贵经验。