приказы, начинающиеся со слова "Дай"

[sab123]

(сабж сперт из http://spamsink.livejournal.com/559873.html)

Как я, ^&*^&*, ненавижу длинные имена переменных. У этого начинания есть только одно достоинство (можно примерно понять, о чем речь, встретив одноразовое упоминание, что полезно для классов, но не очень-то нужно для переменных) и множество недостатков:

1. Текст делается длиннее и кашеобразнее, в нем труднее выцеплять глазом стркутуру. Самый ужас - если сочетать с Корпоративным Стандартным Стилем с ограниением 80 символов на строку, как в Гугеле.

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

3. Имена, составленные из слов, не запоминаются. Запоминается их смысл, а потом попробуй догадаться, как именно он сформулирован. Вот буквально сейчас пишу переменную RawEtlFile, и двумя минутами позже пытаюсь вспомнить, оно RawEtlFile или RawFileEtl, или EtlRawFile. А вот было бы оно названо "retlf", или хотя бы "retlfile" - оно бы стало самостоятельным словом и проблемы с запоминанием бы исчезли.

4. Да и просто при набирании делается больше опечаток.

А длинные имена опций к командам (см. PowerShell) - все то же самое, только еще хуже.

Comments

[alll]

Просто без поддержки достаточно мощного IDE и приличного монитора (угу, пусть засунут эти 80 символов в строке на полку с пачками перфокарт, от которых это ограничение и произошло) стиль с длинными именами не имеют смысла. Например в моей ide достаточно набрать etl чтобы получить подсказку с вариантами. Ну или в крайнем случае вызвать горячей клавишей поиск и начать набирать "etl raw file", оно само отфильтрует список идентификаторов по вхождениям в идентификатор подстрок, разделённых пробелами. Долго объяснять, но очень просто и быстро делать. Опечатки это исключает почти полностью, да и букв набирать надо гораздо меньше, чем полное имя.

Ну а как давать имена, чтобы не потерять читабельность, так это всегда было скорее искусством и к коротким именам это отностися в той же степени, что и к длинным, просто вид сбоку. Есть например эвристика - чем меньше область видимости имени, тем оно короче. Переменную, область видимости которой две строчки, можно и одной буквой назвать. Локальные переменные функции или приватные члены класса видимо можно сокращать, если функция/класс не простыня на сотню строк.

[alll]

> А длинные имена опций к командам (см. PowerShell) - все то же самое, только еще хуже.

Угу, за длинные имена опций без альтернативных коротких надо отправлять на принудительные работы секретарём-машинисткой месяцев эдак на несколько. :)

[juan-gandhi.livejournal.com]

В гугле на джаве 100 лимит.

[sab123.livejournal.com]

Мне казалось, что конкретно на ней - даже 120. А на остальных - 80.

[sab123.livejournal.com]

Ну да, так и делаю, чем локальнее тем короче. А IDE - зло, и поиск имен в них нифига не помогает. Он прерывает поток печатания, и я, даже когда приходится использовать IDE, его люблю наоборот нафиг выключать.

[juan-gandhi.livejournal.com]

А, 120. Забыл уже.

Потому что мы были банда. Наехали гурьбой на Криса Лопеса.

[vit-r.livejournal.com]

с ограниением 80 символов на строку, как в Гугеле.

Честно говоря, что то подобное я подозревал. Теперь понятно, почему у них такой софт.

Называю переменные вроде $cur_search_path_arr и никаких проблем.

[vit-r.livejournal.com]

Угу. "В камере прорубили второе окно и поставили решётку с узорами"

[vaddimka.livejournal.com]

зависит от IDE на самом деле
например, мне нравится как подсказки сделаны в VisualAssist для Visual Studio, но не нравится как то же самое сделано в XCode
разница - вижлассист дополняет исходя из свойств объекта редактирования, экскод - все что попадется (просто строку)
в виме есть автодополнение, но у него скоуп маловат (или я не умею готовить)

