ДоговорНомер или НомерДоговора?

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

мне привычнее.

(0) нд - хорошее название. Очень легко пишется, попробуйте

Если православно - то ВоИмяТвоёДаСвятитсяСейНомерДоговораИСопровождающиеДокументы

ИдентификаторСоглашения

(4) Аминь добавить забыл

Зависит от контекста. Обычно наиболее естественным образом, т.е. "НомерДоговора".
Но если контекст перегружен сущностями, то бывает удобно их группировать по типу "ДоговорНомер", "ДоговорДата", "ДоговорУсловияВыполнения".

(6) Это слово пишется через 6 букв...

НомеръРяда

Придерживаюсь (7)

Изобретение имен длиннее двух букв свидетельствует о низкой квалификации разработчика

(11) Поржал. В типовых посмотри что твориться.

(12) + *творится.

(12) Это свидетельствует о низкой квалификации разработчиков типовых конфигураций.

(11) Вы, случаем, не апологет ректального программирования?

(15) https://ru.wikipedia.org/w/index.php?curid=6775969

(16) Увы, это невозможно свести к тому абсурду, что вы задвинули.

(0) не все ли равно ?

(16) когда читаешь что то смотри на дату. конечно если нужна зарплата а не пенсия

(11) Купи монитор побольше

(17) Это - не абсурд.
Если вы профессионал, тогда
1. Вы пишете программы так, как показано на первой картинке.
2. Всегда получаете смысл переменной не из ее имени, а из контекста.

(18) Чем опытней программист тем дольше он думает над именами переменных? Тру программист, Немчинский, говорит что над именем функции нужно думать дольше чем над ее разработкой.

(11) А как же процессорвыводарезультатакомпоновкиданныхвтабличныйдокумент?

(22) Над именем функции - да. Над именем переменной - нет.

(21)
1. true
2. false
(24) Параметры функции к переменным относим?

(23) Разве это - имя переменной?

(26) А что?

(25) Нет, конечно

(27) Имя метода

Безусловно. Смысл переменной вытекает из контекста. Контекст и есть источник ее смысла.
Но пренебрегать таким мощным вспомогательным инструментом ускорения понимания смысла как имя переменной, отражающее ее сущность - это... Это вредительство. Потому что такой человек может никогда и не читать свой код. Зато придется другим.

(22) надобно вопрос закрыть и забыть.

(29) Объекта

+(31) имя функции не компенсирует если в ней
сто циклов вместо одного запроса с топ 1

Хотя если ты апологет дядюшки фаулера и любая функция у тебя не длиннее шести строк, тогда нам есть о чем поговорить.

Еще раз, чтобы всем понятно было.
Вы придумываете имя ПЕРЕМЕННОЙ. Это имя должно действовать в пределах 5-10 строк кода.
Если у вас так не получается, тогда медитируйте на https://ru.wikipedia.org/w/index.php?curid=6775969 усерднее.
Требование к имени одно. Оно должно быть легко РАЗЛИЧИМО в этих 5-10 строках кода.
Факультативное требование - оно должно быть абстрактным. Потому что настоящий профессионал никогда не вникает в смыслы имен. Он их пропускает мимо сознания. И правильно делает. Например, он ни на минуту не усомнится в том что вот здесь:

СуммаАиБ=A*Б

он имеет дело с произведением. И никогда не допустит ошибки

калимулин пробил очередное дно...

(35) хотел бы я увидеть мало мальски крупную конфигурацию, где переменные используются в пределах 10 строк

(35) А ты уверен, что там произведение? А если это с++ и оператор * переопределен?

(35) Упаси бог работать с тобой в одной команде. В том что ты говоришь - есть крупицы смысла. Но в сумме - это суспензия. Взвесь смысла в дисперсионной среде бреда.
Профессионала никогда не обманет неправильное имя переменной. Он его прочекает. Но за правильное имя переменной он своему коллеге проставит пива, потому что он облегчил ему жизнь. А за неправильное - набьет морду. Фигурально выражаясь.

