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

Ответ 1

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

Ответ 5

• Если вам нужно прокрутить вправо, чтобы прочитать его.
• Описывает 3 или более вещи, которые есть - это не должно делать много чего.
• Ваш босс слишком долго думает.
• Это больше, чем сам код.
• Он начинается с Get, как и 500 других функций.
• Никто не хочет его использовать.
• Существует еще одна функция, которая делает то же самое с более коротким именем, которое пользователи понимают.
• Это можно сделать короче.

Ответ 6

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

Ответ 7

Из Code Complete (1-е издание, стр. 188)

"Gorla, Benander и Benander обнаружили, что усилия, необходимые для отладки программы COBOL, были сведены к минимуму, когда переменные имели имена, составляющие в среднем от 10 до 16 символов (1990). Программы с именами в среднем от 8 до 20 символов были почти такими же легко отлаживаемыми."

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

Ответ 8

Когда вы начинаете думать об этом:)

Ответ 9

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

Ответ 10

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

Ответ 11

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

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

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

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

Ответ 12

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

Ответ 13

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

Ответ 14

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

Ответ 15

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

Ответ 16

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

Ответ 17

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

Ответ 18

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

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

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

Ответ 19

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

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

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

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

Ответ 20

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

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

Ответ 21

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

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

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

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

Ответ 22

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

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

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

Ответ 23

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

Сохраняйте свой код под контролем, используйте вместо него комментарии.

Ответ 24

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

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

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

Ответ 25

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

Ответ 26

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

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

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

public <A> A id(A a);

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

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

Ответ 27

Иногда ограничение в 30 символов во многих контекстах в Oracle SQL и PL/SQL казалось ужасным ограничением, но по размышлению он много раз заставлял нас много думать о том, как назвать вещи, чтобы они были быстро поняты кем-то прочитав код позже.

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