Префикс Is
Enabled vs IsEnabled
OriginAllowed vs IsOriginAllowed
AnyUserActive vs IsAnyUserActive
Success vs IsSuccess
SettingsAvailable vs IsSettingsAvailable
Кастомные булевы названия
AllowUserResizing | WasMoved | HasBeenCopied | NeedsDisposing | ShouldClose | CompleteSchedule | SuffixSent | ThrowOnCancelled
>Префикс Is
Да
Руководствуюсь чувством прекрасного и эстетикой. Программирование - это искусство. Можно тысячью способов сделать работающий код. Но код должен быть ещё и красивым, и здесь лишь художники способны на это.
Раньше я любил b или b_. Это хороший вариант, его ни в чем нельзя упрекнуть, кроме того, что он слишком далёк от читабельности как фрагмента естественного языка.
Поэтому я перешел на Is. Это было бы отличным решением. Но английский язык не может быть покрыт одним лишь Is. Появляются Are, Has, Have, Was, Were, а иногда даже Must, хотя возможно нужен Should, а может быть HaveTo, что добавляет многозначности в языкоразнообразной команде.
Приставка Not - явно дурной вкус. Особенно когда будет IsNotPetookh == false. Мой встроенный в мозг логический анализатор ломается на таком.
Я бы использовал префикс b в именах переменных там наиболее строгий, однозначный, нейтральный к языку. Но что делать с именами свойств, методов? Выглядит слишком уродливо. Получается лучше всё же по-английски писать.
> Программирование - это искусство
У нас как-то с преподавателем философии завязался спор на эту тему. Я тоже ему сказал, что это искусство, а он - НЕТ ЭТА ОБЫЧНЫЙ ИНСТРУМЕНТ НИКАКОЕ НЕ ИСКУСТВО.
> Но английский язык не может быть покрыт одним лишь Is
Ещё распространены Can и Has.
> Но что делать с именами свойств, методов?
Если брать C#, где есть свойства и события, то в нём могут быть коллизии между именами. Допустим, событие Authenticated, которое срабатывает после аутентификации аккаунта. И свойство, которое показывает, аутентифицирован ли аккаунт: bool Authenticated. Если мы не добавим Is к названию, то возникает коллизия. Поэтому имеет смысл добавлять Is к полям, которые описывают текущее состояние объекта.
Мне ещё понравился в качестве примера вот этот класс микрософтов с его именованием булевых свойств:
https://docs.microsoft.com/ru-ru/dotnet/api/system.windows.uielement3d.inputbindings?view=windowsdesktop-6.0
Но в целом, даже микрософты не пришли к какому-то единому стандарту именования булевых переменных.
https://softwareengineering.stackexchange.com/questions/439592/naming-convention-for-boolean-arguments
A field/property represents a state.
A method argument is a command.
Для полей мы используем префиксы в названиях, чтобы обозначить состояние. А для параметров методов - нет.
Но, опять же, допустим нужен ли здесь Is? По-моему он будет лишним:
anyPointersNull | allPointersNull
Может, если это поле класса, тогда стоит Is использовать. А если это локальная переменная, тогда не нужно.
Раз булеан отвечает на вопрос "да или нет?", то и такие переменные называю так, чтобы они это отражали. Для существительных, прилагательных и причастий обычно префикс is, для глаголов много чего, чаще всего can, но чаще стараюсь выразить глаголы через существительные и прилагательные и пишу is.
Ну, во-первых, стандартным правилом скоупа - если твоя переменная только в блоке на пять строк, то можешь её хоть жопой назвать. Если видна из разных модулей приложения - то желательно несколько слов потратить.
Если ты пишешь на статикодрисне без выведения типов - то требований опять же меньше (bool enabled вроде и так понятно), если на динамикодрисне - уже немного подумать надо, но если по контексту понятно, что это буль (например, параметр метода, а дефолтное значение у него буль) - то опять же не сильно много вопросов будет.
В руби, например, вообще префиксы типа is/has не одобряются. Названия методов, которые должны возвращать буль, по конвеншонам заканчиваются вопросительным знаком. Ср.:
user_banned = true if user.banned?
ueer_is_banned = true if user.is_banned
Но для локальной переменной можно при желании. В общем, хуй знает, как тебе нормально сформулировать. Это как у водителя спрашивать, как правильно сцепление отпускать на разных машинах - он и не думает об этом никогда, тут на каждой конкретной смотреть надо.
Богоподобной венгеркой конечно же bVarName
А если будет вот так:
class Person {
public string FirstName;
public string LastName;
public bool IsDvacher;
public bool bDvacher;
public bool BDvacher;
public bool B_Dvacher;
public bool Dvacher;
public bool YavliaetsaDvacherom;
}
Как лучше?
Если использовать переменные, то я бы так написал:
class CPerson {
public:
LPCSTR szFirstName;
LPCSTR szLastName;
BOOL bDvacher;
};
А если тебе нужно хранить выбранный возраст и булеву переменную, которая показывает, были ли вообще выбран возраст?
SelectedAge
32-й бит будет хранить булеву переменную. А возраст отрицательным быть не может.
В сях префикс is зарезервирован для библиотеки. Поэтому испольщую постфикс р из лиспа или никакого. И так видно, что она bool.
Это так. То и дело переименовываю переменные, превращаю циклы for в do while и переформатирую комментарии. А кто-то хуяк-хуяк и написал nginx.
Переменные ещё ладно. А частенько хочется архитектуру переделать. Вот тогда начинается совсем жесть. Я на такие вещи много времени убивал. Это ужас, это пытка разума.
Помню посмотрел код Майнкрафта. Там всё так красиво было. Идеально использованы паттерны проектирования. И ведь разработчик не тратил на написание архитектуры годы. Он просто делал игру.
> Помню посмотрел код Майнкрафта. Там всё так красиво было. Идеально использованы паттерны проектирования.
А потом посмотришь на тот же код, и увидишь шаблонную забагованную хренотень.
Приведу несколько примеров:
CanRotate| HasItem | ShouldUpdate
IsAuthenticated | IsFirstTimeLogin | IsMusicEnabled
IgnoreDefaultValues | AllowUserResizing | SupportsFlush
PreferHostingUrls | TrackAllCaptures | WriteInt64sAsStrings
> булевы переменные
зачем?
Иногда поражаюсь коду микрософтов. У них там две головы одновременно код пишут что ли.
- Если нет глагола, то указывается Is
- Если есть глагол, то он пишется с s в конце, если переменная указывает состояние
- Некоторые глаголы пишутся без s в конце, если это настройки или параметры метода (ты пишешь как бы в приказном формате Сделай То, Сделай Это)
- Есть исключения. Для параметров метода Is не используется. Просто передаётся утвердительная форма, вроде "animated" и "enabled".
isBordered | isEditable | isTracking | isTextDragActive | isDisplayingRepresentativeItem | isCustomizing | isFullScreen | universalLinksOnly | hasImages | canBecomeFocused
importsGraphics | drawsBackground | acceptsFirstResponder | usesFontLeading | showsMenuAsPrimaryAction | restoresFocusAfterTransition | enablesMarqueeWhenAncestorFocused | applicationSupportsShakeToEdit
useFastSameViewOperations | openInPlace
Синтаксический сахар вокруг возраста и булевой переменной.
Некогда не пишу эти ваши is, has.
Просто есть состояние 0 и 1. Все. Что еще надо? Чем отличается FileOpened от isFileOpened? Одним лишним словом, что часто приводит к инверсной логике и непонятности, что хотел сказать автор.
if(fileOpened) и достаточно, сам if уже этот is подразумевает.
Быть перфекционистом - это вред и не только для себя и для окружающих.
Тред настолько унылый, что приходятся бампять в тематике, блять.
> это вред и не только для себя и для окружающих
В чём вред для окружающих?
> Чем отличается FileOpened от isFileOpened?
В C# можно объявить события в классе. Вот "FileOpened" был бы событием, которое срабатывает после того, как открылся файл. Ещё может быть неоднозначная трактовка между OpenedFile и FileOpened.
Короче говоря, таким образом мы убираем все неоднозначности. Программист, увидев такое название переменной, будет 100% знать, что она хранит, ещё до встречи с первым IF, где её используют.
Если ты приготовил фикс/написал письмо и ходишь вокруг монитора без толку: посмотришь стоя, то сидя, то издалека, то вверх ногами, перечитаешь, тратя на это по пол часа, потом подумаешь и перепишешь, удалишь лишнюю запятую, ещё перечитаешь ещё перечитаешь, то это называется суходрочка, хотя некоторые называют эти ритуалы перфекционизмом.
А все ждут пока ты натанцуешься.
Человек должен знать меру идиальному.
Является ли в проектах серьёзных компаний обязательным использование только гетеров\сетеров вместо прямого обращения к данным?
С одной стороны использовать везде get()\set() - красиво, с другой - занимает больше размер текста программы и больше вызовов функций в коде.
Вообще - какая политика к сетерам\гетерам vs обращение к данным в проектах серьёзных компаний?
> Является ли в проектах серьёзных компаний обязательным использование только гетеров\сетеров вместо прямого обращения к данным?
Да.
Вообще не парюсь, всё зависит от контекста.
Вся ваша концепция чистого кода - хуйня, у меня есть эстетическое представление о коде, и думаю, у каждого с опытом появляется.
Посмотри видер: "Объектно-Ориентированное враньё".
Вообще нужно без них обходиться.
>2 пик
IsEnabled не равно !isDisabled, если состояний больше 2.
>3 пик
Для его старой башки может и тяжело читается.
> у меня есть эстетическое представление о коде
Пишу на лиспах, ссу в рот жаба- и питоноплебсу, потому что называю предикаты как
enabled?
origin-allowed?
any-user-active?
success?
settings-available?
и т.д.
>Является ли в проектах серьёзных компаний обязательным использование только гетеров\сетеров вместо прямого обращения к данным?
Да.
Другой вопрос, насколько это обосновано.
> const prefixVisible;
> const visiblePrefix;
> расположение имени изменяемого свойства (в данном случае: visible) до или после целевого объекта (в данном случае: prefix) в имени переменной не имеет никакого значения и зависит от Ваших личных предпочтений - оба синтаксических варианта отлично читаются и однозначно трактуются сторонними разработчиками.
ВИДИШЬ ПЕРЕМЕННУЮ visiblePrefix
@
ХОЧЕШЬ ПОЛУЧИТЬ ОТТУДА ВИДИМЫЙ ПРЕФИКС
@
ВМЕСТО ВИДИМОГО ПРЕФИКСА ТАМ ЛЕЖИТ TRUE ИЛИ FALSE
Вот и я о том же. Например, AgeSelected и SelectedAge неоднозначны. А если добавить Is, тогда все ок: IsAgeSelected и SelectedAge
>>2419514
>>2421064
Благодарю! Я посмотрел видео про ООП враньё.
Инкапсюляция, я так понимаю, начиная с некоторого уровня сложности кода вообще невозможна полностью, есть только степень инкапсюляции - больше или меньше, но никогда не 100%. Поэтому вся эта возня со скрытием данных просто ещё один небольшой шажок сделать свой код чуть более идеальным, но полностью идеальным он никогда не будет.
При помощи инкапсуляции ты показываешь другим программистам как работать с твоим классом. Если твой класс будет голым и открытым всему миру, как потасканная шлюха, то и отношение к нему со стороны программистом будет соответствующим.
А мне нравятся потасканные шлюхи: да, можно что-нибудь подцепить, но зато ей можно вертеть как угодно и больше возможностей удовлетворить свои хотелки. С целками же приходится плясать вокруг них и чаще удовлетворять себя самому. То самое выражение про свободу и безопасность.
Да, в бизнесе, где убытки, отчуждение и отстраненность такое не прокатит, но в своих проектах свобода очень приятна, особенно когда язык к ней располагает.