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

camelCase

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

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

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

SERVICE_ID_347

Непонятно, что это значит

SERVICE_ID_INTERNET_200MBIT_AND_TV_PREMIUM = 347;

Я бы назвал ID_SVC_NET200_TVPREMIUM

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

SERVICE_ID_INTERNET_200MBIT_AND_TV_PREMIUM = 347;

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

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

SERVICE_ID_INTERNET_200MBIT_AND_TV_PREMIUM

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

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

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

Главное не переусердствовать с длиной.

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

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

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

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

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

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

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

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

var  aaAaAbb
var  aaAAabb
func aaAaabb
func AaYaabb

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

Зачем тебе вообще какие-то константы? Это всё выдумки и глупости. Пиши 347 и всё.

Появление таких переменных в коде означает что архитектуру уже зафакапили.

$service = array (
   'id'    => 347,
   'speed' => 200,
   'tv'    => 'premium'
);

можно при желании в объект завернуть

$object = (object)$service;

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

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

Вот! Гениально!

тогда вот это конгениально:

$service = array();

$service[347] = array(
   'speed' => 200,
   'tv'    => 'premium'
);

$service[348] = array(
   'speed' => 100,
   'tv'    => 'standard'
);

У меня не всегда объявление переменной в 140 символов укладывается >_>

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

namespaces же. Условно

enum ServiceID {
  Inet200TVPremium = 347
...
}

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

Возможно.

Писать поэмы капсом в имени константы — это дичь, которая называется «научи дурака богу молиться».

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

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

А второй тариф ты назовешь $service2, наверное. Алсо, какой ещё array () если давно есть [].

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

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

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

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

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

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

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

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

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

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

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

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

А я так и знал, что Владимир - поехавший пенсионер из бюджетной организации.

SERVICE_ID_INTERNET_200MBIT_AND_TV_PREMIUM = 347;

Биллинг пишешь? Вообще тарифы должны храниться в БД чтобы можно было убрать, изменить или новые добавить

20 секунд - не хрен собачий.

В бд их любой джун поменяет, а так - джоб секьюрити.

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

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

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

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

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

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

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

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

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

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

)

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

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

Да хоть 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"
  }
}

SERVICE_ID_INTERNET_200MBIT_AND_TV_PREMIUM = 347;

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

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

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

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

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

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

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

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

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