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

Question

Я попадаю на язык Groovy, который имеет динамическую типизацию (а также необязательную статическую типизацию). Он также имеет встроенную поддержку списков, карт и диапазонов, поэтому я часто использую списки и карты, особенно списки списков, списки карт, карты списков и т. Д.

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

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

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

Любые советы?

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

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

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