Когда имя функции слишком долго?

Задайте себе более интересный вопрос: почему мы делаем имена функций длинными? Это для того, чтобы описать, что делает функция. Что ж, я предлагаю эту гипотезу:

Количество описания, необходимое в имени функции, обратно пропорционально количеству информации о типе, доступной для него.

Чтобы проиллюстрировать это, если вы видели такую ​​функцию ...

public <A> A id(A a);

... как вы думаете, что он делает? Информация о типе сообщает вам все, что вам нужно знать. За исключением побочных эффектов и исключений, есть только одна вещь, которую эта функция могла бы делать.

Конечно, вы, вероятно, работаете на языке, который допускает неограниченные побочные эффекты, так что эта функция могла бы, скажем, писать в файл. Но если это так , то это ложь .

Иногда ограничение в 30 символов во многих контекстах в Oracle SQL и PL / SQL казалось ужасным ограничением,

Если у компилятора есть некоторые ограничения на имена переменных, часто это 64 или 128 символов или что-то среднее между ними. В прошлом также были популярны 32 персонажа. Если у них есть ограничение, они часто просто берут первые n символов и игнорируют остальные.

Общее правило состоит в том, что имя функции дает очень краткое описание того, что она делает. Большинство таких описаний должно легко умещаться в 32 символа. (Используйте CamelCase для разделения слов.) Поскольку большинство IDE теперь предоставляют автозавершение кода, ошибки с именами функций действительно возникают редко. Но сделайте это проще, убедившись, что большинство функций отличаются друг от друга первыми 8 символами. Следует избегать чего-то вроде DateCalculationAddMonth, DateCalculationAddWeek, DateCalculationAddYear и DateCalculationAddDay. Используйте AddMonthDateCalculation, AddWeekDateCalculation, AddYearDateCalculation и AddDayDateCalculation. (Кстати, это глупые примеры, но я надеюсь, что вы понимаете мой уклон.)

На самом деле, может быть лучше добавить (сгруппировать) ваши функции в отдельный класс. В приведенном выше глупом примере вы можете просто создать класс DateCalculation и добавить к этому классу четыре (статические / классовые) функции (AddMonth, AddWeek, AddYear и AddDay). По сути, это было бы более полезно, когда у вас есть много похожих функций, у которых все будут очень длинными именами, если вы не сгруппируете их вместе в отдельные классы.

ИМО, он слишком длинный, когда в нем есть соединение. «Когда», «И», «Тогда» ... что-нибудь в этом роде. Следование правилу единой ответственности должно позволять имена функций, которые должны быть достаточно длинными, чтобы быть описательными, и достаточно короткими, чтобы не вызывать до смешного раздражения.

Имена методов могут быть очень длинными в зависимости от языка ( Максимальная длина имени метода ). В какой-то момент вы собираетесь использовать эту функцию или метод и вводить предложение для имен функций кажется ненужным.

Обеспечьте удобство сопровождения кода, вместо этого используйте комментарии.

Имена функций и методов начинают становиться слишком длинными, когда разработчик забывает об описательной природе аргументов (предполагая значимые имена аргументов и переменных). Например:

 my $template = HTML::Template->new( filename => 'home.html'); 
 $template->param( title => 'Home Page' );
 $html = $template->output;

прозрачен в том, что он делает, даже если вы не знаете Perl и никогда не слышали о HTML :: Template .

Я слишком часто встречал искушение назвать это output , что-то вроде RenderHTMLViewFromTemplateObject . Если все используемые библиотеки имеют такие соглашения об именах, мне становится просто невозможно следить за тем, что происходит.

Имя функции слишком длинное, потому что это сэкономит вам работу, если использовать более короткое.

Мы обычно используем описательные имена функций, потому что это экономит нам работу. (облегчая понимание и поддержку кода). Из этого логически следует, что вы не должны давать своим функциям слишком длинные имена, которые требуют дополнительного времени (например, затрудняя чтение кода)

Я думаю, вам следует больше беспокоиться о том, когда имя функции слишком короткое или недостаточно информативное. Пока ваша функция выполняет то, что описывает ее имя (и все, ее имя), она имеет правильное имя. Я часто пишу функции с длинными именами, например getPropertyNameArrayFromObject (хотя я предпочитаю подчеркивать, а не камелизовать), которые можно было бы назвать getObjPropArr или что-то еще, но не было бы столь информативным. Я стараюсь избегать сокращений, потому что они становятся неоднозначными, когда вы продолжаете работать над чем-то другим и возвращаетесь к коду.