Блин, я столько раз правильно называл переменные, но  пива мне так никто и не налил :(

(40) Я самому себе регулярно наливаю. Когда долго работаю на одной кодовой базе. Только тссс... Волшебник такое не прощает.

безалкогольное же ;)

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

Называй как хочешь, ты автор, тут ты заказываешь :)

(6) славящие правь амона не поминают!

если сущность договор есть, то договор номер, а если нет, то номердоговора

(39) А за "неправильное" имя следует проставлять 50-летний коньяк. Потому что "правильное" имя тянет коллегу на дно нубства. А "неправильное" имя поднимает на вершины абстрактного мышления.
Расслабьтесь, коллеги )))

Сначала объект, потом реквизиты. Всегда так делаю (по привычке)

ДоговорНомер
ДоговорДата
ДоговорГФУ
ДоговорПартнер

и т.д.

(47) Слушай. Я есть где просветлиться твоим продакшн-кодом из шестистрочных функций, не требующих осмысленных имен переменных? Ты просто порвешь мой шаблон. Потому что обычно получается все ровно наоборот. Открываешь очередную простыню - и мать моя женщина... Сплошные непристойности между сoupling и сohesion. Прям во все отверстия.
Рефакторинг чужого кода я обычно так и начинаю - понял, что означает очередное "к2" и сделал очередную автозамену. А по ходу осознания общего смысла уже декомпозицию человеческую делаешь.

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

(35) "он ни на минуту не усомнится в том что вот здесь: СуммаАиБ=A*Б он имеет дело с произведением"
На тему произведения и суммы. Тема раскрыта. Просвещайтесь (пока не запретили)! )
https://www.youtube.com/watch?v=BwPT8_bB8dY

(49) Ты угадал :))
Я конечно не знаток кода автора, но как-то помнится он вывешивал свои портянки. Про длину переменных нихрена не помню, но код был - лаша лапшой.

(11) Вот ты и продемонстрировал свою квалификацию. Код должен быть читабельным, переменные - информативные, а копрокодеры, которые используют однобуквенные переменные не только в итераторах, но и в основном теле кода, должны гореть в аду.

По теме - также придерживаюсь (7), и это не только к 1С относится.

(53) Я с какого-то периода даже в итераторах перешел на длинные мнемонические (за редкими исключениями). Зря я, что ли, слепой десятипальцевый осваивал :)

(55) Дело хозяйское, конечно, но мне так удобнее эти итераторы вычленять при беглом просмотре кода. Если одна буква - то точно итератор, а не хрен пойми что :)

Есть же правила образования имен переменных о чем спор?
https://its.1c.ru/db/v8std/content/454/hdoc

(57) В обоих случаях назначение переменной понятно и однозначно. Вопрос лишь удобства группировки в варианте 1.

(56) Выражения во вложенных циклах легче читаются.

(58) Я про сообщения (3) (14) (35)

(35) Давай пример своего правильного кода. Повосхищаемся.

соглашусь с (48)
пДоговорНомер
А так называй как хош

(48) Реквизиты то да.
но речь про переменную.

(60) Аа, да там даже комментировать нечего.

(0) Какая нафиг разница ?

(65): для ускорения понимания (при чтении кода) того, что содержится в переменной.
последовательность "наименование объекта - детализация" тоже кажется оптимальнее. да и по алфавиту более близкое по смыслу будет стоять рядом (в списочных представлениях объектной модели)..

Первое слово отвечает на вопрос что и существительное, остальное потом.

вот и вывели правило  >>> последовательность "наименование объекта - детализация"

(68) Это доменный принцип наименования. В интернете примерно также :)
Но в понятном контексте это лишнее и рулит естественный язык.

Надо значит читать совершенный код, чистый код. Может там это есть.

(65) Надо в одной парадигме программировать. Сегодня так, завтра так напишешь. Бардак будет.

(71) ©анекдот про врача, строителя и программиста

вроде не пятница

Стас, ты зачем мою ветку топишь? Не хочешь что бы я выходил из гугл программистов?