Янв
20
5 правил именования функций
Категория: Культура кода Автор: Александр Никитин Опубликовано: 20-01-2010
Метки: правила именования, функции
Сегодня я решил раскрыть тему именования функций. Кое-что мною уже было описано в этой статье, здесь же речь пойдет исключительно о тех блоках кода, которые мы выделяем в отдельные функции, процедуры, методы классов.
Итак, главное правило – имя функции должно ясно описывать то, что она делает. Посмотрим, какими средствами этого можно достичь.
- Имя функции должно отражать все, что она делает. Если функция выполняет множество действий, которые напрямую между собой не связаны, то имя получится длинное и несуразное. Например: ConnectToDatabaseAndOpenFileAndWriteDatabaseRecordsCountToFile(); Такое километровое название функции – признак того, что вам стоит задуматься о её содержании и выделить ряд более мелких функций.
- Откажитесь от неоднозначных и бессмысленных названий. Некоторые глаголы могут описывать практически любые действия внутри функций. Например, Calculation(), HandleInput() или ProcessData(). С одной стороны, название функции может согласовываться с содержимым, но догадаться о содержимом по названию практически невозможно. Поэтому вместо Calculation() нужно писать что-то более подробное, типа GetSolutionOfEquation().
- Не используйте нумерацию для функций, которые решают схожие задачи. Бывает, что функции выполняют одно и то же, но разными способами. Например, мы хотим написать функцию факториала и реализовали два варианта – с помощью цикла и с помощью рекурсии. Не нужно называть функции Fact1() и Fact2(). Дайте более осмысленные названия FactCicle() и FactRecursion().
- Не старайтесь искусственно ограничить длину имени функции. Согласно исследованиям оптимальная длина переменной – это 9-15 символов. Функция, как вы понимаете, несет ещё большую смысловую нагрузку, соответственно и длина у неё может быть ещё больше. Важно иметь «говорящие» названия функций, а не определенную длину.
- Используйте описание возвращаемого значения для именования функции. Если функция что-то возвращает, это должно быть ясно из названия. Пример хороших имен: sin(), GetMaxValue(), monitor.IsReady(), iterator.NextElement().
Что ж, это явно не все правила, которых следует придерживаться. Так что ждите её одной статьи, в которой я продолжу делиться секретами именований.
Напоследок пара интересных ссылок:
Рассказ одной модели по совместительству… программистки о том, как это её так угораздило 
Саш, у меня есть небольшое замечание по поводу длинных названий функций (ты ведь знаешь, как я их люблю
Твой пример ConnectToDatabaseAndOpenFileAndWriteDatabaseRecordsCountToFile() очень хорошо иллюстрирует именно то, о чём ты написал — функция делает несколько неявно и слабо связанных между собой действий. Легко определить такую функцию можно по наличию слова «And» в названии. Когда ты действительно называешь функцию исходя из того, что она делает, вряд ли там когда-то вообще может появиться слово «And» (если, конечно, не рассматривать логическую операцию «И»
. На мой взгляд, название функции wrapDataIntoEnvelopeWithinSession() (реальный пример) хоть и длинное, но ясно отражает, что делает функция и чем она отличается от функции wrapDataIntoEnvelope().
Я с тобой согласен, WithinSession в данном случае, скорее всего, важная информация о функции.
Вот, кстати, ещё одна мысль. Мне кажется, ещё важно грамотно называть функции по-английски (у вас даже глава в книге под это запланирована) и не использовать транслит ни в коем случае. Поэтому, правильно будет всё-таки FactLoop()
Ещё хитрый случай — глагол log in. Многие считают, что это уже одно слово (login) и называют функцию, например, isLoginned(), что неверно. Правильное название — isLoggedIn().
Ещё я получаю какое-то особенное удовольствие от таких названий функций, которые позволяют именно читать текст программы. Самый простой пример (он есть в статье) — начинать названия функций, возвращающих булевские значения, со слова «is», «has» и т. п. Что получается (например):
if (monitor.isReady())
То есть мы читаем практически обычный текст: «если монитор готов». Сравним с другим распространённым вариантом:
if (monitor.getReady())
Тут уже получается «если монитор получить готов». Звучит немного странновато, да?
Такой подход очень распространён в Objective C. Там даже сама синтаксическая конструкция вызова метода (там это называется отправкой сообщения) заточена именно под это. Сравните (опять же, примеры из жизни):
imageProcessor.processImageUsingFilterChain(i, fc, 0.5);
и
[imageProcessor processImage: i usingFilterChain: fc withMultiplier: 0.5];
Несмотря на то, что я по-дурацки назвал переменные, смысл строчки ясен после первого же прочтения.
Андрей, совершенно согласен с тобой. Я помню твой код по лабораторным в Бауманке (как, наверное, большинство наших однокурсников
). Его читать легко и приятно, что говорит о том, что ты правильно называешь функции.
Хорошие имена переменных и функций получаются на этапах детализации алгоритма методом «сверху вниз». Здесь можно получить и разумную краткость и в то же время приемлемую содержательность имен. Плюс к тому комментарии избыточными не бывают и пишутся также на этапе разработки. Хорошо закоментированный код вкупе с правильно расставленными отступами сильно экономит время отладки программы.