Когда имя метода Java слишком долго? [закрытый]

Имя слишком длинное, если оно:

• Занимает более 1 секунды для чтения
• Занимает больше оперативной памяти, чем вы выделили для вашей JVM
• Это что-то абсурдное
• Если более короткое имя имеет смысл
• Если оно закручивается в вашей IDE

Честно говоря, имя должно передавать свое назначение только разработчикам, которые будут использовать его как метод публичного API или должны будут поддерживать код после вашего ухода. Просто помните KISS (keep it simple stupid)

Имя идентификатора слишком длинное, если оно превышает длину, которую может обработать компилятор Java.

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

Но! Если имя кажется слишком длинным, вероятно, оно слишком длинное. Способ обойти это - написать код таким образом, чтобы вы находились в контексте, а имя было коротким, но дублировалось в других контекстах. Это похоже на то, когда вы можете сказать по-английски «она» или «он» вместо чьего-либо полного имени.

Я бы сказал, используйте комбинацию хороших ответов и будьте разумны.

Полностью, ясно и понятно опишите, что делает метод.

Если имя метода кажется слишком длинным - реорганизуйте метод, чтобы сделать меньше.

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

Когда вы собираетесь написать имя метода в следующий раз, вспомните приведенную ниже цитату

"The man who is going to maintain your code is a phyco who knows where you stay"

Мое правило таково: если имя настолько длинное, что оно должно стоять в отдельной строке, то оно слишком длинное. (На практике это означает, что я редко использую более 20 символов.)

Это основано на исследовании, показывающем, что количество видимых вертикальных строк кода положительно коррелирует со скоростью / эффективностью кодирования. Если имена классов / методов начинают сильно мешать, они слишком длинные.

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

Никогда не используйте длинное слово, если подойдет уменьшительное.

Я не думаю, что ваш тезис о том, что «длина имени метода пропорциональна длине метода» действительно выдерживает критику.

Возьмем приведенный вами пример: "getNumberOfSkinCareElhibitedItemsWithinTransaction". Для меня это звучит так, будто он делает только одно: он подсчитывает количество элементов в транзакции, которые попадают в определенную категорию. Конечно, я не могу судить, не видя фактического кода метода, но мне кажется, что это хороший метод.

С другой стороны, я видел множество методов с очень короткими и лаконичными именами, которые делают много работы, например, processSale или все еще популярный doStuff.

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

Во-вторых, я думаю, что это дико нереально предполагать, что имя любой управляемой длины скажет вам точно, что функция делает во всех случаях, кроме самых тривиальных. Реальная цель - придумать имя, которое даст читателю ключ к разгадке и которое можно будет вспомнить позже. Например, если я пытаюсь найти код, который вычисляет, сколько антивещества нам нужно потребить, чтобы достичь скорости деформации, если я смотрю на имена функций и вижу «calibrateTransporter», «firePhasers» и «calcAntimatterBurn», становится ясно, что первые два не так, но третий может быть. Если я проверю и обнаружу, что это действительно то, что я ищу, мне будет легко вспомнить это, когда я вернусь завтра, чтобы еще немного поработать над этой проблемой. Достаточно хорошо.

Три одинаковых длинных имени сбивают с толку больше, чем короткие. Если у меня есть две функции, называемые «calcSalesmanPay» и «calcGeekPay», я могу быстро догадаться, какая именно. Но если они называются «calculateMonthlyCheckAmountForSalesmanForExportToAccountingSystemAndReconciliation» и «calculateMonthlyCheckAmountForProgrammersForExportToAccountingSystemAndReconciliation», я должен изучить имена, чтобы увидеть, что есть что. Дополнительная информация в названии, вероятно, в таких случаях непродуктивна.Полусекундное мышление превращается в 30-секундное.

В Java есть культура поощрения использования длинных имен, возможно, потому, что IDE имеют хорошее автозаполнение.

На этом сайте указано, что самое длинное имя класса в JRE - это InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState , длина которого составляет 92 символа.

Что касается самого длинного имени метода, я обнаружил, что этот поддерживаетDataDefinitionAndDataManipulationTransactions , что составляет 52 символа.

Я обычно использую правило хайку для имен:

 Seven syllable class names 
 five for variables
 seven for method and other names

Это практические правила для максимального количества имен.Я нарушаю это только тогда, когда это улучшает читаемость. Что-то вроде recalculateMortgageInterest (currentRate, quoteSet ...) лучше, чем recalculateMortgageInterestRate или recalculateMortgageInterestRateFromSet, поскольку тот факт, что он включает ставки и набор котировок, должен быть довольно ясен из встроенных документов, таких как javadoc или эквивалент .NET.

ПРИМЕЧАНИЕ: Не настоящее хайку, это 7-5-7, а не 5-7-5. Но я все же предпочитаю называть это хайку.

