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

Часть Git должна работать при условии, что удаленный «источник» правильно установлен в /home/aero/server, чтобы репо работало правильно (как в « Git post-receive не работает правильно »). .

Часть npm start может быть проблемой, если эта команда блокируется.
В этом случае (имеется в виду выполнение в Git-хуке), вы можете рассмотреть использование pm2 для запуска приложения, как описано в « Дружественное руководство по автоматизации развертывания для Приложения Node.js с Git Hooks "от aunnnn .

pm2 start npm --name 'my-app' — start \
&& echo "post-receive: app started successfully with pm2".

10
задан Damien Black 13 February 2014 в 22:33
поделиться

6 ответов

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

13
ответ дан 3 December 2019 в 15:22
поделиться

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

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

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

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

7
ответ дан 3 December 2019 в 15:22
поделиться

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

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

  1. Используйте хорошее переменное именование. Например, если у Вас есть карта дат к ints, можно назвать его чем-то как BirthdateToTotalLookup.
  2. Учитесь что визуальные подсказки искать. Это может казаться очевидным, но это взяло меня некоторое время, чтобы привыкнуть искать подсказки как это:

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

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

3
ответ дан 3 December 2019 в 15:22
поделиться

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

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

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

2
ответ дан 3 December 2019 в 15:22
поделиться

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

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

2
ответ дан 3 December 2019 в 15:22
поделиться

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

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

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

2
ответ дан 3 December 2019 в 15:22
поделиться
Другие вопросы по тегам:

Похожие вопросы: