приказы, начинающиеся со слова "Дай"
Nov. 20th, 2014 01:44 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
sab123(сабж сперт из http://spamsink.livejournal.com/559873.html)
Как я, ^&*^&*, ненавижу длинные имена переменных. У этого начинания есть только одно достоинство (можно примерно понять, о чем речь, встретив одноразовое упоминание, что полезно для классов, но не очень-то нужно для переменных) и множество недостатков:
1. Текст делается длиннее и кашеобразнее, в нем труднее выцеплять глазом стркутуру. Самый ужас - если сочетать с Корпоративным Стандартным Стилем с ограниением 80 символов на строку, как в Гугеле.
2. Имена делаются малоотличимы на глаз. Я при нормальном чтении различаю примерно 7 первых символов, остальное превращается в некий неразличимый серый туман. Чтобы отличать этот туман, надо очень сильно напрягаться. Поэтому я всегда стараюсь вынести отличия имен по-возможности вперед.
3. Имена, составленные из слов, не запоминаются. Запоминается их смысл, а потом попробуй догадаться, как именно он сформулирован. Вот буквально сейчас пишу переменную RawEtlFile, и двумя минутами позже пытаюсь вспомнить, оно RawEtlFile или RawFileEtl, или EtlRawFile. А вот было бы оно названо "retlf", или хотя бы "retlfile" - оно бы стало самостоятельным словом и проблемы с запоминанием бы исчезли.
4. Да и просто при набирании делается больше опечаток.
А длинные имена опций к командам (см. PowerShell) - все то же самое, только еще хуже.
Как я, ^&*^&*, ненавижу длинные имена переменных. У этого начинания есть только одно достоинство (можно примерно понять, о чем речь, встретив одноразовое упоминание, что полезно для классов, но не очень-то нужно для переменных) и множество недостатков:
1. Текст делается длиннее и кашеобразнее, в нем труднее выцеплять глазом стркутуру. Самый ужас - если сочетать с Корпоративным Стандартным Стилем с ограниением 80 символов на строку, как в Гугеле.
2. Имена делаются малоотличимы на глаз. Я при нормальном чтении различаю примерно 7 первых символов, остальное превращается в некий неразличимый серый туман. Чтобы отличать этот туман, надо очень сильно напрягаться. Поэтому я всегда стараюсь вынести отличия имен по-возможности вперед.
3. Имена, составленные из слов, не запоминаются. Запоминается их смысл, а потом попробуй догадаться, как именно он сформулирован. Вот буквально сейчас пишу переменную RawEtlFile, и двумя минутами позже пытаюсь вспомнить, оно RawEtlFile или RawFileEtl, или EtlRawFile. А вот было бы оно названо "retlf", или хотя бы "retlfile" - оно бы стало самостоятельным словом и проблемы с запоминанием бы исчезли.
4. Да и просто при набирании делается больше опечаток.
А длинные имена опций к командам (см. PowerShell) - все то же самое, только еще хуже.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2014-11-20 10:05 pm (UTC)Ну а как давать имена, чтобы не потерять читабельность, так это всегда было скорее искусством и к коротким именам это отностися в той же степени, что и к длинным, просто вид сбоку. Есть например эвристика - чем меньше область видимости имени, тем оно короче. Переменную, область видимости которой две строчки, можно и одной буквой назвать. Локальные переменные функции или приватные члены класса видимо можно сокращать, если функция/класс не простыня на сотню строк.
no subject
Date: 2014-11-20 11:43 pm (UTC)no subject
Date: 2014-11-21 01:31 am (UTC)например, мне нравится как подсказки сделаны в VisualAssist для Visual Studio, но не нравится как то же самое сделано в XCode
разница - вижлассист дополняет исходя из свойств объекта редактирования, экскод - все что попадется (просто строку)
в виме есть автодополнение, но у него скоуп маловат (или я не умею готовить)
а по переменным – пусть лучше длинное название, но понятное
то есть локально-то можно хоть a, b именовать, но поля в структуре должны называться так, чтобы не допускать двоякое трактование, то же самое с именами функций (ну, more or less)
no subject
Date: 2014-11-20 10:16 pm (UTC)Угу, за длинные имена опций без альтернативных коротких надо отправлять на принудительные работы секретарём-машинисткой месяцев эдак на несколько. :)
no subject
Date: 2014-11-20 11:30 pm (UTC)no subject
Date: 2014-11-20 11:41 pm (UTC)no subject
Date: 2014-11-20 11:54 pm (UTC)Потому что мы были банда. Наехали гурьбой на Криса Лопеса.
no subject
Date: 2014-11-21 12:58 am (UTC)no subject
Date: 2014-11-21 01:39 am (UTC)no subject
Date: 2014-11-21 02:53 pm (UTC)http://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s4.4-column-limit
no subject
Date: 2014-11-21 12:57 am (UTC)Честно говоря, что то подобное я подозревал. Теперь понятно, почему у них такой софт.
Называю переменные вроде $cur_search_path_arr и никаких проблем.
no subject
Date: 2014-11-21 02:53 am (UTC)no subject
Date: 2014-11-21 07:15 am (UTC)Естественно, нормальные слова читаются быстрее и проще, чем сокращения.
no subject
Date: 2014-11-21 07:47 am (UTC)no subject
Date: 2014-11-21 01:41 am (UTC)Конечно все хорошо в меру, и я совершенно согласен с идеей делать имена местных переменных и функций покороче.
Ну а ограничение на 80/120 символов в строку - это маразм конечно. Лет 20 назад может это и имело некоторый смысл когда мониторы были в 15", но сегодня это уже бессмысленно.
P.S. Помниться в конце 90х у меня один раз была проблема с длиной строки исходника. Я тогда пользовался древним редактором (он мне чем-то нравился), а тот редактор не любил строки длинней 255 символов. И я ругался по этому поводу с коллегой который мог запулять супер-длинные строки.
Но с тех очень давних времен проблем с длиной строки кода вроде никогда и не было:-)
no subject
Date: 2014-11-21 02:45 am (UTC)no subject
Date: 2014-11-21 02:54 am (UTC)Если с одним и тем же куском кода постоянно работать (например в процессе его активного написания), то человек читающий код быстро запомнит основные конструкты и имена, и будет удобней что-то покороче. Но если читать код в первый раз в жизни, то скорее удобней говорящие имена, которые сами внятно обьясняют что это такое.
Классический пример на эту тему - дизайн интерфейса Амазон vs Photoshop. Сайт Амазона сознательно сделан так чтобы любой человек мог успешно выполнить покупку даже если он видит сайт амазона в первый раз в жизни. Но из-за этого же сайт Амазона - весьма verbose, с минимальным количеством кнопочек на каждом экрена и т.п.
У фотошопа круг пользователей совершенно другой. Пользоваться фотошопом - совсем не просто, там есть куча фич и фильтров, есть миллион шорткатов, и всякие не очень очевидные иконки. Но UX фотошоп просто оптимизирован для регулярных пользователей, которые уже давно заучили эти шорткаты наизусть и точно знают что и как делать.
Это не идеальная аналогия, но имхо нечто общее тут есть.
no subject
Date: 2014-11-22 11:16 pm (UTC)no subject
Date: 2014-11-23 12:10 am (UTC)Лично мне, если читать чей-то чужой код, длинные "говорящие" имена как раз очень полезны - я тогда могу сразу представить себе что это такое, и не требуется постоянно прыгать к дефинициям пытаясь понять что же это за штука такая.
И еще хорошо если в дефиниции есть хоть какой-то коммент, который обьясняет что и как. А то бывает приходится догадываться о смысле какой-нибудь переменной или функции по тому как она используется.
no subject
Date: 2014-11-23 12:48 am (UTC)no subject
Date: 2014-11-21 07:53 am (UTC)Мониторы размером 15" и менее сегодня тоже в ходу. Ноутбуки же.
no subject
Date: 2014-11-21 03:34 pm (UTC)Попробуйте на современном экране (хоть ноутбук, хоть обычный десктоп) открыть консольное окно в 80х25 с комфортным размером фонта - это окно будет выглядеть очень маленьким, и будет занимать только часть экрана. А 20 лет назад 80х25 было стандартом, именно из-за размера экрана.
no subject
Date: 2014-11-21 03:44 pm (UTC)no subject
Date: 2014-11-21 06:03 pm (UTC)