Я стараюсь быть достаточно описательным с именами функций, где это возможно. Это иногда приводит к именам функций в диапазоне от 20 до тридцати символов, таких как «GetActionFromTypeName» или «GetSelectedActionType». В какой момент функции становятся слишком длинными для управления (не слишком долго для компилятора)?Когда имя функции слишком длинное?
Если есть более короткий, но но описательный способ назвать функцию, то имя функции слишком велико.
Более конкретно, если существует слово, которое можно отнять без введения двусмысленности, это имя слишком длинное. –
До тех пор, пока функции фактически делают то, что их называют, они делают, и вы не собираетесь вводить заголовок для кода, я думаю, что это хорошо.
Когда он не делает все, что он говорит, что делает. ;)
Да; Стив Макконнелл в «Code Complete» (по крайней мере, в первом издании) согласен. – iokevins
Когда вы начинаете думать это :)
Я собирался сказать, когда вам нужно переместить глаза, но это почти то же самое. – job
Если вы не можете прочитать их вслух больше не переводя дыхания в середине = D
По моему мнению, это имя функции должно быть точно так, как если необходимо, чтобы описать, какова его цель. Если вы считаете, что имя функции слишком длинное, это может быть признаком того, что он пытается сделать слишком много вещей и должен быть реорганизован.
Я не думаю, что имя метода может быть слишком длинным, пока оно является описательным. Если имя метода превышает 40 символов, я увижу, могу ли я передать то же значение в меньшем количестве слов. Если нет, я буду жить с длинным именем ради ясности.
Я бы сказал, когда вы найдете определения аббревиатур для своих имен при обращении к ним. Я также нахожу это слишком много, когда люди начинают описывать пред-/пост-/параметрические условия в именах или давать подсказки о реализации. (например, getVersionInformationFormTheDatabase() или doSomethingWithoutCheckingFooFirst())
TheFunctionNameBecomesTooLongWhenItBecomesTooHardToReadItAndUnderstandIt, с другой стороны it_dependends_on_nameing_convention_how_hard_function_reading_is_sometimes_long_names_are_readable.
Я уверен, что видел две вышеупомянутые функции в стандартной библиотеке PHP. –
ИМХО, для функций важнее описать. IDE помогают избежать проблем с неправильным использованием или что-то в этом роде. Я думаю, что нормально использовать аббревиатуры иногда, если они согласованы по коду (без каких-либо аббревиатур для одной и той же вещи, ни же аббревиатуры для двух разных вещей.
Имя функции слишком длинное, когда оно начинается с более подробно описывают, что он делает, или когда это затрудняет читаемость кода.
Ну положить. Держите имена ясными и краткими, но все же наглядными. – Mark
Я думаю, что это особенно важно для публичных имен - они не должны быть слишком длинными, но долгое время это очень субъективно. более длинное и описательное имя, чем слишком короткое имя.
Для частных методов даже очень длинные имена, на мой взгляд, действительно не проблема.
Если имя функции «слишком длинное», то, скорее всего, сама функция слишком длинная и имеет слишком большую ответственность. Многие мудрые программисты говорят, что функция должна делать только одно и только одно. Функция, имя которой должно быть длинным, чтобы точно описать, что она делает, вероятно, будет хорошим кандидатом для рефакторинга в multiple smaller and simpler private functions, который, следовательно, имеет более короткие имена.
Пытаясь избежать субъективности:
Когда имена получают быть около 1/3 всего, что типичная длина линии, то вы протягивать его. На 1/2 длины линии вы слишком далеко ушли. Один оператор на строку становится довольно жестким, когда имена занимают всю строку.
Кроме того, большинство IDE поддерживают завершение (тем самым экономя программиста от фактического ввода большинства имен), поэтому, что, по моему мнению, более важно, чтобы имя было как можно более уникальным, как только насколько это возможно.
Думаю, вам стоит больше беспокоиться о том, когда имя функции слишком короткое или недостаточно описательное. Пока ваша функция делает то, что описывает ее имя (и все, что указано), она хорошо известна. Я часто пишу функции с длинными именами, такими как getPropertyNameArrayFromObject (хотя я склонен подчеркивать, а не camelize), который можно было бы назвать getObjPropArr или чем-то другим, но не был бы таким дескриптивным. Я стараюсь держаться подальше от аббревиатур, потому что они становятся двусмысленными, когда вы работаете над чем-то другим и возвращаетесь к коду.
С другой стороны, рассмотрим многие встроенные функции PHP, такие как stricmp, которые действительно должны быть названы в соответствии с строками caseInsensitiveStringComparison.
И есть случаи, когда я намеренно пишу очень короткие имена функций, которые не являются описательными вообще. Иногда я просто хочу, чтобы короткая функция JavaScript функционировала как ярлык. Например, я обычно псевдоним $ (id) для document.getElementById (id), потому что мне становится неловко печатать его.
Имена методов могут быть очень длинными в зависимости от языка (Maximum Method Name Length). В какой-то момент вы собираетесь использовать эту функцию или метод и напечатать предложение для имен функций, кажется ненужным.
Сохраните ваш код под контролем, используйте вместо него комментарии.
Если у компилятора есть некоторые ограничения на имена переменных, это часто 64 или 128 символов или где-то посередине. В прошлом 32 персонажа также были популярны. Если у них есть предел, они часто просто берут первые n символов и игнорируют остальных.
Общее правило заключается в том, что имя функции дает очень краткое описание того, что он делает. Большинство таких описаний должны легко вписываться в 32 символа. (Используйте CamelCase для разделения слов.) Поскольку большинство IDE теперь предоставляют Code Completion, ошибки с именами функций имеют тенденцию быть редкими. Но сделайте это проще, убедившись, что большинство функций отличаются друг от друга первыми 8 символами. Необходимо избегать таких событий, как DateCalculationAddMonth, DateCalculationAddWeek, DateCalculationAddYear и DateCalculationAddDay. Используйте AddMonthDateCalculation, AddWeekDateCalculation, AddYearDateCalculation и AddDayDateCalculation. (Кстати, это глупые примеры, но я надеюсь, что вы понимаете мой дрейф.)
На самом деле, возможно, лучше добавить (сгруппировать) свои функции в отдельный класс. С таким глупым примером вы можете просто создать класс DateCalculation и добавить в этот класс четыре (статические/классные) функции (AddMonth, AddWeek, AddYear и AddDay). В принципе, это было бы более полезно, если у вас много подобных функций, которые будут иметь очень длинные имена, если вы не объединяете их в отдельные классы.
Ах, вопрос без ответа!
Я, как правило, обнаруживаю, не могу ли я его инкапсулировать в нескольких словах, тогда есть что-то с дизайном (paracribbing из Code Complete).
Так что пока я доволен FindArticlesWithoutTitles Мне бы, наверное, было противно FindArticlesWithoutTitlesThenApplyDefaultStyles. Это просто неправильно; либо название является слишком техническим, и не описывает его фактическую функцию (заголовки без статей часто требуют стилей, которые должны быть исправлены, так что это будет FixArticleStyles), или это должно быть две функции: FindArticlesWithoutTitles/ApplyDefaultStyles.
Также: частота имеет много общего с этим. Если он используется часто, я хочу, чтобы он был коротким, чтобы уменьшить блики кода; длинные повторяющиеся имена делают код уродливым для чтения и болью типа. Если я всегда нахожу FindArticlesWithoutTitles, я могу просто сократить до FindNoTitles в зависимости от соответствующего контекста или, может быть, даже от FindArticles, если у меня нет других функций поиска статей.
Обратите внимание на этот пример, что привычка к функциям именования с полностью описательным названием - вот что нашло недостаток в дизайне. Открыв, что правильное имя будет «FindArticlesWithoutTitlesThenApplyDefaultStyles», вы на самом деле обнаружили, что функция делает слишком много. Тенденция к сокращению имен замаскировала бы этот факт. Сделайте свои имена описательными. Если описание слишком длинное, укоротите функцию, а не имя. –
Но я бы сказал, что это не так просто, один человек многословие - это минимализм другого человека. У меня есть функция, которая выполняет следующие действия: открывает файл, читает каждую строку файла, проверяет, сравнивает строки базы данных, а все, что не находится в БД, хранится в словаре C#. Это звучит как много чего, но разделение этого на несколько функций затруднит чтение. Проще всего обернуть его в одну функцию LoadSymbolsFile, что имеет смысл в контексте класса. Функция является частной и называется один раз. –
Это может быть немного не по теме, но, как вы просили специально для функции имени директивы (в отличие сказать, метод), я полагал, что я цитирую Линус Торвальдс о наименовании (хотя это более относится к переменным, но все же - принципы придерживаются).
Глава 3: Именование
C является Spartan языка, и поэтому должен вашего именования быть. В отличие от Modula-2 и Программисты Pascal, программисты C делают не используют милые имена, такие как ThisVariableIsATemporaryCounter. Программист C назвал бы эту переменную «tmp», которая намного проще писать, и не менее сложной для понимать.
Краткие, описательные названия хорошо сочетаются с короткими специфическими функциями ... которые хорошо сочетаются с повторным использованием кода.
Когда он содержит информацию, которая очевидно из контекста (например, incrementInteger (интермедиат х), долго longID), бесполезно (например, ObsoleteIncrementer, RobertsCarFactory), непонятное (например, TheFunctionThatRobertWorkedOnLastWeekButDidntFinish), числовой (например, ID1, ID2, id3) или иным образом не помогает понять или содержит запах кода. Обратите внимание, что даже если некоторая часть названных выше имен должна быть обрезана, вам может понадобиться добавить их с полезной информацией, чтобы они были уникальными и сделать их понятными, как в person_id для id1, employer_id для id2 и т. Д.
Функция имя слишком длинное, когда оно сэкономит вам работу, чтобы использовать более короткий.
Причина, по которой мы обычно обращаемся к описательным именам функций, заключается в том, что это экономит нам работу. (упрощая понимание и поддержание кода).Так что логически следует, что вы не должны давать свои имена функций, которые так долго, что стоит вам дополнительное время (сделать код труднее читать, например)
С Code Complete (1-е издание, стр 188)
«Gorla, Benander и Benander обнаружили, что усилия, необходимые для отладки программы COBOL, были сведены к минимуму, когда переменные имели имена, которые составляли от 10 до 16 символов (1990). Программы с именами в среднем от 8 до 20 символов были почти такими же легко отладки».
Это единственное эмпирическое обсуждение разумного ориентира для переменной длины имени, которую я когда-либо видел. Все остальное зависит от мнения и комфорта.
Я не верю, что это эмпирическое обсуждение напрямую применимо, поскольку оно не относится к именам функций, просто имена переменных. – mtnpaul
IMO, это слишком долго, когда в нем есть соединение. «Когда», «И», «Затем», ... что-то в этом роде. Следуя правилу единой ответственности, следует разрешить имена функций, которые достаточно длинны, чтобы быть описательными и достаточно короткими, чтобы не быть смехотворно раздражающими.
Задайте себе более интересный вопрос: почему мы долгое время называем имена функций? Это для того, чтобы описать, что делает функция. Я выдвигаю эту гипотезу:
Объем описания, необходимый в имени функции, обратно пропорционален количеству доступной для него информации о типе.
Чтобы проиллюстрировать этот момент, если вы видели такую функцию ...
public <A> A id(A a);
... что бы вы думаете, что делает? Информация о типе сообщает вам все, что вам нужно знать. Запрет побочных эффектов и исключений, , есть только одна вещь, которую эта функция могла бы сделать.
Конечно, вы, вероятно, работаете на языке, который допускает неограниченные побочные эффекты, чтобы функция могла, скажем, писать в файл. Но если это , то его тип - это ложь. Работа на языке, который объявляет эффекты в типах, позволяет использовать очень короткие имена без потери описательности.
Иногда ограничение в 30 символов во многих контекстах в Oracle SQL и PL/SQL было ужасным ограничением, но при отражении это заставляло нас много раз думать о том, как назвать вещи так, чтобы они были быстро поняты кто-то читает код позже.
Если мы не смогли адекватно описать цель таблицы, вида, функции, процедуры, пакета и т. Д., Используя 30 символов без использования чрезмерной аббревиатуры, это просто нужно было немного подумать и, возможно, добавить дополнительный слой абстракции группировать связанные вещи вместе.
Имена функций и методов начинают слишком долго, когда разработчик забывает о дескриптивном характере аргументов (предполагая значащие аргументы и имена переменных). Например:
my $template = HTML::Template->new(filename => 'home.html');
$template->param(title => 'Home Page');
$html = $template->output;
прозрачен в том, что он делает, даже если вы не знаете, не Perl и никогда не слышал о HTML::Template.
Я слишком часто видел соблазн, чтобы называть это output метод примерно RenderHTMLViewFromTemplateObject. Если все используемые библиотеки имеют такие соглашения об именах, мне становится просто невозможно следовать тому, что происходит.
Имя функции слишком длинное, когда вам нужно использовать редактор без завершения кода. – schnaader
Мои имена функций имеют одинаковую длину, когда я использую vim ... –
Ну, пользователи vim также имеют тенденцию писать довольно быстро. ОК, программисты в целом склонны к лучшим навыкам ввода текста ... но с завершением кода все еще работает лучше. – schnaader