System.out.println(i++); // "6"
Это отправляет println
значение, которое я имел до этой строки кода (6), а затем увеличивает I (до 7).
Сохраняйте семантичность. Используйте полные, простые (желательно английские) слова. Не пытайтесь придумывать что-то модное или техническое и не описывайте, что это - мы это знаем. Опишите, что он делает . Описание цели добавляет информационную ценность.
Ничего не сокращайте! BW_RCB01_SW
кое-что значил для команды, которая много лет назад занималась нашим CSS, но сейчас это ничего не значит для меня, и мне приходится работать в обратном направлении, чтобы попытаться перевести то, что BW_RCB01_SW
соответствует для моих целей, и либо запомните этот перевод, либо запишите его где-нибудь. Лучше? blackwhite-boxtype1-bottomleft
. Он длиннее, но также не требует розеттского камня.
Используйте строчные буквы и символы подчеркивания или дефисы. Я предпочитаю дефисы, но это мое предпочтение. Не должно быть препятствий для использования дефисов, поскольку они не зарезервированы в CSS или HTML, а идентификаторы обрабатываются как буквальные строки на всех других языках. Строчные буквы - это весь опыт - слишком много часов потрачено на размышления, какого черта этот стиль не применим. pageContainerLeft
не то же самое, что pageContainerleft
.
Определите точно , что это за элемент, но не более того. Серьезно подумайте о каждой части информации, которую вы вкладываете в имя, и о том, необходимо ли это. В вашем примере - вам нужно, чтобы знал, что это флажок рядом с идентификатором? Вряд ли. Вы уже знаете, о каком элементе говорите, потому что это ' sa уникальный идентификатор, и вы все равно должны кодировать этот элемент.
Называя как можно меньше объектов, определенно помогает поддерживать чистоту. Если вы можете обойтись, назвав родителя и просто сославшись на ребенка, это будет лучше (на мой взгляд). Вы получаете бонус в виде немного меньшего количества HTML, отображаемого клиенту на каждой странице.
Тем не менее, когда мне все же нужно называть элементы, я предпочитаю все строчные буквы с обозначением подчеркивания. Я был обманут тем, что раньше не понимал мой случай в файлах CSS, так что если я могу посчитать это проблемой на ранней стадии, это как облегчение.
Подчеркивание - это символы, а тире можно интерпретировать как минус, так что это один более потенциальная проблема - имеет смысл использовать только символы подчеркивания. Flex, например, не принимает XML с атрибутами, названными тире (я знаю, что это значения, а не атрибуты; но все же безопасный вариант).
Я согласен с вышеизложенным - никаких типов элементов, позиционирования или цвета как класса / идентификатора. Венгерская нотация == плохо. Очень полезно определить, что такое ID. Мне нравится называть поля формы специфическими для объекта способами - user_login, user_email, user_address_state_id, user_address_country_id
и т. Д. Могут все отображаться в форме регистрации пользователя. Обычно поля, не являющиеся формами, не имеют достаточной длины для подчеркивания, иначе вы можете переименовать их.
Хотите верьте, хотите нет, но у меня были проблемы с дефисами в качестве имен идентификаторов и имен классов CSS при использовании определенных библиотек javascript. Это очень редко, но вы, очевидно, хотите избежать подобного. Из-за этого я использую верблюжий регистр или подчеркивания. Вы также можете использовать символы подчеркивания.
В противном случае общее правило - иметь значимые имена, которые легко читаются и понимаются. Когда дело доходит до «элементов управления», убедитесь, что вы соблюдаете какое-то соглашение об именах. Лично я предпочитаю постфиксы префиксам (т.е. nameText вместо textName), но я стараюсь избегать постфиксов, поскольку считаю их слишком многословными.
Итак: 1. Значимые имена. 2. Избегайте пост- / префикса. 3. Избегайте сокращений (например, адрес вместо адреса). 4. Не торопитесь.
Вот несколько рекомендаций по именованию, которые помогли мне с моими идентификаторами и классами в DOM:
Один из гуру HTML на моей последней работе рекомендовал разделять идентификаторы из нескольких слов тире
<input type="text" id="user-name" />
Я не могу вспомнить, почему - у меня нет доступа к этим документам внутренних стандартов больше. Я знаю, что это действительно не отвечает на ваш вопрос о Pascal vs Camel casing.
Я лично не советовал бы использовать HN - я считаю, что это в значительной степени отвратительная практика. Что произойдет, если вам нужно вместо этого изменить массив флажков на элемент select? Теперь в ID элемента заложена ложная семантика. Просто это не стоит хлопот, ИМО.