именование методов, переменных

← →
студент-первокурсник (2011-03-15 22:06) [0]

Как грамотно, с точки зрения стилистического оформления, именовать методы, возвращающие bool значения и переменные типа bool?

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

Например, метод который возвращает результат авторизация пользователя на web сервере и переменная которая этот результат хранит. Если методу дать название function IsAuthorized(const UserName, Password: string): Boolean; , какое название давать переменной.

← →
Игорь Шевченко © (2011-03-15 22:16) [1]

> какое название давать переменной

Authorized

← →
студент-первокурсник (2011-03-15 22:20) [2]

а если к примеру методы типа FileExist?

← →
Игорь Шевченко © (2011-03-15 22:24) [3]

"Важной частью пропагандируемого мною стиля программирования является
разложение сложных процедур на небольшие методы. Если делать это неправильно,
то придется изрядно помучиться, выясняя, что же делают эти маленькие методы.
Избежать таких мучений помогает назначение методам хороших имен. Методам
следует давать имена, раскрывающие их назначение. Хороший способ для этого -
представить себе, каким должен быть комментарий к методу, и преобразовать
этот комментарий в имя метода.
Жизнь такова, что удачное имя может не сразу придти в голову. В подобной
ситуации может возникнуть соблазн бросить это занятие - в конце концов,
не в имени счастье. Это вас соблазняет бес, не слушайте его. Если вы видите,
что у метода плохое имя, обязательно измените его. Помните, что ваш код
в первую очередь предназначен человеку, а только потом - компьютеру.
Человеку нужны хорошие имена. Вспомните, сколько времени вы потратили,
пытаясь что-то сделать, и насколько проще было бы, окажись у пары методов
более удачные имена. Создание хороших имен - это мастерство, требующее
практики; совершенствование этого мастерства - ключ к превращению
в действительно искусного программиста.
То же справедливо и в отношении других элементов сигнатуры метода.
Если переупорядочивание параметров проясняет суть - выполните его."

Мартин Фаулер.

← →
Dimka Maslov © (2011-03-15 23:21) [4]

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

← →
Юрий Зотов © (2011-03-15 23:26) [5]

Методы надо именовать в порядке возрастания: Method1, Method2 и т.д.

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

← →
Leonid Troyanovsky © (2011-03-15 23:37) [6]

> студент-первокурсник (15.03.11 22:20) [2]

> а если к примеру методы типа FileExist?

Таких методов быть не должно.

--
Regards, LVT.

← →
Inovet © (2011-03-15 23:57) [7]

> [5] Юрий Зотов © (15.03.11 23:26)
> Method1, Method2 и т.д.

Лучше так
64A71552-C23D-4BBB-A47C-F19CA2610919
CA0EC5CA-FDC2-4B14-96BA-26CCAAA80AA0
B05172EE-D9E7-4D03-9159-E7719972E38E
F68D2C48-E1DE-4F59-9F8D-F63F0A307D4A
5A6A39A3-F6B9-4F2F-94D0-82D55557422A
и т.д.

← →
Anatoly Podgoretsky © (2011-03-16 09:45) [8]

> Inovet (15.03.2011 23:57:07) [7]

Шурик это не наш метод.

← →
MsGuns © (2011-03-16 09:56) [9]

"Давая имена процедурам в манере Proc1,Proc2 и т.д., он сладострастно тер руки, представляя муки адовы того программиста-бедолаги, которому придется разбираться в его программе" (с)

← →
TUser © (2011-03-16 12:49) [10]

Лично мое мнение:

1. Если каждому методу приписать некий префикс, например, MethodOfVasyaPupkinNamed<настоящее_имя_метода>, это не добавляет читаемости коду. Нисколько. Даже наоборот. Тоже самое верно в отношении префиксов типа Is или lp

2. Допустим нам дан кусок кода в 10 строк типа
var MyVar: boolean;
...
MyVar := MyMethod
Очевидно, по крайнйе мере в паскале, что вопрос о типе MyMethod"а у читателя не возникает.

