Какие соглашения об именах вы используете при кодировании?

Question

Какие соглашения об именах вы используете при кодировании?

Answer 1

Я надеюсь, что здесь мы не будем обсуждать префиксы для имен полей и стилей фигурных скобок:)

Вот моя библия для .NET:

Также MSDN дает твердые рекомендации.

Другим полезным источником является Руководство по внутреннему кодированию MS

Answer 2

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

• Методы верхнего регистра (DoThis)
• переменные в верблюжьем регистре (thisThing)
• переменным уровня страницы предшествует _ (_thisWorksEverywhere)
• все регионы в нижнем регистре (#region чужие свойства)
• Свойства и объекты в верхнем регистре (Object.Property)
• Иностранным свойствам предшествует _ (Object._ForeignGroups)
• Элементы управления в некоторой степени венгерские, такие как (txtTextBox) и (rptRepeater). Я не слишком строг в отношении того, что обычно, потому что "Водяной знак" может быть wm или wk или чем-то еще, если они все соответствуют друг другу в моем приложении.

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

Answer 3

Вот список общих соглашений о присвоении имен из MSDN.

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

Неважно, какие стандарты используются, imo - просто есть некоторые, и люди знают, что они собой представляют.

Answer 4

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

Например, я использую префикс в венгерском стиле для имен элементов управления, таких как txt для TextBoxes, btn для кнопок, pic для PictureBoxes, lbl для меток и т. Д. Это помогает легко определить, что такое элемент управления.

Для имен функций я стараюсь использовать разумные пояснительные имена, но ничего с какими-то конкретными правилами. Для имен переменных я просто использую пояснительные имена, но ничего особенного.

Answer 5

В дополнение к ответу @Aku, авторы Руководства по проектированию рамок опубликовали в Интернете дайджест-версию своих руководств с акцентом на условные обозначения.

Руководство по проектированию фреймворка, сборник v2

Скачать здесь

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

Answer 6

Выберите один, чтобы быть последовательным. Изменение стиля имени приводит к путанице.

Answer 7

Люди, пожалуйста, не публикуйте ответы типа "Мне нравится __field" или "Мне нравится m__field" Это очень личный и субъективный вопрос без единого ответа.

Если у вас есть какие-либо указания , это уже большая победа. Хуже всего в команде разработчиков является отсутствие общих соглашений.

Было бы неплохо, если бы попытался описать некоторые преимущества данного руководства.
Например:

префикс полей с символом подчеркивания улучшить автозаполнение с IntelliSense