2008-11-20 5 views
6

Как начинающий программист, я пытаюсь установить для себя стандартное соглашение об именах. Я понимаю, что это личное предпочтение, но я пытался получить некоторые идеи от некоторых из вас (ну много из вас), которые намного умнее меня.Какие соглашения об именах вы используете в C#?

Я не говорю о нотации верблюда, а как вы называете свои переменные и т. Д. IMHO, var_Quantity гораздо более описателен, чем Q или varQ. Однако как вы держите переменную слишком длинной. Я попытался описать свои элементы управления более описательными, но в итоге у меня получилось такое, что «rtxtboxAddrLine1» для RadTextBox, который содержит адресную строку 1. Слишком я, это неуправляемо, хотя довольно ясно, что это за контроль.

Мне просто интересно, если у вас есть какие-то руководства, за которыми вы следуете, или я остался на своих устройствах?

ответ

1

Чем более наглядным, тем лучше, вы обнаружите, что длина не так важна, как помнить, что этот элемент управления/переменная выполнял через пять лет в будущем.

1

Для проектирования .NET API (и некоторые рекомендации общего C#) проверить Кшиштоф Квалина и Брэда Абрамса Framework Design Guidelines

С уважением, Тамберг

2

Я рекомендовал бы использовать собственные директивы Microsoft в качестве отправной точки , Как правило, большинство компаний начинают там (по моему опыту, в любом случае).

http://msdn.microsoft.com/en-us/library/czefa0ke(VS.71).aspx

5

В этом случае, я думаю, вы бы лучше назвать его как primaryAddressLine или firstAddressLine. Вот почему - rtxt как префикс бесполезно сообщает вам тип. Intellisense поможет вам с типом и невосприимчив к изменениям, внесенным в фактический тип объекта. Вызов его firstAddressLine удерживает его от (плохого) соглашения с использованием 1, 2, 3 ... в конце имен переменных, чтобы указать, что по какой-то причине вам понадобилось больше из них вместо коллекции.

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

1

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

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

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

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

1

Мне нравится этот документ:

C# Coding Standars for .NET (ZIP)

Это хороший сборник лучших практик и кодирования руководящих принципов стиля.

5

Guidelines for Names - лучшая отправная точка. Но, как и в других областях жизни, как только вы знаете правила, вы начинаете понимать, где разумно их разорвать.

Я никогда не использую старые венгерские обозначения, которые называет вещи strFirstName, intCount и т.п .; но я до сих пор использовать его на контроль: txtFirstName, btnVerifyData и т.д. Причины включают в себя:

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

Кроме того, я вполне вероятно, сделать то же самое для многих из TextBoxes или ComboBoxes на странице или в форме, в то время как я, вероятно, сделать что-то для всех целых чисел или строк, не упомянутых в страницу или форму. Таким образом, это помогает быстро найти все текстовые поля с префиксом txt.

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

+0

Благодарим за это. Я распечатал его! – GregD 2008-11-20 22:28:31

 Смежные вопросы

  • Нет связанных вопросов^_^