3. Если все же возникает, то пусть читатель поставит себе современный редактор и наведет мышкой. Напоминать ему постоянно и навязчиво, что речь идет о boolean, - это юриспродизмом попахивает. Представьте себе инструкцию жены мужу: "Мой муж Василий, соверши при помощи своих ног (нижних конечностей) локомоцию в направлении источника продуктов питания, находящегося за пределами совместно принадлежащего нам (с тобой) недвижимого имущества, с целью приобретения (обмена на законные денежные знаки центрального банка Российской Федерации) источников калорий и витаминов в соответствии с приложением к настоящей просьбе, пожалуйста". Нормальный человек не напоминает, кто кому муж, что продукты надо купить, причем вне квартиры, причем туда надо идти, а не ползти. Лишнее упоминание очевидных деталей раздражает. Вероятно, это требуется в юридической практике для исключения кривотолков (скорее - для уменьшения, все равно же кривотолкуют), но там стоит явная задача - обломить кривотолкователя. Если же предполагается, что читатель - человек, и он стремиться понять мысль автора кода, а не кривотолкнуть ее, то нао помнить, что человеку свойственнододумывать неуказанные детали, и в нормальной ситуации он их додумывает правильно.

4. Сказанное - не есть догма, я использую прфикс Is, но редко, когда непонятно без него. Пример: медод [Is]ValidFoo, который проверяет Foo на валидность, а не возвращает валидное значение этого самого Foo. Если есть еще и метод, который возвращает, то стоит назвать их IsValidFoo и GetValidFoo.

← →
Компромисс (2011-03-16 13:10) [11]

медод [Is]ValidFoo, который проверяет Foo на валидность, а не возвращает валидное значение этого самого Foo

Должен быть назван ValidateFoo (если бросает exception) при ошибке или IsValidFoo (если boolean). ValidFoo - вообще не может быть именем метода. Имя метода обязано включать в себя глагол (английский, желательно) и быть правильным с грамматической точки зрения. GetValidFoo - правильное имя метода, ValidGetFoo - неправильное. Соответственно, не будет вопросов, чем является ValidFoo - методом или переменной. Конечно, переменной.

← →
TUser © (2011-03-16 13:18) [12]

> Имя метода обязано включать в себя глагол

Например, в Д7 у TCustomForm есть методы без глагола. неверных из Борланда на мыло ?)

← →
Компромисс (2011-03-16 13:25) [13]

> Например, в Д7 у TCustomForm есть методы без глагола. неверных
> из Борланда на мыло ?)

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

← →
stenfit (2011-03-16 15:00) [14]

а если метод проверяет, например, существование поля в таблице и возвращает булевский результат, так что ли писать:?

FieldExists := IsFieldExists("MyField")

← →
Игорь Шевченко © (2011-03-16 15:27) [15]

пиши как хочешь, лишь бы было понятно

← →
Компромисс (2011-03-16 15:34) [16]

а если метод проверяет, например, существование поля в таблице и возвращает булевский результат, так что ли писать:?

FieldExists := IsFieldExists("MyField")

Хороший вопрос. Тут я порекомендую только использовать нормальный язык типа java, в котором таких проблем нет :)

fieldExists = fieldExists("myField");

А если серьезно, речь была о полях и методах. Локальные переменные можно попроще называть.
myFieldExists := fieldExists("myField");
или для понятности
uncleExists := fieldExists("uncle");

← →
clickmaker © (2011-03-16 15:36) [17]

> FieldExists := IsFieldExists("MyField")

с точки зрения правильности грамматики надо DoesFieldExist()

← →
Anatoly Podgoretsky © (2011-03-16 16:05) [18]

> clickmaker (16.03.2011 15:36:17) [17]

В VCL FileExists и DirExists

← →
Jeer © (2011-03-16 16:06) [19]

> IsFieldExists

Масляное масло.

← →
RWolf © (2011-03-16 16:14) [20]

а вот если добавить вопросительный знак в набор символов, разрешённых в идентификаторах, то можно называть булевы функции в стиле Ruby:

function FieldExists? (const FieldName : string) : Boolean;

это вроде бы не конфликтует с нынешней грамматикой языка.

← →
Компромисс (2011-03-16 16:20) [21]

RWolf © (16.03.11 16:14) [20]

И переменные в стиле

fieldExists! = FieldExists?("my");

Теперь я понял, почему Паскаль ввел оператор <> вместо !=

:-)

← →
Palladin © (2011-03-16 16:32) [22]

> Масляное масло.

Это масляное масло?

← →
Jeer © (2011-03-16 17:37) [23]

Is*Exists - префикс и суффикс семантически идентичны.

← →
Игорь Шевченко © (2011-03-16 18:25) [24]

> префикс и суффикс семантически идентичны.

между именами

