Суть. Требуется номер телефона преобразовать в нужный формат для внешнего сервиса (сервисов много и каждому свой формат). Описание этого формата включает 3 поля:
1. Формат телефона в смысле глобальный, национальный, локальный или внутренний.
2. Шаблон.
3. Длина номера, к которому применяем шаблон (для внутренних форматов, т.к. их длина ничем не регламентируется — а длина нац. и глобального формата известна).
И вопрос вот в чем. Сама эта структура из 3 полей — это формат. И 1 поле этой структуры — тоже формат.
Сразу в голову не приходит как назвать правильно. В ходе дискуссии даже предлагали изменить архитектуру и отказаться от таких сущностей. Уже и самом рассматривал изменение архитектуры по причине сложности подбора адекватных терминов.
Так же был вариант психануть и назвать PhoneFormat1 и PhoneFormat2. Или PhoneFormat и FullPhoneFormat. Чуть лучше PhoneFormat и PhonePresentationFormat.
Но самые подходящие — это PhoneFormat+PhoneStyle и PhoneFormatType+PhoneFormat. Наиболее четко отражает суть сущностей. Сложно выбрать между двумя вариантами.
Вопрос вот в чем. Насколько вы заморачиваетесь с этим? Используете то что первое пришло в голову и то что потом требует пояснения или же можете пол дня подбирать подходящие термины?
Заморачиваюсь, т.к. считаю, что называть переменные/фенкции/классы/файлы — это важно. Потом слихвой компенсируется простотой и скоростью подключения контекста: что за переменная, что она означает. Также, на мой взгляд (данных проверить нету), это снижает вероятность ошибки, то есть неправильного использования переменной. А в долгосрочной перспективе, представьте, сколько времени потратят разные разработчики на понимание, что значит та или иная переменная? А если будут 2-3-5-10 мейнтейнеров кода, и на протяжении 3-5-10 лет? Они там каждый свой смысл понавкладывают, в итоге переменная будет Франкенштейном с кучей смыслов.
Никому не навязываю, как впрочем и не могу подкрепить свою точку зрения фактами. Это чисто мое интуитивное восприятие, основанное на опыте.
Хотя нет, вот как раз пример буквально из вчерашнего. Я делаю пет-проджект на питоне. И завел переменную как раз на скорую руку, думая "это пет прожект, просто играюсь, пофиг". В итоге уже буквально через 3 дня поймал себя на мысли, что на автомате неправильно трактовал эту переменную и начал писать уже новый код с логической ошибкой, основанной на неверном толковании переменной.
И это код, написанный мною, написанный пару дней назад...
Под катом многобукав с деталями из области видеокодирования и FFmpeg
Работаю в этом проекте с тремя типами видео:
1) YUV (это большущие несжатые данные, которые также называют raw, или сырые); данные лежат как есть и ты должен откуда-то извне узнать размер изображения и формат данных
2) Y4M (это то же самое, но в начале файла добавляется информация про размер изображения и формат данных)
3) H.264 (закодированное с каким-то битрейтом видео)
Изначально у меня была некая функция, которая принимала параметры:
Потом мне понадобилось добавить обработку 3го типа. А для него нужно только имя файла. Сделал такое допущение
def my_func(filename: str, pix_fmt: str = None, width: int = None, height: int = None):
...
is_raw = pix_fmt is not None and width is not None and height is not None
То есть если передается только имя файла, то это 3й тип.
Вот как раз переменная is_raw и стала тем примером, когда я забил на корректное название
В общем, дальше мне понадобилось принимать данные 2го типа. А это как бы raw, но для них тоже надо только файлнейм.
И также мне понадобилось вычислять средний размер фрейма вот так:
И я ни о чем не подозревая пишу такой код. Потому что рассуждаю так: если у меня сырятина (is_raw), значит считаем ширина на высоту и помножить на полтора, а в противном случае делим битрейт на кол-во фреймов за секунду и домотаем на 1000 (перевод из килобит в биты). Но тут-то и оказалась проблема, т.к. во втором случае (Y4M) он посчитает как битрейт поделить на 25 и умножить на 1000, что неверно. Так как это сырятина и надо считать по первой формуле
Хорошо, я достаточно быстро обратил на это внимание. Но для себя еще такой подумал "блин, вот же сразу не назвал правильно ))))".
Патриот здравого смысла
Re: Подбор именований - много ли уделяете внимания?
S>Суть. Требуется номер телефона преобразовать в нужный формат для внешнего сервиса (сервисов много и каждому свой формат). Описание этого формата включает 3 поля:
S>1. Формат телефона в смысле глобальный, национальный, локальный или внутренний. S>2. Шаблон. S>3. Длина номера, к которому применяем шаблон (для внутренних форматов, т.к. их длина ничем не регламентируется — а длина нац. и глобального формата известна).
S>И вопрос вот в чем. Сама эта структура из 3 полей — это формат. И 1 поле этой структуры — тоже формат.
S>Сразу в голову не приходит как назвать правильно. В ходе дискуссии даже предлагали изменить архитектуру и отказаться от таких сущностей. Уже и самом рассматривал изменение архитектуры по причине сложности подбора адекватных терминов.
S>Так же был вариант психануть и назвать PhoneFormat1 и PhoneFormat2. Или PhoneFormat и FullPhoneFormat. Чуть лучше PhoneFormat и PhonePresentationFormat.
S>Но самые подходящие — это PhoneFormat+PhoneStyle и PhoneFormatType+PhoneFormat. Наиболее четко отражает суть сущностей. Сложно выбрать между двумя вариантами.
S>Вопрос вот в чем. Насколько вы заморачиваетесь с этим? Используете то что первое пришло в голову и то что потом требует пояснения или же можете пол дня подбирать подходящие термины?
1 — Это адрес телефона, только в разных по уровню сетях, у нас сеть с коммутацией каналов, а уже как это записывается — это формат.
Программа – это мысли спрессованные в код
Re[2]: Подбор именований - много ли уделяете внимания?
Здравствуйте, Qulac, Вы писали:
Q>1 — Это адрес телефона, только в разных по уровню сетях, у нас сеть с коммутацией каналов, а уже как это записывается — это формат.
У телефона нет адреса, так никто не говорит. Вам нужно вносить пояснения в документации, что под адресом телефона вы подразумеваете то и то. И то, получится не PhoneAddress а PhoneAddressLevel.
Re[3]: Подбор именований - много ли уделяете внимания?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Qulac, Вы писали:
Q>>1 — Это адрес телефона, только в разных по уровню сетях, у нас сеть с коммутацией каналов, а уже как это записывается — это формат.
S>У телефона нет адреса, так никто не говорит. Вам нужно вносить пояснения в документации, что под адресом телефона вы подразумеваете то и то. И то, получится не PhoneAddress а PhoneAddressLevel.
Я всегда говорю, что у меня статичный ip-номер.
Программа – это мысли спрессованные в код
Re: Подбор именований - много ли уделяете внимания?
Здравствуйте, Shmj, Вы писали:
S>1. Формат телефона в смысле глобальный, национальный, локальный или внутренний. S>2. Шаблон. S>3. Длина номера, к которому применяем шаблон (для внутренних форматов, т.к. их длина ничем не регламентируется — а длина нац. и глобального формата известна). S>И вопрос вот в чем. Сама эта структура из 3 полей — это формат. И 1 поле этой структуры — тоже формат. S>Сразу в голову не приходит как назвать правильно.
Очевидно, что это не формат, а номер телефона для внешнего сервиса поэтому и название <ServiceName>PhoneNumber это всё что надо отдать, а внутри назвать PhoneNumberType/Type {local, E.164, internal, intranet }.
Я так понимаю, тебе надо, например, E.164 привести к какому-то внешнему формату который съест сервис? Это и будет номер телефона только в формате сервиса. Лучше описывать задачу не на базе того что ты уже придумал, а через то, что надо получить.
Где-то выше у тебе будут E.164PhoneNumber и твой <ServiceName>PhoneNumber будут иметь конструктор который примет E.164PhoneNumber.
Sic luceat lux!
Re[2]: Подбор именований - много ли уделяете внимания?
Здравствуйте, Kernan, Вы писали:
K>Где-то выше у тебе будут E.164PhoneNumber и твой <ServiceName>PhoneNumber будут иметь конструктор который примет E.164PhoneNumber.
Причем тут конструктор? Форматы хранятся в базе данных, сервисов много — очень много. Вопрос всего лишь в том как назвать сущность и поле этой сущности.
Re: Подбор именований - много ли уделяете внимания?