С другой стороны, рассмотрите многие встроенные функции PHP, такие как stricmp, которым действительно следует называть что-то в строке строки caseInsensitiveStringComparison.

И бывают случаи, когда я намеренно пишу очень короткие имена функций, которые совсем не описательны. Иногда мне просто нужна короткая функция JavaScript, работающая как ярлык. Например, я обычно использую псевдоним $ (id) для document.getElementById (id), потому что мне надоело это печатать.

И есть случаи, когда я намеренно пишу очень короткие имена функций, которые совсем не описательны. Иногда мне просто нужна короткая функция JavaScript, работающая как ярлык. Например, я обычно использую псевдоним $ (id) для document.getElementById (id), потому что мне надоело это печатать.

И есть случаи, когда я намеренно пишу очень короткие имена функций, которые совсем не описательны. Иногда мне просто нужна короткая функция JavaScript, работающая как ярлык. Например, я обычно использую псевдоним $ (id) для document.getElementById (id), потому что мне надоело это печатать.

Ах, вопрос без ответа!

Я стараюсь найти, если не могу инкапсулировать это в нескольких словах, а затем что-то не так с дизайном (параграф из Code Complete).

Так что, хотя я доволен FindArticlesWithoutTitles , мне, вероятно, не понравится FindArticlesWithoutTitlesThenApplyDefaultStyles . Это просто неправильно; либо название слишком техническое и не описывает его действительную функцию (заголовки без статей часто нуждаются в исправлении стилей, поэтому это будет FixArticleStyles ), либо это должны быть две функции: FindArticlesWithoutTitles / ApplyDefaultStyles .

Также: частота имеет много общего с этим. Если он используется часто, я хочу, чтобы он был коротким, чтобы уменьшить блеск кода; длинные повторяющиеся имена делают код некрасивым для чтения и затрудняют ввод. Если я всегда нахожу FindArticlesWithoutTitles , я могу просто сократить до FindNoTitles в зависимости от соответствующего контекста или, может быть, даже просто FindArticles , если у меня нет других функций поиска статей.

Также: частота имеет много общего с этим. Если он используется часто, я хочу, чтобы он был коротким, чтобы уменьшить блеск кода; длинные повторяющиеся имена делают код некрасивым для чтения и затрудняют ввод. Если я всегда нахожу FindArticlesWithoutTitles , я могу просто сократить до FindNoTitles в зависимости от соответствующего контекста или, может быть, даже просто FindArticles , если у меня нет других функций поиска статей.

Также: частота имеет много общего с этим. Если он используется часто, я хочу, чтобы он был коротким, чтобы уменьшить блеск кода; длинные повторяющиеся имена делают код некрасивым для чтения и затрудняют ввод. Если я всегда нахожу FindArticlesWithoutTitles , я могу просто сократить до FindNoTitles в зависимости от соответствующего контекста или, может быть, даже просто FindArticles , если у меня нет других функций поиска статей.

Когда он содержит информацию, которая очевидна из контекста (например, incrementInteger (int x), long longID), бесполезна (например, ObsoleteIncrementer, RobertsCarFactory), непонятна (например, TheFunctionThatRobertWorkedOnLastWeekButDidntFinish) например, id1, id2, id3) или иначе не помогает понять или содержит запах кода. Обратите внимание, что даже несмотря на то, что некоторая часть приведенных выше имен должна быть сокращена, вам может потребоваться дополнить их полезной информацией, чтобы сохранить их уникальность и сделать их понятными, например, person_id для id1, работодателя_id для id2 и т. Д.

Это может быть немного не по теме, но, поскольку вы специально просили указать директиву по названию функции (в отличие от метода), я решил процитировать Линуса Торвальдса по именованию (хотя это больше относится к переменным, но все же - принципы остаются в силе).

Глава 3: Именование

