Комментарии 56
Иногда использую префикс to для указания того, что переменная содержит объект (или коллекцию объектов), над которыми нужно произвести определенное действие. Например -- пробежаться по коллекции, для каждого элемента определить, требуется ли ее удалять. Если да, то индекс положить в список toDelete. Альтернативно можно было бы собрать список toKeep и пересоздать новую коллекцию, в которой только эти индексы. Идея именования переменной та же самая. Другие примеры -- toEdit, toPrint, toSend, toUpdate и т.п.
Спасибо кэп!!!
Всегда пожалуйста)))
В функциях (методах обьекта) если есть возможность сериализации в какой то формат, то стоит именовать метод как toXML(); или toJSON(); , если же форматов много то лучше делать convertTo(formatType) или serializeTo(formatType)
Мне добавить префикс to?
1) Min, Max, Total - должен быть суффикс в конце, а не префикс (CountMin, CountMax, CountTotal)
2) toXML - должно быть XMLfrom() - сначала получаемый тип
Где должен быть? Пожалуста укажите ссылку на источник, я впервые о таком слышу
А в нашем шарповом мире есть линку и там функции ToArray(), ToList() и т.д.
А почему? потому что екстеншены и можно писать так:myArray.Select(x => x.Id).ToArray();
А у вас какой мир?
MyObject.XMLfrom() ??? Это некрасиво, масло маслянное
По мне так не просто некрасиво, а запутывает. Как будто метод должен получить что-то на вход - из чего он собирается сделать XML. А объект тогда, наверное, какой-то сериализатор. Методы с префиксом to, используемые для преобразования - вполне распространённая практика, даже в стандартных библиотеках языков. Если очень хочется придерживаться принципа, что метод должен содержать глагол, то convertToXML.
Что-то на "процедурном" :)
XMLfrom
Мастер лишь такое придумать способен. Йода имя его.
Вы бы знали, сколько раз я людям на кодревью указывал, что булевые переменные надо называть с is*.
Как по мне, так префикс is совершенно не нужен. Например Active это уже само по себе прилагательное, которое указывает на определенную характеристику объекта, а именно "Объект Активен" - добавлять к нему еще is это, по-моему, откровенно избыточно. Can тоже очень спорно. Потому что сразу же вопрос "Кто что Can?" - это сам объект "can" что-то? Или кто-то другой "can" что-то? Почему просто не именовать так: canEdit -> Editable, canUpdate -> Updatable? Но это, впрочем, мелочи, потому что я когда-то видел такой шедевр имени свойства, как IsHasЧтоТоТам.
сразу же вопрос "Кто что Can?" - это сам объект "can" что-то?
На этот вопрос обычно отвечает контекст, к примеру:
user.canDo...validateUserPermissions() { bool canDo... = ...; }
Почему просто не именовать так: canEdit -> Editable
Сам по себе объект редактируемый или кем-то?
Вы предлагаете префикс заменять на суффикс, те же профильные яйца)
Нет, я предлагаю вместо myDocument.CanEdit писать myDocument.Editable, что более явно: "мойДокумент редактируемый (то что можно редактировать)". Второй вариант, к тому же, лучше ложится на шаблон: "объект - существительное", "метод - глагол", "свойство - существительное или прилагательное". Вы, конечно, правы в том, что если какой-то префикс хорошо ложится на контекст, то надо его и использовать, но, просто я постоянно наблюдаю как эти все is-has пихают на автопилоте куда ни попадя.
Я никому ничего не предлагаю, это не призыв к действию, это всего лишь рекомендательная памятка.
Булевы переменные удобно искать набирая is...
Active и Editable как property вроде бы ок смотрятся, по крайней мере плохой пример придумать не смог, понятно, что это is editable. Но вот is_admin поменять на admin - уже большая разница, is_admin - точно булевое, admin - там может и имя быть и ссылка на другой класс и т.п. Да и функцию editable() и active() делать не стоит, гораздо больше неопределенности. В целом, префикс is прямо сообщает нам, что возвращаемое значение в поле/функции булево.
Canтоже очень спорно. Потому что сразу же вопрос "Кто что Can?" - это сам объект "can" что-то? Или кто-то другой "can" что-то?
Спорно, если не знаете английский :) Can - это сам объект can что-то, всегда. Может ли объект быть редактируемым - can be editable. Is editable - редактируемый ли в данный момент объект. Passive voice можно почитать на эту тему
Но это, впрочем, мелочи, потому что я когда-то видел такой шедевр имени свойства, как
IsHasЧтоТоТам
Может поэтому вы и не поняли шедевр, там было написано всё нормально, но вы не смогли перевести? Is has - такого быть не может это грамматическая ошибка.
Is editable - редактируемый ли в данный момент объект
Есть другое мнение: https://dictionary.cambridge.org/dictionary/english/editable
Есть слова, которые могут быть прилагательным или глаголом при одинаковом спеллинге, например: bright и to bright. Префикс is или to устраняет неопределенность. isBright или toBright, все ясно.
Вызов метода toBright заставит объект сиять или сконвертирует его в яркий объект?
Если объект может быть тусклым, а может быть ярким, то наверное сделает его ярким. Да мне кажется Вы, несмотря на вопрос, так и поняли. Не так ли?
Хотя может выбор слова и не очень удачный.
Я это и спросил, чтобы показать неудачность вашего выбора. Префикс to может означать только конвертацию или приведение типа. А все вот эти глаголы, наречия и другие герундии не имеют никакого значения, потому что объект, это подлежащее, а метод - это сказуемое, а между подлежащим и сказуемым to не употребляется ни в каком времени. Как частица to применяется только рядом с инфинитивом, поэтому если мы где-то в ООП видим to, то это 100% не частица, а предлог.
setBrighter() тогда уж, но есть есть уровни яркости, лучше явно их передавать, а еще лучше increase делать без аргумента или с аргументом на сколько шагов ярче делать, заодно внутри можно будет инкапсулировать проверку на границы диапазона яркости.
Color.toBright() очевидно вернет яркую версию того же цвета (а если он уже яркий, то его же самого).
Есть ведь готовый глагол.
Префикс is однозначно намекает на булев тип. В противном случае не всегда понятно, что там внтури. Допустим, myObj.hyperlink -- это isHyperlink или свойство hyperlink, у которого ещё свои свойства есть?
>> Как по мне, так префикс is совершенно не нужен. Например Active это уже само по себе прилагательное,
Это хорошо работает только до тех пор, когда слово очевидно является именно прилагательным.
Но в английском языке полно слов, которые могут быть и прилагательным, и глаголом. И вот тут как раз начинаются проблемы.
Некоторое время назад на хабре упоминалась история про багу, которая получилась, когда программист вызвал у контейнера метод .empty(), ожидая, что это очистит содержимое контейнера. Но на самом деле этот метод просто возвращал bool, который показывает - пуст контейнер или нет.
Так что я всячески поддерживаю соглашение о том, что такие методы должны начинаться в "is".
get/set не нужны. Эти функции определяются по наличию аргумента.
В STL есть функция to_array().
Здесь префикс to_ означает: преобразовать в ...
Аналогично to_string() и еще ряд других.
Сложилось впечатление, что всю статью можно сократить до "руководствуйтесь правилами английского языка при нейминге методов, переменных и прочих объектов".
Для переменных, хранящих числовые значения, особенно если они относятся к количеству чего-либо, можно использовать префикс
countилиnum. Например:
countItems— количество предметов.
numPages— количество страниц.
countErrors— количество ошибок.
Тогда уж наоборот, ItemCount, PageCount, ErrorCount.
«CountItems» — это «пересчитать элементы», т. е. глагол, который больше подойдёт для продолжительной или затратной функции.
Считаю, что за префикс check нужно бить больно и беспощадно, особенно если методы с этим префиксом возвращают bool. Императив "сходи проверь" слишком многозначен. checkValidity может иметь поведение isValid (почему бы так не назвать), а может иметь поведение isNotValid (или это должно называться checkInvalidity?) или isValiditySpecified, isValidityConsisent. Единственное хотя бы немного оправданное поведение для функции/метода check -- бросать исключение, когда очевидно, что из-за значения Validity дальше все точно пойдет не так, но это тоже неочевидно, особенно что конкретно проверяла эта check-функция.
ГОВОРИТЕ ОТКРЫТО И СМЕЛО ПРЯМО В ЛИЦО! is, а не check!
HandleClick? Странно, всегда был onClick, onChange, onSubmit и прочее.
На моей первой и второй работе функции и переменные назывались как придется, не было каких-то соглашений. А вот на новой, где я уже 3 года всё почти полностью, как в статье этой. Со всем согласен тут кроме check, с ним нередко не очевидно становится, какое именно состояние ожидается. Видел вариант checkIsAvailable, который содержал какую-то непростую логику проверки с запросом на сервер.
Спасибо за статью! Можно брать за основу для приведения наименований переменных/функций к единому стандарту при командной разработке. Да и в принципе проще будет названия переменных придумывать: на это уходит львиная доля времени работы программиста :)
Ещё вариант "ought":
bool oughtToBeEnough;
:)
Спасибо за статью. Тема казалось бы простая. Но даже опытные разработчики порой делают ошибки в именовании.
Как вам такое имя свойства - getSystemFonts() : bool и имя метода для этого свойства getgetSystemFonts(): bool
Сразу понятно для чего оно? ?
Префикс fetch, по-моему, сомнительный. Если его использовать в слое бизнес-логики, он ломает абстракцию, т.к. прямо указывает на сеть. А в самом адаптере/сервисе для работы с внешней системой он бессмысленный - и так понятно откуда будет происходить get или retrieve.
С точки зрения английского, правильнее must, а не should, т.к. should носит рекоммендательный характер. Или я не прав?
Префиксы is, has, can, should… в нейминге переменных и функций