В последние недели я видел, как некоторые ребята использовали очень длинные имена для метода или класса (50 символов), обычно это связано с предпосылкой, что это улучшает читаемость, мое мнение таково, что длинное имя, подобное этому, является индикатором что мы пытаемся сделать много или слишком много в классе методов, если нам нужно такое длинное имя, однако я хотел знать, что вы, ребята, думаете об этом.
Пример:
getNumberOfSkinCareEligibleItemsWithinTransaction
Имя в Java или любом другом языке слишком длинное, когда существует более короткое имя, которое равномерно передает поведение метода.
Некоторые методы сокращения длины имен методов:
Если ваша вся программа, класс или модуль посвящена "предметам ухода за кожей", вы можете отказаться от ухода за кожей. Например, если ваш класс называется SkinCareUtils,
который приведет вас к getNumberOfEligibleItemsWithinTransaction
Вы можете изменить внутри внутри, getNumberOfEligibleItemsInTransaction
Вы можете изменить транзакцию на Tx, которая приведет вас к getNumberOfEligibleItemsInTx.
Или, если метод принимает параметр типа Transaction, вы можете полностью удалить InTx: getNumberOfEligibleItems
Вы меняете numberOf по счету: getEligibleItemsCount
Теперь это очень разумно. И это на 60% короче.
Только для изменения, не субъективный ответ: 65536 символов.
A.java:1: представление UTF8 для строки "xxxxxxxxxxxxxxxxxxxx..." слишком длинное для постоянного пула
; -)
Я согласен со всеми: имена методов не должны быть слишком длинными. Я хочу добавить одно исключение:
Имена методов тестирования JUnit, однако, могут быть длинными и должны напоминать предложения.
Почему?
Пример:
@Test
public void testDialogClosesDownWhenTheRedButtonIsPressedTwice() {
...
}
См. "" Дизайн, управляемый поведением" для получения дополнительной информации об этой идее.
Контекст "... WithinTransaction" должен быть очевиден. Это объектная ориентация.
Этот метод является частью класса. Если класс не означает "Транзакция" - и если это не спасет вас от необходимости говорить "Внутритрансформации" все время, значит у вас проблемы.
Я использую правило хайку для имен:
Seven syllable class names
five for variables
seven for method and other names
Это правила для максимальных имен. Я нарушаю это только тогда, когда он улучшает читаемость. Что-то вроде recalculateMortgageInterest (currentRate, quoteSet...) лучше, чем пересчитыватьMortgageInterestRate или пересчитыватьMortgageInterestRateFromSet, поскольку тот факт, что он включает ставки и набор кавычек, должен быть довольно ясным из встроенных документов, таких как javadoc или эквивалент .NET.
ПРИМЕЧАНИЕ. Не настоящий хайку, так как это 7-5-7, а не 5-7-5. Но я все же предпочитаю называть его хайку.
Java имеет культуру поощрения длинных имен, возможно, потому, что IDE приходят с хорошей автозаполнением.
Этот сайт говорит, что самое длинное имя класса в JRE InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState, длина которого составляет 92 символа.
Как для самого длинного имени метода, я нашел этот supportsDataDefinitionAndDataManipulationTransactions, который составляет 52 символа.
Никогда не используйте длинное слово, когда миниатюрный будет делать.
Я не думаю, что ваш тезис о "длине имени метода пропорционален длине метода" действительно содержит воду.
Возьмите пример, который вы даете: "getNumberOfSkinCareEligibleItemsWithinTransaction". Это звучит так, как будто это одно: оно подсчитывает количество элементов в транзакции, попадающих в определенную категорию. Конечно, я не могу судить, не видя фактического кода для метода, но для меня это звучит как хороший метод.
С другой стороны, я видел множество методов с очень короткими и сжатыми именами, которые делают много работы, например "processSale" или когда-либо популярный "doStuff".
Я думаю, было бы сложно дать жесткое правило о длине имени метода, но цель должна быть: достаточно длинная, чтобы передать то, что делает функция, достаточно короткая, чтобы быть читаемой. В этом примере я бы подумал, что "getSkinCareCount", вероятно, было бы достаточно. Вопрос в том, что вам нужно отличить. Если у вас есть одна функция, которая учитывает элементы, подходящие для ухода за кожей, в транзакциях, а другая, которая учитывает элементы, относящиеся к уходу за кожей, в чем-то еще, тогда "inTransactions" добавляет ценность. Но если это не означает ничего говорить о таких вещах за пределами транзакции, то нет смысла загромождать имя такой избыточной информацией.
Во-вторых, я думаю, что это невероятно нереально предположить, что имя любой управляемой длины скажет вам, что именно делает функция во всех, кроме самых тривиальных случаях. Реалистичная цель - сделать имя, которое дает читателю подсказку, и это можно запомнить позже. Например, если я пытаюсь найти код, который вычисляет, сколько антиматерии нужно потреблять, чтобы достичь скорости деформации, если я смотрю на имена функций и вижу "calibrateTransporter", "firePhasers" и "calcAntimatterBurn", довольно ясно, что первые два - это не третий, а третий. Если я проверю и обнаружу, что это действительно тот, который я ищу, то будет легко вспомнить, что когда я вернусь завтра, чтобы еще немного поработать над этой проблемой. Это достаточно хорошо.
Три, длинные имена, которые похожи, более сбивают с толку, чем короткие имена. Если у меня есть две функции, называемые "calcSalesmanPay" и "calcGeekPay", я могу сделать хорошее предположение, которое есть на быстрый взгляд. Но если они называются "calculateMonthlyCheckAmountForSalesmanForExportToAccountingSystemAndReconciliation" и "calculateMonthlyCheckAmountForProgrammersForExportToAccountingSystemAndReconciliation", я должен изучить имена, чтобы увидеть, что именно. Дополнительная информация в названии, вероятно, контрпродуктивна в таких случаях. Кажется, половина секунд думает о 30 секундах.
Мое правило таково: если имя так долго, что оно должно появляться на отдельной строке, то оно слишком длинное. (На практике это означает, что я редко выше 20 символов.)
Это основано на исследованиях, показывающих, что количество видимых вертикальных линий кода положительно коррелирует со скоростью кодирования/эффективностью. Если имена классов/методов начинают значительно ухудшать это, они слишком длинны.
Добавить комментарий, где объявлен метод/класс, и пусть IDE доставит вас туда, если вам нужно подробное описание того, для чего оно предназначено.
Создайте свой интерфейс так, как вы хотите, и сравните реализацию.
Например, возможно, я напишу, что
getTransaction().getItems(SKIN_CARE).getEligible().size()
или с потоками Java 8:
getTransaction().getItems().stream()
.filter(item -> item.getType() == SKIN_CARE)
.filter(item -> item.isEligible())
.count();
Длина самого метода, вероятно, является лучшим показателем того, делает ли он слишком много, и даже это дает вам приблизительную идею. Вы должны стремиться к краткости, но описательность важнее. Если вы не можете передать то же значение в более коротком имени, то само название, вероятно, хорошо.
Это имя метода, безусловно, слишком велико. Мой разум, как правило, блуждает, когда я читаю имена таких размеров. Это как чтение предложения без пробелов.
Лично я предпочитаю как можно меньше слов в методах. Вам помогает, если имя пакета и класса может передать смысл. Если ответственность класса очень кратка, нет необходимости в имени гигантского метода. Мне любопытно, почему там "WithinTransaction".
"getNumberOfSkinCareEligibleItemsWithinTransaction" может стать:
com.mycompany.app.product.SkinCareQuery.getNumEligibleItems();
Тогда при использовании метод может выглядеть так: query.getNumEligibleItems() "
Имя переменной слишком длинное, когда более короткое имя позволит улучшить читаемость кода по всей программе или важные части программы.
Если более длинное имя позволяет вам передавать больше информации о значении. Однако, если имя слишком длинное, это загромождает код и уменьшает возможность понимания остальной части кода. Обычно это происходит, вызывая перенос строк и нажатие других строк кода на странице.
Трюк - это определение, которое обеспечит лучшую читаемость. Если переменная используется часто или несколько раз за короткое пространство, может быть лучше дать ей короткое имя и использовать пояснение комментария. Читатель может легко вернуться к комментарию. Если переменная используется часто во всей программе, часто в качестве параметра или в других сложных операциях, лучше всего обрезать имя или использовать сокращения для напоминания читателю. Они всегда могут ссылаться на комментарий по объявлению переменной, если они забывают о значении.
Это непростая компромиссная задача, поскольку вы должны учитывать, что читатель кода может попытаться понять, а также учитывать, как код будет меняться и расти со временем. Вот почему трудно называть вещи.
Считываемость - это то, почему приемлемо использовать я в качестве счетчика циклов вместо DescriptiveLoopCounterName. Поскольку это наиболее распространенное использование переменной, вы можете потратить наименьшее количество пространства на экране, объяснив, почему оно существует. Более длинное имя просто теряет время, затрудняя понимание того, как вы тестируете условие цикла или индексирование в массив.
На другом конце спектра, если функция или переменная используется редко, как в сложной операции, например, при передаче в вызове с несколькими параметрами, вы можете позволить себе дать чрезмерно описательное имя.
Когда вы собираетесь написать имя метода в следующий раз, просто подумайте, пожалуйста, следующую цитату
"The man who is going to maintain your code is a phyco who knows where you stay"
Как и любой другой язык: когда он больше не описывает одно действие, которое выполняет функция.
Я бы сказал, используйте комбинацию хороших ответов и будьте разумными.
Полностью, четко и с готовностью описывать, что делает этот метод.
Если имя метода кажется слишком длинным - реорганизуйте метод, чтобы сделать меньше.
Это слишком долго, когда имя метода обертывается на другую строку, и вызов метода является единственной вещью в строке и начинается довольно близко к краю. Вы должны учитывать средний размер экрана людей, которые будут его использовать.
Но! Если имя кажется слишком длинным, значит, оно слишком длинное. Способ обойти это написать свой код таким образом, чтобы вы были в контексте, а имя короткое, но дублировано в других контекстах. Это похоже на то, когда вы можете сказать "она" или "он" на английском языке вместо имени человека.
Это слишком долго, когда он слишком подробным образом объясняет, о чем идет речь.
Например, эти имена функционально эквивалентны.
в Java: java.sql.SQLIntegrityConstraintViolationException
в Python/Django: django.db.IntegrityError
Спросите себя, в пакете SQL/db, сколько еще типов ошибок целостности вы можете придумать?;)
Следовательно, db.IntegrityError достаточно.
Имя идентификатора слишком длинное, если оно превышает длину, которую может обрабатывать ваш компилятор Java.
Здесь есть два способа или точки зрения: один из них заключается в том, что на самом деле не имеет значения, как долго будет имя метода, до тех пор, пока оно будет описательным, чтобы описать, что делает этот метод (базовое правило лучшей практики Java). С другой стороны, я согласен с сообщением flybywire. Мы должны использовать наш интеллект, чтобы попытаться как можно меньше уменьшить имя метода, но не уменьшая его описательность. Описательность важнее:)
Слишком длинное имя, если оно:
Честно говоря, имя должно только передать свою цель Разработчикам, которые будут использовать его в качестве общедоступного метода API или должны поддерживать код при выходе. Просто помните KISS (держите это просто глупо)