Как разбить его немного больше, чтобы дать что-то большее (освобождая меня от использования логических операторов Java в довольно долго ), как это:

public bool findFirstCondition()
{
   // do some stuff giving the return value of the original "thisCondition".
}

public bool findSecondCondition()
{
   // do some stuff giving the return value of the original "thatCondition".
}

public bool findLastCondition()
{
   // do some stuff giving the return value of the original "lastCondition".
}

private void cleanUp() 
{
   // perform common cleanup tasks.
}


public bool myMethod() 
{ 


   bool returnval = true;
   returnval = returnval && findFirstCondition();
   returnval = returnval && findSecondCondition();

   returnval = returnval && findLastCondition();
   cleanUp();
   return returnval; 
}

Вы можете создать свой собственный скроллер с помощью javascript.

Это не очень практичная идея, но вы можете попробовать.

И поместите ссылку на изображение, описывающее его лучше. Это было бы очень полезно.

Только для изменения, не субъективный ответ: 65536 символов.

A.java: 1: UTF8 слишком длинное представление для строки «xxxxxxxxxxxxxxxxxxxx»... для постоянного пула

; -)

Имя в Java или любом другом языке слишком длинное, когда существует более короткое имя, которое в равной степени передает поведение метода.

Мое правило следующее: если имя настолько длинное, что оно должно отображаться в собственной строке, то оно слишком длинное. (На практике это означает, что я редко превышаю 20 символов.)

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

Добавьте комментарий, в котором объявлен метод/класс, и позвольте среде IDE взять вас туда, если вы хотите длинное описание того, для чего он предназначен.

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

Здесь есть два пути или точки зрения: Первая заключается в том, что на самом деле не имеет значения, насколько длинным является имя метода, если оно максимально описательно описывает то, что делает метод (основное правило лучшей практики Java). С другой стороны, я согласен с постом flybywire. Мы должны использовать наш интеллект, чтобы попытаться максимально сократить имя метода, но без снижения его описательности. Описательность важнее :)

Некоторые приемы сокращения длины имен методов:

1. Если вся ваша программа, или класс, или модуль посвящены "предметам по уходу за кожей", вы можете отказаться от ухода за кожей. Например, если ваш класс называется SkinCareUtils, getNumberOfEligibleItemsWithinTransaction

2. Вы можете изменить within на in, getNumberOfEligibleItemsInTransaction

3. Вы можете изменить Transaction на Tx, что приведет вас к getNumberOfEligibleItemsInTx.

4. Или, если метод принимает параметр типа Transaction, можно вообще отказаться от InTx: getNumberOfEligibleItems

5. Вы меняете numberOf на count: getEligibleItemsCount

Вот это очень разумно. И это на 60% короче.

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

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

Хитрость заключается в том, чтобы определить, что будет лучше читаться. Если переменная используется часто или несколько раз в небольшом пространстве, может быть лучше дать ей короткое имя и использовать пояснение комментария. Читатель может легко вернуться к комментарию. Если переменная часто используется в программе, часто в качестве параметра или в других сложных операциях, может быть лучше урезать имя или использовать сокращения в качестве напоминания читателю. Они всегда могут ссылаться на комментарий в объявлении переменной, если забыли его значение.

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

Удобочитаемость - вот почему допустимо использовать i в качестве счетчика цикла вместо DescriptiveLoopCounterName. Поскольку это наиболее распространенное использование переменной, вы можете потратить минимум места на экране, объясняя, почему она существует. Более длинное имя просто тратит время, затрудняя понимание того, как вы проверяете условие цикла или индексацию в массив.

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

Контекст "...WithinTransaction" должен быть очевиден. В этом и заключается объектная ориентация.

Метод является частью класса. Если класс не означает "Transaction" -- и если он не избавляет вас от необходимости постоянно говорить "WithinTransaction", то у вас проблемы.

Я согласен со всеми: имена методов не должны быть слишком длинными. Однако я хочу добавить одно исключение:

Однако имена тестовых методов JUnit могут быть длинными и должны напоминать предложения.

Почему?

• Потому что они не вызываются в другом коде.
• Потому что они используются как названия тестов.
• Потому что тогда они могут быть записаны как предложения, описывающие требования. (Например, используя AgileDox )

Пример:

    @Test
    public void testDialogClosesDownWhenTheRedButtonIsPressedTwice() {
        ...
    }

См. « Behavior Driven Design » для получения дополнительной информации об этой идее.

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

Лично я предпочитаю, чтобы в методах было как можно меньше слов. Вам поможет, если имя пакета и класса сможет передать смысл. Если ответственность класса очень лаконична, нет необходимости в гигантском имени метода. Любопытно, почему там "WithinTransaction".

"getNumberOfSkinCareEligibleItemsWithinTransaction" может стать:

com.mycompany.app.product.SkinCareQuery.getNumEligibleItems();

Тогда при использовании метод может выглядеть как "query.getNumEligibleItems()"