Какие есть соглашение по именовнию переменных «список свойств объектов»

objectNames или objectNameList.

А это не приведет к неоднозначности в количестве объектов? Например если список групп пользователей (userGroups) и список групп, в которые входит текущий пользователь (опять userGroups?)

Назови xs.

groups. Неоднозначность устраняется зависимостью от контекста

Оба варианта плохие.

Почитай «Совершенный код» или «Perl Best Practice» там очень подробно описано как нужно именовать переменные и пр. Лучше первую книгу, т.к. там есть ссылки на исследования, а значит выводы обоснованы.

object_names_

xs слишком абстрактно; другое дело - ns, сразу ясно, о чем речь.

«Совершенный код» или тем более «Perl (лол) Best Practices» не читай - говно для обезьян безмозглых. Читай сорцы на Хаскеле и Окамле, сразу станет ясно как и что называть.

«objectsNames» не звучит по-английски. А вот, «objectNames» вполне можно перевести как «имена объектов».

Google translate «имена объекта» и «имена объектов» переводит одинаково. Может, кто хорошо знающий англицкий подскажет.

Оба варианта плохие.

И как по преведенным тобой книгам следует выбрать имя в этом конкретном случае?

Во-первых, имена переменных (и объектов) советуют выбирать в такой форме:

«сущность переменной»_«принадлежность к чему либо»

Средняя длина имени переменной 10-16 символов (статистические исследования показывают, что при этом меньше всего сил тратится на отладку программы).

Короче, лучше так:

list_of_(чего там у тебя за объекты)

Подчеркивания использовать лучше чем заглавные буквы потому, что: «ПодчеркиванияИспользоватьЛучшеЧемЗаглавныеБуквы»

Конкретный пример во втором посте.

Про него и вопрос, а не про подчеркивания простив CamelCase. Если бы у меня было «чего там у тебя за объекты», то вариантами были бы просто objects или users. Вопрос в другом.

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

list_of_names_of_objects

Скорее всего при более удачной структуре эту переменную можно будет назвать

list_of_names

Google translate «имена объекта» и «имена объектов» переводит одинаково.

Я тебе и говорю о том, что эта фраза по-английски должна звучать одинаково. Это в русском есть различие.

Ага,

list_of_names_of_objects = get_list_of_names_of_objects(list_of_objects);

И что тебя смущает?

Если избавиться от окончания «_оf_objects» получится, хороший, легко читаемый, понятный код, но и с окончанием тоже понятный и опечататься при наборе сложно, и проблемы окончания «s» нет.

Меня смущает:

* тип в имени

* концентрация на понятности имени биндинга а не функции

Нормальный человек напишет:

ns = object_names(os);

(Прошу заметить, информации потеряно ровно 0)

Ну, или если он только купил новую клавиатуру и привыкает к ней, то:

names = get_object_names(objects)

Уже, в общем-то, начинает выглядеть несколько дебильно, но вроде еще приемлемо.

1. ns, os — ужасные имена переменных, из названия непонятно, что они означают.

2. судя по посту наименование object_names вызывает кучу вопросов (про «s», про порядок слов), а вот names_of_objects — нет, тут никакое «s» отбросить нельзя и слова местами не поменять.

3. list — это не тип в имени, а сущность переменной

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

1. ns, os - отличные имена переменных, из названия их типа должно быть понятно, что они означают; зачем мне думать вместо компилятора, читая длинные имена с «сущностями», - неясно.

2. я согласен на names_of_object, all_names_of_all_objects или как угодно, лишь бы автору было понятно что делает функция, потому что функций с типом (Объекты -> Имена) миллиард разных.

3. 'Сущность' переменных должна быть в типе.

Многословность не помогает выглядеть «тривиально».

http://img3.joyreactor.cc/pics/post/фото-конь-793103.jpeg

Не нужно дополнительно напрягать мозг на понимание уже написанного кода

Ну тогда lpListObjects как в WinAPI

это в гайдлайнах должно быть прописано.

Общих правил нет, и быть не может.

names = get_object_names(objects)

Уже, в общем-то, начинает выглядеть несколько дебильно, но вроде еще приемлемо.

в пхп и других нендоязычках с глобальным пространством имён так и надо :)

1. ns, os — ужасные имена переменных, из названия непонятно, что они означают.

в контексте класса всё понятно. В контексте класса непонятно, зачем писать для метода FooMethod(), если снаружи надо писать Foo::FooMethod(), а внутри и так понятно, что оно внутри?

Выступать с мнением «и ежу понятно», «очевидно» против объективных выводов, подкрепленных статистическими исследованиями, как-то глупо, не правда ли?

http://libra.msra.cn/Publication/767591/debugging-effort-estimation-using-sof...

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

Выступать с мнением «и ежу понятно», «очевидно» против объективных выводов, подкрепленных статистическими исследованиями, как-то глупо, не правда ли?

http://libra.msra.cn/Publication/767591/debugging-effort-estimation-using-sof...

эти выводы верны исключительно для программ на Cobol, да и то не всех, а только учебных хэлловорлдов. Да и вообще, как-то глупо в качестве доказательства приводить пруфы в рамках ЯП, который как раз и критикуется всеми за свою многословность. Ясное дело, что программисты просто вынужденны так называть функции, иначе в _их_ программах будет ничего не понятно. Там и так моск сломаешь: «The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.» Если там ещё и переменные обзывать «ns» и т.д., то можно сразу психиатру звонить, чтоб забирал. :)

В более новых и развитых ЯП необходимости для этого меньше, назначение и тип переменных и методов и так очевидны из контекста.

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

спорно. Естественный язык не предназначен для описания алгоритмов для компьютера. Он предназначен для описания алгоритмов для людей. А люди отличаются от компьютера, и прежде всего тем, что умеют думать и додумывать. Компьютерам в этом плане пока ещё далеко до человека (хотя подвижки есть, например gcc уже сейчас умеет выбирать оптимальные структуры данных и машинные команды при оптимизации. Но надо использовать C, что-бы вместо int компилятор смог самостоятельно подставить самый быстрый тип, и что-бы при вычислении x-- - --x смог додумать за программиста, что это выражение константно равно нулю)

Что до имён переменных/методов, то они исключительно для людей нужны, а стало быть, не должны дублировать имеющуюся информацию. В контексте класса C++ все данные относятся к классу, потому в их именах упоминать их класс не нужно и вредно. Тип всегда не нужно упоминать, ибо он к переменной не относится, и всегда может измениться (т.е. одна и та же сущность может быть в одних системах double, а в других int, и программа обязана работать правильно, вне зависимости от типа).

Хороший код должен читаться как алгоритм, написанный в математической нотации, потому что естественный язык слишком ambiguous.

3. 'Сущность' переменных должна быть в типе.

Это если у тебя объекты сложных классов, а если простые типы типа int или string.

Ну, в нормальных языках есть что-то вроде

newtype MyFancyInt = MyFancyInt Int

где Int - примитивный тип, MyFancyInt - обертка над ним без всякого рантайм оверхеда, но с другим типом.

В ООП-языках о таком, конечно, редко задумываются.