Здравствуйте, RSDN Team, Вы писали.

Раз уж документ объявляется правилом, то не появляется ли желания перенумеровать описанные там утверждения? А то для использования в реальных разработках приходиться создавать копию документа, нумеровать все и выкладывать у себя вместо того, чтобы дать ссылку на [http://www.rsdn.ru/article/?511

Автор(ы): RSDN Team
Дата: 27.02.2003

].

Да и на форуме удобнее будет — написал новичек опрос с кодом, а ему бац: Вы нарушили пункт 14.6.1.12 Соглашений по оформлению кода — бан на месяц по IP.

Здравствуйте, RSDN Team, Вы писали:

А>Статья:

Спасибо за "соглашения" — отличная основа для правил по оформлению кода.
Я полностью, согласен с Frostbitten в том, что нужно пронумеровать все утверждения

Автор: Frostbitten
Дата: 10.11.04

. Когда я этим занимался, заметил несколько неточностей структурирования. Все, что написано в параграфе "Именование идентификаторов — Пространства имен — Импорт пространств имен" относится, скорее, к оформлению кода ("Стиль кода"), чем к именованию идентификаторов. То же касается параграфа "Именование идентификаторов — Типы" и некоторых других (например, "Одна декларация должна содержать не более одного поля и должна располагаться на одной строке." — в "Именование переменных — Поля").
Напротив, часть того, что написано в "Стиль кода — Локальные переменные" относится как раз к именованию ("Используйте стиль Кэмел для регистра букв в именах переменных.", "Счетчики в циклах традиционно называют i, j, k, l, m, n." и др.).

Также, хотелось бы иметь параграф про оформление атрибутов.

[Visible]
publiс string Name;

или 

[ Visible ]
publiс string Name;

//////////////////////

[Visible]
[Nullable]
publiс string Name;

или 

[
Visible, 
Nullable
]
publiс string Name;

или

[Visible, Nullable]
publiс string Name;

И про регионы. Не знаю, правда, используются ли регионы в проектах РСДН.
Прбовал разбивать код на регионы по семантическим признакам, но это оказалось не сильно полезным — в каждом классе свои собственные регионы, большое разнообразие регионов. Сейчас пробуем такой вариант:

1. Элементы типа могут быть разбиты на регионы. Разбинеие производится по формальным признакам. Отдельный регион для полей, отдельный — для свойств, отдельный — для методов и т.д.. Вложенные типы находятся в отдельном регионе, реализации интерфейсов — в собственных регионах.
2. Старайтесь не использовать вложенные регионы.
3. Список основных регионов:
•Inner types. Регион для вложенных типов.
•Fields. Регион для полей.
•Properties. Регион для свойств.
•Indexers. Регион для индексаторов.
•Constructors. Регион для конструкторов.
•Methods. Регион для методов.
•Events. Регион для событий.
•Interface members. Регион для реализации интерфейса.

Пример:

public class MyClass
{
#region Inner types
#endregion Inner types

#region Fields
#endregion Fields

#region Methods
#endregion Methods

#region ISerializable members
#endregion ISerializable members

    ...
}

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

Пример:

public class MyClass
{
#region Static Properties
#endregion Static Properties

#region Instance Properties
#endregion Instance Properties

#region Public methods
#endregion Public methods

#region Protected methods
#endregion Protected methods

    ...
}

Будет ли вторая версия правил? Могу поучаствовать.

Здравствуйте, Аноним, Вы писали:


MS Code Style internal guidelines

Здравствуйте, RSDN Team, Вы писали:

RT>Соглашения по оформлению кода команды RSDN

Автор(ы): RSDN Team
Дата: 27.02.2003

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

Вот тут положил файл настроек для MSVS 2005, удовлетворяющий (если я нигде не наврал) соглашениям.

Вопрос: верно ли я понимаю, что сдедующие куски кода оформлены в соответствии с соглашениями? Если нет, то почему?

foreach(object o in items) // внутри for-а один if-else
  if(condition) // со "сложным" if-ом "простой" else
  {
    int a = 0;
    a++;
    a++;
    a++;
    a++;
    a++;
  }
  else
    bla-bla-bla;

Здравствуйте, RSDN Team, Вы писали:

Здравствуйте, объясните пожалуйста что такое lightweight поля, что под этим имеется ввиду в данной статье?