У меня имя массива часто совпадает с именем таблицы, а элементы массива с именами столбцов таблицы.
Дальше по аналогии:
$user['id'] - user_id
$user['name'] - user_name



_____________
Бесплатному сыру в дырки не заглядывают...

Ну тут немного не то. Тут речь просто о переменных, по твоей аналогии должно быть

$user['group_id']

или

$user['id_group']

Rand
Вот. Уже конкретика. Спасибо.

Еще есть соображения?

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Аааа, ёпто! Так бы и сказал. Для меня вообще не ставится вопроса писать id_user, это же убожество. От общего к частному. Сначала речь идет о пользователе, а уже у пользователя - id. Но зная, дядя Коля, твою бунтарскую сущность скажу, что пиши не как все, иначе будешь как серая масса. Пиши, например, us_id_er или prod_id_uct - это очень клево и никто так не делает!

_____________
Свои мозги еще никто не отменял.
Телепатов нету.

id
id_user
id_group
id_something

Так же поддерживаю версию user_id.

Потому что пример: "Можно сказать номер_шкафа или шкафа_номер", не корректен на мой взгляд, т.к. мы ищем - шкаф, а не номер шкафа. Номер шкафа лишь конкретизирует его месторасположение.

Если бы "задача" так сказать была найти номер, к которому привязаны разные значение, то да, было бы правильно Номер->Шкаф, а так мы ищем -пользователя у которого есть свой ID, Name, Address и etc.

Т.е. - user_id - я считаю более корректно.

Взять ту же БД... из пхпнет

Указывается пользователь базы данных, но никак ни база данных пользователя, хотяяя <_< ... может быть и база данных пользователя, но это как говорится - Другая история... :lol:

Бляяя! Где ты раньше был)))

Да какое тут бунтарство. У меня тоже вопросов не возникало, когда была змеиная нотация. Но когда встал вопрос о lowerCamelCase, стало неуютно. Как ты там сказал... убожество: userId. А если levelId, вообще не читабельно. Куда эстетичнее наоборот: idUser. А тем более idLevel. Сущность с большой буквы, уважительно)))

А так, как (ты правильно заметил) я никогда слепо не иду по течению, хочу узнать, ради чего такие жертвы.

Буржуйский язык, это понятно. Но не столь важно в приватном проекте.
А что еще важного? Мои визави ничего другого не придумали. Тут тоже пока один слабенький аргумент. Нужно быть уверенным в том, что так надо. А не просто потому, что так надо.


_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Принадлежность, характеристика, свойство, опция, как угодно называй. Это не отменяет что сначала вещь, а потом её черта. У user есть id, есть name итд.

Правильность языка в английском тут можно считать просто совпадением, я бы это за довод вообще не принял. Возьми правило из китайского, арабского, вот тебе будет контрдовод. То есть на русском я бы всё равно писал пользователь->номер или получитьПользовательскийНомер.
Да хоть получитьПользовательНомер, 100 раз говорил что не надо к ЯП относиться как к литературному английскому, это совершенно разные вещи.

Почему именно так? Потому что нужно какое то правило что бы в рамках проекта писать в одном стиле. Правило "сначала объект, потом свойство" более логично в языках программирования, да и в жизни на мой взгяд.

$переменная = значение
объект->свойство
название_принадлежность 
главный, второстепенный
[1, 2]

1 простое правило и больше не надо морочить голову.

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

Code style лучше выбирать самый распространенный, чтобы как можно меньше новых членов команды испытывали вот это:

Ко всему можно привыкнуть, но чем меньше людей это будет делать, тем лучше, поэтому стоит подумать не только о своём комфорте, но и о тех, кто придет после вас. В качестве примера - в code style Laravel конкатенация строки пишется без пробела, от чего у меня "дико бомбит", т.к. эта операция ничем не отличается от других. Сразу возникает вопрос - кто это такой вумный в команде разработчиков? Как будто бы решение продавлено авторитетом. Он художник, он так видит Не надо так делать пожалуйста )

Так и есть:
$user['group_id'] — user_group_id

_____________
Бесплатному сыру в дырки не заглядывают...

Чет не то... Зачем искать то. ID может быть и не в таблице базы данных. Это просто идентификатор. И если смотреть с другой стороны, то переменная содержит. Что содержит, шкаф или номер шкафа? Вопрос, что первичнее. Если рассуждать логично, то все-таки номер. Идентификатор. Значит он есть суть вопроса. А его на задворки. :(

Вот допустим если аргументы, в каком порядке обычно пишутся? Так

    public function __construct($id, $locker)

или наоборот? Тут ни у кого вопросов не возникает почему то обычно, ибо идентификатор важнее. А в переменной наоборот почему то.

Arh

В том вся и печенюшка, что тут главное - идентификатор. А уже потом принадлежность.
Паспорт транспортного средства.
Номер серии
Сертификат соответствия

Это логично. Но только с точки зрения русского языка. В английском все наоборот. Потому так и пишут, и тут твоя логика не канает. Просто так сложилось, что мы вынуждены придерживаться их правил.






_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Да не про таблицу я вовсе. Я сейчас DDD практикую, там вообще нет таблиц как таковых. И уж тем более ключей. Есть сущности и есть их идентификаторы. И если у меня поля по порядку, то вот так намного красивее

class Foo
{
    private $id;
    private $idUser;
    private $idGroup; 
}

чем вот так:

class Foo
{
    private $id;
    private $userId;
    private $groupId; 
}

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

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Да надо абстрагироваться от литературных правил. Это не литературный язык.

Назови это "правилом весомости". От большего к меньшему. Правило сортировки, не знаю.
машина.паспорт.номер
машина.колесо.шайба
открыл дверь -> зашёл в квартиру

А ты считай что америкосам не повезло в этом плане.
То есть у них постоянно возникает проблема смешивания литературных понятий и понятий программирования. Потому что в литературе open door, а в коде $door->open, вот у них крышу сносит.
А у тебя всё по полочкам, есть язык программирования, а есть красивый поэтичный литературный русский =)

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

class Foo
{
    private      $Id;
    private  $userId;
    private $groupId; 
}

но речь то не о красоте, а о том что бы было понятно.

_____________
Стимулятор ~yoomoney - 41001303250491

Это наименьший дискомфорт, с которым ему придется столкнуться))) Потому что в то, что я сейчас делаю, не могут врубиться дядьки с 5-6 летним стажем на Yii. Какие идентификаторы нафиг))) Но зато красиво. И логично.

А я вот иначе рассуждаю. Я когда то занимался версткой. Не, не этой версткой, не веб. Настоящей. Так вот, там есть понятие "кернинг". Это когда шрифт не моноширинный, а приятный глазу. Потому что буквы разные, и допустим если поставить рядом буквы У и А без кернинга, будет некрасиво. Потому что у них загиб в одну сторону. Кернинг сокращает расстояние между ними, чтобы создать впечатление ровных расстояний.

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

    $laravel .'зря они так)';

Так что тут не просто кто то что то там сказал, а есть жесткое обоснование. А с переменными пока не нахожу...

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.