C - спартанский язык, и поэтому следует ваше имя будет. В отличие от Модулы-2 и Программисты на Паскале, программисты на C не используйте милые имена вроде ThisVariableIsATemporaryCounter. AC программист назвал бы эту переменную "tmp", который намного проще написать, и не в последнюю очередь труднее поймите.

Короткие описательные имена хорошо сочетаются с короткими конкретными функциями ... которые хорошо сочетаются с повторным использованием кода.

Из Код завершен (1-е издание, стр. 188)

«Горла, Бенандер и Бенандер обнаружили, что усилия, необходимые для отладки программы COBOL, были минимизированы, когда переменные имели имена, которые в среднем состояли из 10–16 символов (1990 г.). Программы с именами в среднем от 8 до 20 символов было почти так же легко отлаживать ».

Это единственное эмпирическое обсуждение разумного руководства по длине имени переменной, которое я когда-либо видел. Все остальное зависит от мнения и комфорта.

1. Если вам нужно прокрутить вправо, чтобы прочитать его.
2. Описывает 3 или более вещей, которые он делает - он не должен делать так много.
3. Ваш босс думает он слишком длинный.
4. Он длиннее, чем сам код.
5. Он начинается с Get, как и 500 других функций.
6. Никто не хочет его использовать.
7. Есть еще одна функция, которая делает то же самое с более короткое имя, понятное пользователям.
8. Его можно сделать короче.

Попытка избежать субъективизма:

Когда имена становятся примерно 1/3 от вашей типичной длины строки, вы ее растягиваете. При длине 1/2 строки вы зашли слишком далеко. Один оператор в строке становится довольно сложным, когда имена занимают всю строку.

Помимо этого, большинство IDE поддерживают завершение (тем самым избавляя программиста от фактического ввода большинства имен полностью), поэтому более важная вещь, которую нужно сделать, в моем По мнению, необходимо как можно скорее сделать имя максимально уникальным.

Я думаю, что это особенно важно для публичных имен - они не должны быть слишком длинными, но то, насколько они длинные, очень субъективно. Всегда лучше иметь более длинное и описательное имя, чем слишком короткое.
На мой взгляд, для частных методов даже очень длинные имена не проблема.

Пока функции действительно делают то, что следует из их названия, и вы не собираетесь вводить код для гольфа, я думаю, что это хорошо.

Я бы сказал, когда вы обнаружите, что при обращении к ним находите сокращения для их имен. Я также нахожу это слишком частым, когда люди начинают описывать предварительные / пост- / параметрические условия в именах или давать подсказки по реализации. (например, getVersionInformationFormTheDatabase () или doSomethingWithoutCheckingFooFirst () )

Если имя функции «слишком длинное», то вполне вероятно, что сама функция тоже слишком длинная и несет слишком большую ответственность. Многие мудрые программисты говорят, что функция должна делать одно и только одно. Функция, имя которой должно быть длинным, чтобы точно описывать то, что она делает, вероятно, будет хорошим кандидатом для рефакторинга нескольких более мелких и простых частных функций , которые, следовательно, имеют более короткие имена.

Я не думаю, что имя метода может быть слишком длинным, если оно носит описательный характер. Если имя метода превышает 40 символов, я посмотрю, смогу ли я передать то же значение меньшим количеством слов. Если нет, я буду жить с длинным именем для ясности.

TheFunctionNameBecomesTooLongWhenItBecomesTooHardToReadItAndUnderstandIt, с другой стороны it_dependends_on_nameing_convention_how_hard_function_reading_is_sometimes_long_names_are_readable.

Когда он не делает всего , что говорит, что делает. ;)

Когда начинаешь думать :)

ИМХО, гораздо важнее, чтобы функции были описательными. IDE помогают избежать проблем с неправильным написанием или чем-то в этом роде. Я думаю, что иногда можно использовать сокращения, если они согласованы в коде (никаких разных сокращений для одного и того же элемента или одного и того же сокращения для двух разных вещей.

Когда вы больше не можете читать их вслух, не дыша посередине = D

Имя функции слишком длинное, когда оно начинает переоценивать то, что она делает, или когда это мешает читаемости кода.

На мой взгляд, имя функции должно быть ровно столько, сколько необходимо для описания ее назначения. Если вы считаете, что имя функции слишком длинное, это может указывать на то, что она пытается сделать слишком много вещей, и ее следует отредактировать.