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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

Честно говоря, я не уверен, какое доброе имя будет для списка карт.

Ответ 5

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

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

Ответ 6

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

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

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