IsFile
и
FileExists

есть некоторая разница

но все это ловля блох

← →
_Юрий (2011-03-16 20:27) [25]

Свойства с геттерами суть методы, а называются существительными. Это хорошо?

← →
Игорь Шевченко © (2011-03-16 21:43) [26]

> Свойства с геттерами суть методы, а называются существительными.
> Это хорошо?

Это хорошо

← →
_Юрий (2011-03-17 01:06) [27]

> Это хорошо
>

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

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

"От нас" ничего не скрыли. Это вы уже "перебрали". Там где геттеры, там и сеттеры. И какой же глагол вы предлагаете использовать? Get или Set?
Возвращайтесь в просто паскаль. Там нет ни геттеров, ни сеттеров, ни свойств(property) как таковых. Есть просто переменные.

> От нас скрыли, будет ли вызван метод

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

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

нужно изначально геттер грамотно писать.
if FPrivateVariable = nil then
FPrivateVariable = GetVariableFromDBOrWebServer;
Result := FPrivateVariable;

вместо

Result := GetVariableFromDBOrWebServer;

← →
_Юрий (2011-03-18 00:34) [31]

>>clickmaker © (17.03.11 11:18) [30]
Ну во первых, нет никакой гарантии, что сторонний класс написан "грамотно", во вторых часто логика объекта такое не допускает,
например, если состояние может изменяться)

> Германн © (17.03.11 04:57) [28]

> "От нас" ничего не скрыли.

именно скрыли. Если нет сорцов - то и надежно скрыли.

> И какой же глагол вы предлагаете использовать?

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

> Я предлагаю убрать свойства, а геттеры и сеттеры выносить
> в паблик \ протектед.
> Если же это суть поле, без методов доступа, то выносить
> в паблик прямо поле.

неудобно

> Я предлагаю убрать свойства, а геттеры и сеттеры выносить
> в паблик \ протектед.

И что же мы в итоге получим в Инспекторе объектов?

> _Юрий (17.03.11 01:06) [27]
>
> > Это хорошо
> >
>
> А по моему, так не очень.
> Дырявая абстракция.
> От нас скрыли, будет ли вызван метод, и таким образом непонятно,
> нужно ли запоминать полученное значение при многократном
> обращении, или можно обращаться к свойству.

А если функция, то понятно? Тебе известна реализация всех функций?

← →
Дмитрий Тимохов (2011-03-18 03:14) [35]

> Игорь Шевченко © (16.03.11 15:27) [15]
> пиши как хочешь, лишь бы было понятно

едрена вошь...

Игорь спер мой ответ.

А еще... я как-то прочел статью "каждой предметной области свой язык предметной области"

Для меня теперь это ориентир. Не бывает так - разработал подход и живешь с ним 10 лет. Все меняется, все изменяется. Главное, чтобы было понятно в конкретном случае.

> _Юрий (18.03.11 00:34) [31]
>
> >>clickmaker © (17.03.11 11:18) [30]
> Ну во первых, нет никакой гарантии, что сторонний класс
> написан "грамотно", во вторых часто логика объекта такое
> не допускает,
> например, если состояние может изменяться)

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

← →
Компромисс (2011-03-18 10:56) [37]

Ответ прост - надо всегда заводить локальную переменную и запоминать в ней значение свойства, метода и даже переменной.
По двум простым причинам:
1) а вдруг значение свойства/переменной/метода изменится между двумя вызовами.
2) а если потом выяснится, что нужно вызывать другое свойство/переменную/метод? Будете в 15 местах замену производить?
Вторая причина может плавно привести к выделению метода. Если что-то используется больше одного раза, можно выделить метод с параметром.

Так код

if(vasea.index > 15) then
callMethod(vasea.index + 20);

становится:

callMyMethod(vasea.index),

где callMyMethod - новый метод типа
callMyMethod(index: int);
begin
if(index > 15) then
callMethod(index + 20);
end;

и если вместо vasea.index надо использовать peatya.index + 1, То менять придется всего в одном месте

> Кроме этого, еще какие то доводы в пользу сокрытия в общем
> случае есть?

Есть.
Дизайнеры, датабиндинг и автоматически генерируемый (в том числе динамически) код.
Если убрать свойства, то где-то придётся хранить метаинформацию о гетерах/сетерах. Получится чудище обло, озорно, огромно, стозевно и лаяй.

именование методов, переменных Найти похожие ветки