Подтвердить что ты не робот

Проблемы с хорошими именами для функций

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

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

4b9b3361

Ответ 1

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

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

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

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

Ответ 2

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

Имя, подобное ReadPropertiesFromFileThenWriteToSession, лучше, чем ReadProps.

Ответ 3

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

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

Ответ 4

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

void RetrievePropertiesFromRemoteStore()

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

void RetrieveRemoteProperties()

Вместо:

bool CheckToSeeIfUserIsAuthorized()

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

bool IsUserAuthorized()

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

void GetUserProfileAndSetUpSession()

У вас может быть:

void GetUserProfile()
void SetupSession()

Ответ 5

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

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

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

Ваши функции должны действительно указывать, что они делают! Но не чрезмерно многословно. Это то, что вы освоите с течением времени, нужно немного практиковать правильную функцию.

Быстро прочитайте этот, чтобы увидеть некоторые вещи, которые я писал об этом подобном вещании некоторое время назад. Удостоверьтесь, что вы следуете к другая статья, которая вдохновила меня написать его и проверить комментарии.

Ответ 9

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

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

Ответ 10

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

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

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

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

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

Ответ 11

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

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()

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