Нотация для названий функций
В Какао мне очень нравится, как используется возможность «Объектного Си» вставлять параметры прямо в название методов («селекторов»):
[someObject doStuffWithThing:x andThing:y usingParameter:z];
Получаются нормальные предложения. В большинстве языков так делать нельзя, однако формулировать названия функций так, чтобы параметры продолжали предложение, никто не запрещает. Если параметр всего один, или параметры образуют очевидную последовательность, то это добавит удобочитаемости. Я принял нотацию, согласно которой название функции завершается подчёркиванием, если оно составлено по такому принципу. В этом случае открывающая скобка не отбивается пробелом (вообще, я всегда отбиваю; меня страшно бесит, что в ЦССе так делать нельзя).
Пример перевода:
e2_note_by_id ($id) → e2_note_with_id_($id).
А так могли бы выглядеть некоторые функции с несколькими параметрами:
do_stuff_at_($x, $y),
do_stuff_with_date_($year, $month, $day).
Если параметры не образуют очевидной последовательности или нормально переформулировать смысл функции не удаётся, то функция пишется «по старинке», без подчёркивания в конце:
e2_store_cache ($path, $data, $secure).
А какие вы используете хитрости для повышения удобочитаемости кода?
Я для повышения удобочитаемости кода не заканчиваю имена функций знаком подчеркивания (все единообразно, это важнее смысловых догадок, которые могут возникать при медитации на название функции), а также не отбиваю открывающую скобку пробелом (в математике скобка примыкает к обозначению функции, даже если оно состоит из нескольких символов).
Ути-пути.
В математике аргумент функции вообще в скобки не берут.
Именованные параметры есть не только в Objective C. Но и в языках без их явной поддержки можно реализовать что-то подобное при помощи цепочек вызовов (Zend_Db) или при помощи граничных объектов (Win32API).
А самым действенным приемом по повышению удобочитаемости кода является ограничение вложенности до минимума (тогда глубоко вложенные участки кода просто выделяются в отдельные методы)
В яваскрипте довольно популярен способ называть какие-нибудь хитрые переменные так, чтобы в итоге было похоже на английский язык. Сегодня встретил аналогичный прием в яве:
Было:
assertTrue(expected);
Стало:
assertThat(expected, is.TRUE);
Угу, в математике сплошь и рядом написано «f x» :)
В данном случае скобки просто подсказывают, что f — это функция. Когда используется известная функция, скобки ставят только программисты, а нормальные люди пишут: sin x, ln y и т. д.
Илья, а можно следить за дискуссией по почте, если сказать нечего? :-)
Ну, у вас уже получится :-) А вообще — РСС есть.
Удобочитаемость — это спорная очень область, кому-то так удобно, а кому-то эдак.
В ЦССе скобки от селекторов и значения от параметров можно как отбивать пробелами, так и не отбивать, что же вас бесит?
Я говорю о круглых скобках. Вариант ##url (’path/to/file.jpg’)## не сработает.
Я не понял, чего в ЦСС сделать нельзя? Какую скобку?
Заметил, что удобочитаемость повышают пропущенные строки (больше, чем традиционный отступ).
На одной кафедре видел код (PL/1) вообще без отступов. Доцент сказал: «Место экономлю». Год 1992!
Я тоже ставлю пробел перед круглой скобкой (открывающей) вот почему.
Не знаю можно ли назвать хитростью, я использую именованные параметры:
%%e2_store_cache(array(
’path’ => ,
’data’ => ,
’is_secure’ =>
));%%
Для булевых значений обязательно ставлю префикс is_ или has_
Вместо длинных цепочек if люблю использовать and:
%%$is_success = (
$photo_id
and extract_photo($photo_id, $working_copy = temporary_file())
and transform_image(array(’src_file’ => $working_copy, ’rotate’ => $angle))
and store_photo($photo_id, $working_copy));%%
Я вместо ’is_secure’ написал бы ’secure?’.
А скобку бы закрыл на том же уровне, что и открыл:
%%$is_success = (
$photo_id
and extract_photo ($photo_id, $working_copy = temporary_file ())
and transform_image (array (
’source-file’ => $working_copy,
’rotate’ => $angle
))
and store_photo ($photo_id, $working_copy)
);%%
Надо сказать, что такая цепочка не отличается читаемостью и понятностью.
Если позволяет язык, можно переходить от передачи параметров последовательной цепочкой к передаче через хеш.
%%^someObject.doStuff[
$.theThing[$x]
$.anotherThing[$y]
$.someParam[$z]
]%%
Также разумно комбинировать:
%%^sorcerer.makeMagic[$badassWand][
$.backupWand[$wand4]
$.useExtraSpells(1)
]%%
Илья, я таки не получаю комментарии на почту, хотя отметил соответствующий флажок.
Вероятнее всего из-за того, что в мой адрес почты выглядит так: blah+blah.blah@blah.com
Есть ли возможность это исправить?
А в спаме их тоже нет?
Я смотрю на то, какой стиль предпочитают люди, и вижу, что наиболее близок в этому идеалу, к наилучшей удобочитаемости и ясности кода приблизился язык Ruby.
Даже вот Илья привёл пример, когда вместо «is_secure» лучше написать «secure?».
Руби, при всей своей концептуальной красоте, совершенно нечитаем. То есть, не зная Руби, даже опытный программист не разберётся, что делает программа, глядя на её код. Вопросительный и восклицательный знаки в названиях методов — случайное исключение.
Илья, письма таки в спаме были, спасибо. :-)
И ссылку на РСС для комментов я нашел.
По поводу комментариев в РСС. Добрая половина комментариев (а именно — те, которые написаны Ильей Бирманом), не входит в ленту, что есть нехорошо. Есть ли возможность и желание это исправить?
Илья, не соглашусь: я, собравшись ознакомиться с «Руби», смог читать примеры кода на нём без затруднений.
$is_secure = $something[’secure?’]; // не хочется смешивать
Насчёт руби: там мало визуального шума, поэтому читается он без затруднений, но вот пишется совсем не так легко, как некоторые хотят показать. Обилие в словесного поноса про easy, sexy, fun никак не влияет на способность к запоминанию. Я например до сих пор не усвоил, как там пишется конструкция if.
!!А какие вы используете хитрости для повышения удобочитаемости кода?!!
Я использую висячие комментарии. :)
Я по этому же принципу строки, начинающиеся с подчёркивания, пишу на один пробел раньше, чтобы подчёркивание висело налево.
Алисей Лебедев, а если «store_photo» закончится неудачей, и нужно будет почистить хвосты от extract_photo и transform_image?
«Тоже»? Вы говорите о разных вещах: Илья — о вызовах и/или объявлениях функций, а ты — об управляющих конструкциях языка. Эти понятия практически всегда разделяются. Лично мне противно видеть пробел перед скобкой в первом случае и противно НЕ видеть пробел во втором. Этого мнения придерживаются и некоторые другие, например:
http://www.python.org/dev/peps/pep-0008/ «Whitespace in Expressions and Statements»
http://pear.php.net/manual/en/standards.funcalls.php + http://pear.php.net/manual/en/standards.control.php
Да, а подчеркивание на конце имени функции — это детство какое-то. Это тупо лишняя сущность, зачем-то повторно (кроме скобки) отделяющая название вызываемой функции от списка аргументов.
Она не отделяет, а, наоборот, соединяет.