Соглашение об именовании файлов Unix для эффективного завершения табуляции?

Question

Мне кажется, что я часто называю файлы так, что мой компьютер постоянно издает звуковой сигнал во время программирования, потому что заполнение вкладок неоднозначно. Прежде чем заняться программированием на Unix, я обычно называл связанные файлы с одинаковым префиксом, чтобы указать их отношение. Теперь я должен переосмыслить свой подход к структурам и именам папок и файлов для более эффективного программирования.

Какие эвристики или правила вы применяете при программировании для упрощения заполнения табуляции? Используете ли вы какие-либо инструменты, чтобы сделать табуляцию более гладкой (например, emacs icicles )?

РЕДАКТИРОВАТЬ: Wow, спасибо за фантастические идеи. Я думаю, что все возможные мои слабые места были учтены в ответах. Я принял тот, который кажется лучшим улучшением производительности, хотя их все стоит прочитать.

Answer 1

Я обычно работал над проектами, в которых все связанные файлы находятся в одном каталоге , а сами имена файлов специализированы для указания их содержимого.

Конечно, напрашивается вопрос, почему вы выполняете табуляцию имен файлов? Если вы просматриваете исходный код, есть TAGS , CEDET и множество других утилит , которые позволят вам обойти имя файла и перейти непосредственно к функция / переменная, которую вы действительно ищете.

Все зависит от того, что вы действительно пытаетесь сделать, и поиск определенного файла обычно является средством достижения другой цели.

Answer 2

В общем

setterm -blength 0

отключит звуковой сигнал терминала. Экран GNU и некоторые графические терминалы имеют свои собственные настройки звукового уведомления.

Специально для Bash и другого Readline -использующего программного обеспечения поведение завершения вкладки можно изменить с помощью файлов конфигурации $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

Каталоги для файлов со схожестью обычно являются хорошей идеей, но не всегда возможны. В этих случаях простой подход, который хорошо работает, заключается в добавлении общности в суффикс, а не в префикс. Например, я называю свои юнит-тесты суффиксом _test.py. Если сделать это в обратном порядке (например, test_foo.py), это завершит ввод табуляции для каждого тестового файла.

Вы можете распространить эту идею на общий случай уплощения иерархий. Например, если у вас есть иерархия классов Person->Employee->Programmer, вы можете избежать зеркального отображения структуры каталогов кода, вызвав тест programmer_employee_person_test.py. Опять же, более общие компоненты идентификатора встречаются позже в имени.

Answer 4

Я должен признать, что я называю свои файлы безотносительно к завершению табуляции и вместо этого настраиваю свое желание нажимать на табуляцию, пока не узнаю, что набрал достаточно символов, чтобы не становиться глупым.

Answer 5

Я согласен с другими ответами здесь: в общем, не называйте файлы, чтобы облегчить завершение или выразить отношения (кроме того, что подразумевается просто описанием того, для чего предназначен файл).

Wrt завершение : Да, это может помочь использовать что-то вроде Сосульки . Существует много разных способов, которыми может помочь гибкое завершение, в том числе для поиска в файлах проекта. См., Например, Поиск сосулек .

Возможность предоставления нескольких простых шаблонов сопоставления (« прогрессивное завершение ») также помогает - это намного проще, чем придумывать одно сложное регулярное выражение. Также полезно иметь возможность исключать совпадения для определенных шаблонов (« отщепление не-слона »). Наконец, для сопоставления имени файла иногда может также помочь совпадение компонентов каталога.

Answer 6

Вы можете использовать полное меню вместо полного:

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

Answer 7

Я склоняюсь к тому, что имеет смысл для организации кода, а не к завершению табуляции - это может варьироваться в зависимости от рассматриваемого кода, поэтому трудно дать прямой ответ, но использование надлежащих подкаталогов делает жизнь проще Я согласен с Доном.

Вместо этого я перемещаюсь по источникам, используя такие инструменты, как find . -name {expr} (имена файлов), grep -r {expr} * (функция def, protos и использование) и их комбинации. Можно написать сценарии оболочки для эффективного выполнения операций поиска / замены с использованием sed i 's/find/replace' по всему дереву исходного кода. У меня в папке ~ / есть небольшая папка, в которой есть несколько таких полезных скриптов.

Я комбинирую это с IDE, такими как Eclipse для редактирования или VIM, в зависимости от того, что я делаю. Мне нравятся оба одинаково, действительно, поскольку я использую оба для различных целей.

Что касается Emacs, я пробовал, мне это не нравится. Он слишком большой и сложный, и у меня есть более важные дела, чем научиться его использовать (хорошо, давайте остановимся, прежде чем мы начнем обсуждение «настоящие программисты используют…»). Поэтому я не могу комментировать инструмент Emacs, с которым вы связались. Я думаю, попробуйте и посмотрите, поможет ли это.