а по переменным – пусть лучше длинное название, но понятное
то есть локально-то можно хоть a, b именовать, но поля в структуре должны называться так, чтобы не допускать двоякое трактование, то же самое с именами функций (ну, more or less)

[juan-gandhi.livejournal.com]

Совершенно согласен.

[qvb.livejournal.com]

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

Конечно все хорошо в меру, и я совершенно согласен с идеей делать имена местных переменных и функций покороче.

Ну а ограничение на 80/120 символов в строку - это маразм конечно. Лет 20 назад может это и имело некоторый смысл когда мониторы были в 15", но сегодня это уже бессмысленно.

P.S. Помниться в конце 90х у меня один раз была проблема с длиной строки исходника. Я тогда пользовался древним редактором (он мне чем-то нравился), а тот редактор не любил строки длинней 255 символов. И я ругался по этому поводу с коллегой который мог запулять супер-длинные строки.

Но с тех очень давних времен проблем с длиной строки кода вроде никогда и не было:-)

[sab123.livejournal.com]

Обратите внимания, что две из четырех проблем - то, что делает код с длинными именами непригодным для чтения.

[sab123.livejournal.com]

Но ведь потом это кому-то придется читать и мучаться.

[qvb.livejournal.com]

ИМХО для чтения тут работает классический сценарий оптимизации под нового человека.

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

Классический пример на эту тему - дизайн интерфейса Амазон vs Photoshop. Сайт Амазона сознательно сделан так чтобы любой человек мог успешно выполнить покупку даже если он видит сайт амазона в первый раз в жизни. Но из-за этого же сайт Амазона - весьма verbose, с минимальным количеством кнопочек на каждом экрена и т.п.

У фотошопа круг пользователей совершенно другой. Пользоваться фотошопом - совсем не просто, там есть куча фич и фильтров, есть миллион шорткатов, и всякие не очень очевидные иконки. Но UX фотошоп просто оптимизирован для регулярных пользователей, которые уже давно заучили эти шорткаты наизусть и точно знают что и как делать.

Это не идеальная аналогия, но имхо нечто общее тут есть.

[vit-r.livejournal.com]

Перед "длинные слова его только огорчали" в оригинале стоит "в голове его были опилки".

Естественно, нормальные слова читаются быстрее и проще, чем сокращения.

[alll]

Судя по $ в начале это либо перл, либо похапэ, либо эзотерика. Так что читающим мучаться придётся по-любому, как переменные не называй. ;)

[alll]

> Лет 20 назад может это и имело некоторый смысл когда мониторы были в 15"

Мониторы размером 15" и менее сегодня тоже в ходу. Ноутбуки же.

[paster.livejournal.com]

100
http://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s4.4-column-limit

[qvb.livejournal.com]

Ноутбук при работе находится гораздо ближе к глазам, за счет чего видно много больше чем на 15" на столе. Телефон еще меньше, но за счет расстояния до глаз там тоже много чего видно.

Попробуйте на современном экране (хоть ноутбук, хоть обычный десктоп) открыть консольное окно в 80х25 с комфортным размером фонта - это окно будет выглядеть очень маленьким, и будет занимать только часть экрана. А 20 лет назад 80х25 было стандартом, именно из-за размера экрана.

[alll]

Что разрешения матриц экранов выросли - спору нет.

[sleepy-drago.livejournal.com]

инструменты позволяют набирать '.etl' и выбирать то что там было вне зависимости от того оно там в начале, середине или конце. Если чтото надо выяснять то делаю полнотекстовый поиск не доверяя особенно инструментам которые пытаются ограничивать контексты. Часто таким образом находятся аналогичные вещи в других контекстах. Возможность легко находить всяческие апи и сразу видеть их документацию (без лишних телодвижений) очень сильно облегчает вхождение во чтото. Когда сам пишешь то все эти заморочки можно и отключить. все равно сам себе словарь составляешь =)

[sab123.livejournal.com]

Так ить дело в том, что длинные имена читать и различать невозможно, не говоря уже про запоминать.

[qvb.livejournal.com]

Почему невозможно?

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

[sab123.livejournal.com]

Потому что они все выглядят одинаково.