LINUX.ORG.RU

Допустимо использовать длинные названия для констант и переменных?

 


0

1

Речь идет о PHP, но мне хотелось бы узнать и о практике в других яп. В моем случае есть идентификаторы услуг, и в зависимости от них нужно производить какие-то действия. Напр. Услуга интернет 200 мбит и тв премиум имеет ID 347.

SERVICE_ID_INTERNET_200MBIT_AND_TV_PREMIUM = 347;

не самое длинное, а если больше то как быть? Может так SERVICE_ID_347?


Никто не мешает переименовать потом на месте если эта константа используется несколько раз в блоке кода и портит его читаемость своей длиной.

Если указанная константа далеко от использующего ее кода то длинное название оправдано, если их несколько таких то я бы из них сделал мапу вроде service_ids = {…разные услуги: их id}.

WSL_user
()

Имена переменных должны быть понятными и удобными. Баланс между ними это вкусовщина. При желании, можно internet сократить до inet и убрать and. При большом желании, service id сократить до sid.

d ★★★★
()

В моем случае есть идентификаторы услуг, и в зависимости от них нужно производить какие-то действия

SERVICE_ID_INTERNET_200MBIT_AND_TV_PREMIUM = 347;

Не надо так. Для этого придумали enumerations.

vvn_black ★★★★★
()

Да. Чем понятней, тем лучше. Длина не принципиальна. Внутри отдельного блока, функции, если она часто используется, завсегда можно ввести временный псеводним (реализация разная, в зависимости от возможностей языка, может быть псевдоним, а может и другая локальная переменная).

SERVICE_ID_INTERNET_200MBIT_AND_TV_PREMIUM

очень понятное и хорошее название.

Сокращение слов полезно делать, когда есть привычное клише, шаблон, как тут, например, вместо identificator написано id.

soomrack ★★★★★
()
Последнее исправление: soomrack (всего исправлений: 1)

Если нет ограничений со стороны языка/инструментария или принятого в проекте/компании стиля, то делай как удобнее.

anonymous
()

Допустимо. Всё равно твой код кроме тебя никто читать не будет) Шутка.

Вообще, программирование - творческое занятие, где помимо сочинения алгоритмов и структур часто приходится тратить значительное количество усилий на сочинение имён своим абстракциям.

Программист - это своего рода писатель или даже, если хотите, метаписатель, выдумывающий каждый раз свой новый язык в каждой своей программе и функции. И как любому хорошему писателю ему нужно обладать определёнными способностями.

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

Очевидно, что и физическое и психическое состояние сказывается на творческих способностях. Занятия спортом, медитация, холодные ванны, здоровая диета, в том числе информационная, крепкий сон, общение с приятными людьми и даже время суток - всё это может влиять на то, насколько чистыми, точными, ёмкими и простыми будут наши мысли и слова.

anonymous
()

А тебе вообще нужна такая константа в коде? Может тащить из базы набор услуг входящих в тариф, а вот это твое «действие» сделать услугой, которая входит или не входит в тариф?

cobold ★★★★★
()

если открыть главную страницу гугла, ну или каких либо сервисов, то можно увидеть переменные и функции вида:

var  aaAaAbb
var  aaAAabb
func aaAaabb
func AaYaabb

гугл же райская гавань для программистов. Будь как гугл, делай нейминг непонятным!

TPPPbIHDELj
()
Ответ на: комментарий от ya-betmen

ограничение в 80 символов уже давно не актуально.

Ух ты, орлы в треде! Завидую количеству пикселей в ваших глазах.

Zeta_Gundam
()
Последнее исправление: Zeta_Gundam (всего исправлений: 1)

Есть такая тонкая хреньгрань, называется «чувство меры». КОГДА_КОД_ОРЕТ_НА_ТЕБЯ — это уже немного странно. Поэтому упоротое применение даже явно недокументированных соглашений должно регулироваться коллегиально на кодревью. Есть один жупел в кровавом энтерпрайзе — «понятность/читабельность». Они ее понимают как «понятность идиотам» - и только идиоты хотят читать такой код: ПОНЯТНОСТЬ_ТОГО_ЧТО_ОЧЕВИДНО_СИЛЬНО_ПЕРЕОЦЕНА = КОД_НАПИСАННЫЙ_КАПИТАНОМ_ОЧЕВИДНОСТЬ_ЧИТАТЬ_ВСЕ_РАВНО_БОЛЬНО. Хотя и по другим причинам.

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)

namespaces же. Условно

enum ServiceID {
  Inet200TVPremium = 347
...
}

Краткость собственно имени зависит от контекста, от того, кто будет читать код. Если много человек поверхностно в текстовом редакторе без доступа к документации, то можно более длинные понятные, если мало человек, которые должны хорошо разобраться, то лучше короче (длинные имена приводят к информационному шуму). Но вообще всё описание в имя всё равно невозможно засунуть

caryoscelus
()

Ну тебе половина скажет что очень наглядно так и делай, половина скажет что нужно записать как SERV200TVPREMID и ни буквой длиннее, ну и еще они поделятся на CamelCase и snake_case. А вывод один, никакой разницы нету, дело вкуса, поэтому лучше следовать одинаковой логике в проекте и все, что бы можно было по признакам определять что есть что, писать большими буквами это например полезно, сразу понятна константность.

