Соглашения об именах переменных для карт/списков в языках с динамическим типом

Это обычная жалоба новичка. Вы можете использовать соглашение об именах, но есть вероятность, что вы слишком скоро откажетесь от него и сосредоточитесь на том, что представляет переменная (ее значение по отношению к остальной части кода), а не на том, как это представлено (это "тип").

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

1. количество платежей, подлежащих оплате на эту дату (paymentsDue)
2. количество дней между отображаемой датой и другим моментом времени (daysPassed)
3. количество сообщений, опубликованных в этот день в Stack Overflow (numberOfPostedMessages)

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

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

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

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

1. Используйте хорошие имена переменных. Например, если у вас есть сопоставление дат с целыми числами, вы можете назвать его как-то вроде BirthdateToTotalLookup.

2. Узнайте, какие визуальные подсказки искать. Это может показаться очевидным, но мне потребовалось некоторое время, чтобы выработать привычку искать такие подсказки:

   sum += x['10-16-92']
   

Из фрагмента кода выше я могу сказать, что x — это карта, которая имеет дату в качестве ключа и возвращает какое-то число.

Если имена могут быть короткими, то я склоняюсь к тому, чтобы называть карты как-то вроде "nounToNoun". Поэтому, используя ваш пример отображения дат в целые числа, я бы назвал это «dateToCount» (если целые числа являются счетчиками для чего-то). Таким образом, очевидно, что это карта, и очевидно, что на что сопоставляется. Проблема в том, что иногда трудно сделать такие имена короткими и читабельными. Например, «userToLoginHistory» становится немного громоздким.

Для списков я обычно использую множественное число для имени переменной. Таким образом, «пользователь» будет одним пользователем, а «пользователи» — списком пользователей.

Честно говоря, я не уверен, какое хорошее название подойдет для списка карт.

Одним из преимуществ динамических языков является то, что даже если вы используете объект в качестве карты, он не ДОЛЖЕН быть картой. Все, что ему нужно сделать, это поддерживать любые сообщения, отправленные ему. В Groovy, если я знаю, что данный метод ожидает карту, чтобы он мог искать вещи с помощью ключа String, я могу дать ему полную карту, урезанную карту, Expando со свойством, названным так же, как ключ или любой другой объект, у которого есть свойство, названное так же, как ключ. Это потому, что someObject["keyname"] и someObject.keyname — это одно и то же. (Конечно, если код вызывает someObject.get("keyname"), мне нужно каким-то образом подключить этот метод.)

Дело в том, что в таком динамическом языке, как Groovy, вы меньше думаете о ТИПАХ и больше о ПОДДЕРЖИВАЕМЫХ СООБЩЕНИЯХ. Если концептуально это карта, то прекрасно — имя ее рожденияToTotal имело бы смысл (хотя я предпочитаю называть ее «итоги», потому что totals[дата рождения] выглядит лучше, чем дату рожденияToTotal[дата рождения]) — но если ее не нужно указывать, не указывайте его. Вы оставляете себе гибкость позже.

Это то, что вы перерастете со временем. Не сказать, что я не знаю 20-летнего программиста, все еще использующего венгерский, но он кодирует на языке со статической типизацией, так что это почти понятно.

Учти это. Эта переменная, которую вы называете, может быть HashMap, так какой тип вы добавляете к имени? Карта? Это промежуточный ответ. Почему не Коллекция? Таким образом, если вы решите изменить СПОСОБ хранения данных, вам не нужно менять имя переменной. Почему бы не HashMap, если вы действительно хотите, чтобы читатель знал, что происходит.

Как вы можете подозревать, ни один из них не является необходимым. Смысл динамического языка (и даже полиморфизма) в том, что вам не нужно знать точный тип представляемой переменной, важны только сами данные. Хотя вам может понадобиться подсказка о том, как взаимодействовать с этими данными, вскоре вы обнаружите, что в большинстве случаев уже знаете или можете легко поместить эту информацию в переменную без указания типов: addressByZipCode, totalByBirthdate и т. д.