Unix 文件命名约定是否有效制表符补全？

Question

我觉得我经常以这样的方式命名文件，以至于我的计算机在编程时不断发出蜂鸣声，因为制表符补全不明确。在进行大量 Unix 编程之前，我倾向于使用相同的前缀来命名相关文件以表明它们的关系。现在我必须重新思考我的文件夹和文件结构以及名称的方法，以便更有效地进行编程。

在编程以简化制表符完成时，您应用什么启发法或规则？您是否使用任何工具来使制表符完成更顺畅（例如， emacs 冰柱)?

编辑：哇，感谢您的精彩见解。我认为我的每一个可能的弱点都在答案中得到了解释。我接受了看似最能提高生产力的一篇，尽管它们都值得一读。

Answer 1

我通常从事的项目中相关文件都在同一个文件中 目录, ，并且文件名本身专门用于指示其内容。

当然，这引出了一个问题，为什么要对文件名进行制表符补全？如果您正在仔细阅读源代码，那么有 标签, 欧洲经济与发展中心, ，以及大量其他 公用事业 这将使您绕过文件名并直接跳转到您真正想要的函数/变量。

这完全取决于您真正想要做什么，而查找特定文件通常是达到不同目的的手段。

Answer 2

一般来说，

setterm -blength 0

将禁用终端的蜂鸣声。 GNU 屏幕 有些图形终端有自己的蜂鸣通知设置。

专门针对 重击 和别的 阅读线- 使用软件，可以使用以下命令更改选项卡完成行为 $INPUTRC, /etc/inputrc, ， 和 ~/.inputrc 配置文件。例如，

bell-style none     # never ring the bell
bell-style visible  # use visual bell, if available

show-all-if-ambiguous on  # list all completions instead of ringing the bell

Answer 3

我必须承认，我的名字我的文件，而不考虑选项卡完成，并改为调整我的冲动，打标签，直到我知道我已经输入的字符足以得不到标签傻。

Answer 4

与公共性文件目录通常是一个好主意，但可能并不总是可行的。在这种情况下，行之有效的简单方法是把共性的后缀，而不是前缀。例如，我的名字我的单元测试“_test.py”作为后缀。轮做它的其他方式（例如test_foo.py）将残端tab完成对于每个测试文件。

您可以将此理念扩展到一般情况下为扁平化层级。例如，如果你的类层次结构Person->Employee->Programmer，你能避免调用测试programmer_employee_person_test.py镜像代码的目录结构。再次，该标识符的更一般的部件以后进来的名称。

Answer 5

我倾向于去与任何有意义的代码，而不是标签完成的组织 - 这可以根据问题的代码不同，因此很难直接回答，而是使用正确的子目录确实让生活更轻松。我同意唐。

相反，我使用导航工具，如find . -name {expr}（文件名），grep -r {expr} *（功能DEFS，PROTOS和使用）的组合的来源以及它们。它可以编写shell脚本，切实做好查找/使用在您的整个源代码树sed i 's/find/replace'替换操作。我有一个小夹在我的〜/提供这样一些有用的脚本的路径。

我结合这与像Eclipse IDE中进行编辑，或VIM，这取决于我在做什么。我喜欢都同样，真的，因为我用两个不同的目的。

有关Emacs的，我已经试过了，我不喜欢它。这是远太大和复杂，我有更重要的事情不是去学习如何使用它做的（好吧，让我们停在那里，然后才开始“真正的程序员使用......”的讨论）。所以我不能对你链接到Emacs的工具发表评论。我想尝试一下，看看是否有帮助。

Answer 6

您可以使用菜单完成，而不是完整的：

bind '"\C-i": menu-complete'
echo '"\C-i": menu-complete' >>~/.inputrc

Answer 7

我与其他答复同意在这里：不，一般来说，名称的文件，以方便完成或（什么是刚刚描述什么文件是做或暗示以外）表达的关系。

。

WRT的完成的：是的，它可以帮助使用类似的的冰柱 。有许多不同的方式灵活完成可以帮助 - 包括项目文件中进行搜索。参见，例如，的冰柱搜索 。

能够提供多个简单匹配模式（“陆续完成”）有助于太 - 这比拿出一个单一的，复杂的正则表达式要容易得多。同样地，能够排除对于某些模式（匹配“小打小闹非象“）是有帮助的。最后，文件名匹配它有时可以帮助能够匹配目录组件。