Трудно придумать хорошие имена для функций - PullRequest
20 голосов
/ 11 июня 2009

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

Что вы делаете в этой ситуации? Это очень расстраивает.

Ответы [ 11 ]

19 голосов
/ 11 июня 2009

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

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

Обновление: многие авторы программного обеспечения говорили о важности именования. програмы Генри Ф. Ледгарда для программирования (1975) и Брайана Кернигана и П.Дж. Плаугера Элементы стиля программирования (1978) были ранними и до сих пор заслуживают чтения. Замечательный Code Complete Стива Макконнелла (2-е издание, 2005 г.) - более свежий пример, посвящающий целую главу этой теме.

Элементы стиля программирования частично были созданы по образцу Стрэнка и Уайта Elements of Style , что на самом деле имеет удивительное значение. Их акцент на том, чтобы сделать прозу ясной и чрезвычайно лаконичной, относится к нашим техническим письмам и комментариям (и именам), но я всегда видел это как аналог того, что мы делаем, когда мы реорганизуем и улучшаем наш код.

14 голосов
/ 11 июня 2009

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

Имя типа ReadPropertiesFromFileThenWriteToSession лучше, чем ReadProps .

9 голосов
/ 11 июня 2009

Покойный великий Фил Карлтон классно шутил: в информатике есть только две трудные проблемы - именование вещей и аннулирование кэша. Мой опыт подсказывает мне, что в этом много правды.

Правильно называть вещи - это искусство, а не наука, и как таковые не существует жестких и быстрых правил. Тем не менее, я иногда читаю правила Оттингера для именования переменных и классов , в которых есть некоторые хорошие эвристические характеристики, о которых следует помнить. Одним из моих любимых способов является использование именных фраз, таких как - person.getName () или bitTorrentClient.findPeersFromTracker (). В обоих этих случаях смысл строки кода похож на фразу на английском языке.

6 голосов
/ 11 июня 2009

Иногда вы можете уменьшить длину имени функции, просто переписав название. Вместо:

void RetrievePropertiesFromRemoteStore()

Вы можете использовать:

void RetrieveRemoteProperties()

Вместо:

bool CheckToSeeIfUserIsAuthorized()

Использование:

bool IsUserAuthorized()

Другой способ уменьшить это - переосмыслить, что делает функция. Вместо одной функции, подобной этой:

void GetUserProfileAndSetUpSession()

Вы можете иметь:

void GetUserProfile()
void SetupSession()
2 голосов
/ 11 июня 2009

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

У вас есть процесс, который должен выполнять A, B, C, ..., X, Y и Z; Вы не можете назвать процедуру doABCDEFGHIJKLMNOPQRSTUVWXYZ. Вы должны найти какую-то логическую группировку среднего уровня (возможно, несколько слоев), которая делит процесс на части.

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

Другая помощь заключается в инкапсуляции функций / процедур (в зависимости от особенностей языка, который вы используете), чтобы имя могло быть короче (поскольку его имя можно интерпретировать в контексте его контейнера). Например, процедура «openFile» обычно просто открывает файл для чтения; но в контексте класса «UserPrefsFile» он может иметь более конкретное значение.

1 голос
/ 11 июня 2009

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

1 голос
/ 11 июня 2009

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

0 голосов
/ 11 июня 2009

Использование объектно-ориентированного подхода помогает уменьшить эту проблему. connectionsToAccessLines -> connexion.connect (System.getAccessLines ());

handleWallVisionSplit -> этот, я не совсем уверен, что он делает: D Но я бы сказал что-то вроде: wall.handleVision (Wall.split); или что-то еще, я думаю, вы понимаете, о чем я.

Кроме того, иногда, когда действительно сложно назвать слишком специфическую функцию, это может быть потому, что код недостаточно высокого уровня. Например: readSecondWordOfLine (a_line) -> line.split () [1].

Или, sort (sortWithSecondWordOfLine ()) может стать, sort (line => split (line) [1]) .. Я знаю, что это не всегда выполнимо так же чисто, как во всех языках, но вы понимаете, о чем я. Например, в C ++ вы можете использовать композиты bind и stl для создания одного выражения liner вместо создания нового метода.

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

0 голосов
/ 11 июня 2009

Вы можете использовать нумерацию и постфиксы "_ *", чтобы избежать слишком большого количества имен в вашем коде:

void DoX()
void DoX_Decode1()           <-- this name shows that this function is only used by DoX()
void DoX_Decode2()
void DoX_Decode3()
void DoX_Find1()
void DoX_Find2()
void DoX_Find3()

Вы также можете группировать аналогичные функции с префиксами:

void tcpip_ShowConnectDialog()
void tcpip_AcceptConnections()
void logging_WriteToFile()
void logging_UpdateLogWindow()

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

0 голосов
/ 11 июня 2009

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

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

...