Но я бы рекомендовал не использовать константы просто, а поместить это в БД. Чем меньше кода в программе тем лучше, перемещать код в данные это неплохой вариант.

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)

Допустимо использовать длинные названия для констант и переменных?

Здесь важно уметь создавать удобные названия.
Например: VpНачДата, VpКонМесяца, VpКолДней, flСозданиеНовогоДокумента, ...

Единых правил «как» - нет.

Кстати многие ЯП, поддерживают возможность использования названий в национальной кодировке.

Например, приведённый пример названий для C++ вполне корректен.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 3)
Ответ на: комментарий от anonymous

А второй тариф ты назовешь $service2, наверное.

Я предлагаю прочитать чуть дальше. Так и знал что придется разжевать предлагаемый подход иначе не поймут

Алсо, какой ещё array () если давно есть []

Запрети мне юзАть array(), с ним я массив, с ним все меня боятся…

Obezyan
()
Ответ на: комментарий от Obezyan

Почитал дальше. Массив с числовыми индексами (где индекс это айди клиента или что там у опа) это ещё веселее - кто-нибудь отсортирует криво и до свидания.

А начинали вообще с констант, которые вообще тут не к месту.

Но в целом я с тобой согласен.

anonymous
()
Ответ на: комментарий от anonymous

кто-нибудь отсортирует криво и до свидания

Этот индекс является идентификатором строки строки из бд (и по совместительству - автоинкрементным индексом). Попробуйте отсортировать этот индекс криво, мне даже интересно на это будет поглядеть в php.

Но в целом я с тобой согласен.

Вы нарушете первое правило ЛОРа - никогда нельзя соглашаться с собеседником и не важно что он там говорит.

Obezyan
()
Ответ на: комментарий от Obezyan

Этот индекс является идентификатором строки строки из бд

Но про бд ты не писал.

Попробуйте отсортировать этот индекс криво, мне даже интересно на это будет поглядеть в php.

Да хоть sort($service);

Array
(
    [0] => Array
        (
            [speed] => 100
            [tv] => standard
        )

    [1] => Array
        (
            [speed] => 200
            [tv] => premium
        )

)

anonymous
()
Ответ на: комментарий от anonymous

Но про бд ты не писал.

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

Да хоть sort($service);

Ну, тут мои полномочия все. Вы правы, если так сортировать массив со значащими ключами, то программисту лучше сразу заявление по собственному писать.

ksort($service);


array(2) {
  [347]=>
  array(2) {
    ["speed"]=>
    int(200)
    ["tv"]=>
    string(7) "premium"
  }
  [348]=>
  array(2) {
    ["speed"]=>
    int(100)
    ["tv"]=>
    string(8) "standard"
  }
}

Obezyan
()

SERVICE_ID_INTERNET_200MBIT_AND_TV_PREMIUM = 347;

Толстых в программировании пруд пруди. Из личного опыта запомнился случай, из времен моей падаванской юности. Написал я функцию слияния двух списков (по какой-то там бизнес-логике). Сигнатура выглядела достаточно стандартно

List<Entity> iDontRemeberName(List<Entity> a, List<Entity> b)

Так вот, один классический сеньор-помидор аж покраснел, начал обзывать меня гамнокодером, только потому, что ему имена а и b казались слишком короткими. На крики собрался целый консилиум, во главе с главным в команде. На мой вопрос, о том какие имена выбрали бы они, прозвучал лишь ответ listA и listB.
Думаю, не стоит упоминать, что все мои доводы и даже апелляции к авторитету авторов JDK остались незамеченными.

По теме. Есть золотое правило именования — чем больше область видимости переменой тем длинее может/должно быть ее имя.
Также не стоит добавлять слова не несущие никакого смысла, как AND в твоем случае. Также MBIT, так как и так понятно, что каналы провайдеры меряют не колограммами.
Я бы назвал, скорей всего, INET200_PREMIUM или SERVICE_200_PREMIUM, в зависимости от контекста и задачи. Если верно подобрать схему именования то будет и так понятно, что отвечает за ширину канала а что за ТВ.

urxvt ★★★★★
()
Ответ на: комментарий от Obezyan

Запрети мне юзАть array()

там же хеш-таблица, а не массив, т.е. когда вы пишете array, вы лжете в коде, а с квадратными скобками делегируете этот разводняк разработчикам похапэ;)

Syncro ★★★★★
()
Ответ на: комментарий от Syncro

А что там должно было быть вместо упорядоченной хеш таблицы с сложностью О(1)? Бинарное дерево со сложностью O(log n)?

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

Obezyan
()
Ответ на: комментарий от Obezyan

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

Syncro ★★★★★
()
Ответ на: комментарий от Syncro

у массивов не может быть ключей, а хэш-таблицы не являются упорядоченными…

Вы даже на вбросить нормально не можете. У меня от вас испанский стыд. Тот самый случай когда 5 звёзд это диагноз.

Obezyan
()