Трудность при именовании функций [дубликат]
8 ответов
Для именования функций просто избегайте использования простых существительных и называйте их после глаголов. Некоторые указатели:
- Имена функций явно уникальны, например нет
validateInput ()иvalidateUserInput (), поскольку трудно сказать, что одно делает над другим. Кроме того, избегайте очень похожих персонажей, например цифру 1 и строчную букву l. Иногда это имеет значение. - Вы работаете над проектом с несколькими людьми? Вам также следует потратить некоторое время на изучение соглашений об именах, например, если в имени функции должны быть символы подчеркивания, должно быть camelCase и т. Д.
- Венгерская нотация - плохая идея; избегайте этого.
- Подумайте, что делает функция. На ум приходит та сплоченность, о которой вы упомянули в своем вопросе. Как правило, функции должны делать только одно, поэтому не называйте это
constructCarAndRunCar (), а вместо этого используйте одну функцию, которая создает, а другая - запускает. Если ваши функции находятся, скажем, между 20 и 40 строками, все в порядке. - Иногда, и это зависит от проекта, вы можете также захотеть поставить перед именами функций префикс класса, если класс является чисто процедурным (состоит только из функций). Итак, если у вас есть класс, который заботится о запуске моделирования, назовите ваши функции
sim_pauseSimulation ()иsim_restartSimulation (). Если ваш класс основан на ООП, это не проблема. - Не используйте базовые структуры данных в самих функциях; их следует абстрагировать. Вместо использования таких функций, как
addToVector ()илиaddToArray (), пусть они будутaddToList (). Это особенно верно, если это прототипы или структуры данных могут измениться позже. - Наконец, будьте последовательны в своих соглашениях об именах. Если после некоторого размышления вы придете к соглашению, придерживайтесь его. Когда думаешь о несовместимых именах функций, на ум приходит PHP.
Удачного кодирования! :)
Иногда может случиться так, что ваша функция слишком велика и поэтому выполняет слишком много задач. Попробуйте разделить свою функцию на другие функции, и, возможно, будет яснее, как вызывать каждую отдельную функцию.
Не беспокойтесь о том, чтобы называть вещи одним или двумя словами. Иногда, если функции делают что-то, что можно объяснить в виде небольшого предложения, продолжайте и назовите функцию немного длиннее, если это поможет другим разработчикам понять, что происходит.
Еще одно предложение - получить обратную связь от других. Часто другие люди, которые приходят с другой точки зрения и впервые видят функцию, лучше понимают, как ее вызывать.
Я следую следующему правилу: Имя в соответствии с целью (Почему? - дизайнерское решение), а не по содержанию (Что, Как? - можно увидеть в коде ).
Для функций это почти всегда действие (глагол), за которым следует существительное параметров и (или результатов. (Не по теме, но для переменных не используйте "arrayOfNames" или "listOfNames", это информация о типе но просто «имена») . Это также позволит избежать несоответствий, если вы частично реорганизуете код.
Для заданных шаблонов, таких как создание объекта, будьте согласованы и всегда используйте одно и то же имя, например «Create. .. "(а не иногда" Распределить ... "или" Построить ... ", иначе вы или ваши коллеги в конечном итоге почешете себе рану на голове)
Дайте ему лучший шанс и пересмотрите его позже, если он все еще не подходит.
Мне легче называть функции, когда мне не нужно сокращать количество слов. Пока вы не используете javascript для стартовой страницы Google, вы можете использовать более длинные имена.
Например, у вас есть метод dequeueReusableCellWithIdentifier и mergeChangesFromContextDidSaveNotification в структуре apples какао.
Пока ясно, что делает функция, вы можете назвать ее как хотите и реорганизовать позже.
Почти так же важно, как и имя функции, что вы согласны с комментариями. Многие IDE будут использовать ваши правильно отформатированные комментарии не только для предоставления контекстно-зависимой справки для функции, которую вы можете использовать, но и для создания документации. Это бесценно при возвращении к проекту после длительного периода или при работе с другими разработчиками.
В академической среде они служат хорошей демонстрацией ваших намерений.
Хорошее практическое правило - [глагол] returnDescription. Это легко сделать с функциями типа GetName () и не может применяться повсеместно. Трудно найти баланс между ненавязчивым и информативным кодом.
Вот руководство по соглашению .Net , но оно применимо к большинству языков.
Перейдите на www.thesaurus.com и попробуйте найти более подходящее имя, используя синонимы.
По моему собственному практическому правилу, если имя функции слишком длинное, оно должно быть преобразовано в новый объект. Тем не менее, я согласен со всеми сообщениями выше. кстати, хороший вопрос нуба