Неправильные имена методов и что они говорят о структуре кода - PullRequest
4 голосов
/ 25 мая 2010

(заранее извиняюсь, если это повторная публикация, но я не нашел похожих сообщений)

Какие шаблоны имен плохих методов вы видели в коде и что он сказал вам о коде.

Например, я продолжаю видеть:

public void preform___X___IfNecessary(...);

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

Ответы [ 4 ]

3 голосов
/ 25 мая 2010

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

InsertImportQueueRecord

Я ненавидел это имя. Я изменил это на

ImportItem

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

2 голосов
/ 25 мая 2010

вещь (), doThing (), и действительно DoThing ()

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

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

1 голос
/ 26 мая 2010

Еще один, который я недавно заметил, Куча частных методов вида:

private void SOMETHINGBecauseOf__a__(..);
private void SOMETHINGBecauseOf__b__(..);
private void SOMETHINGBecauseOf__c__(..);

Я не могу придумать вескую причину для того, чтобы иметь в методе метод FromOf или делать нечто подобное. Это выглядит как хороший пример для оператора switch / if в одном методе.

1 голос
/ 25 мая 2010

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

Очевидным примером будет ValidateFormData_PersistToDB_SendEmail().

Хотя, поскольку я разработчик на C #, я бы не посмел использовать подчеркивание в любом случае.

...