Здравствуйте, V.Petrovski, Вы писали:

GZ>>Если да, то только вследствии костности мышления.
VP>нет, это похоже ты ни как неможешь поверь в то, что так как ты ставишь скобки никто не ставит
Ставит. В частности в реализации STL, идущей вместе с VS .NET.

GZ>>Никаких объективных причин ставить фигурные скобки так, как предлагает статья я не вижу.
VP>А я в твоем примере вообще не вижу причины ставить скобки
Пример надуман. И служит лишь для демонстрации вопроса.

VP>P.S.
VP>Можешь ставить скобки так как тебе хочеться, если ты работаешь один, а если ты работаешь в команде, то тебя думаю будут бить.

Для работы в команде единый стиль программирования не роскошь, а прямая необходимость.
Никто с этой истиной спорить не собирается.
Мой вопрос был вызван лишь непонимание факта занесения примера форматирования в раздел "не верно".

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

GZ>Для работы в команде единый стиль программирования не роскошь, а прямая необходимость.
GZ>Никто с этой истиной спорить не собирается.
GZ>Мой вопрос был вызван лишь непонимание факта занесения примера форматирования в раздел "не верно".
Занчит вся команда RSDN решила, что такой вариант растановки скобок не верен.

Здравствуйте, V.Petrovski, Вы писали:

VP>Занчит вся команда RSDN решила, что такой вариант растановки скобок не верен.
Вопрос был:
Почему такой стиль оформления фигурными скобками считается не верным.

Здравствуйте, V.Petrovski, Вы писали:

VP>А я в твоем примере вообще не вижу причины ставить скобки
Интересно, что ребята из Редмонда в посленее время ставят скобки даже в таких случаях.

Посмотрите на ATL из беты новой студии. Возможно, кто-то из начальства обнаружил, что
проще всегда ставить скобки, чем тратить недели на отлов ошибок, связанных с тем что
функцию заменили на макрос, да еще на криво написанный. Для библиотек вроде ATL, которая
используется практически повсеместно в C++ проектах под Win32 это очень актуально.

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

GZ>Вопрос был:
GZ>Почему такой стиль оформления фигурными скобками считается не верным.

Ответ был:
Потому что трудночитаем. Глазу легче сканировать вниз до первого непустого знака (и это будет '}') чем искать именно '}'

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

GZ>Почему такой стиль оформления фигурными скобками считается не верным.
GZ>Было бы очень интересно узнать.
По правилам. Не нравятся такие — можешь внедрить другие правила (у себя в команде).

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

GZ>>Почему такой стиль оформления фигурными скобками считается не верным.
GZ>>Было бы очень интересно узнать.
S>По правилам. Не нравятся такие — можешь внедрить другие правила (у себя в команде).

ok.
На мой взгляд оба способа расстановки фигурных скобок абсолютно равнозначны и имеют
право на существование. Я уважаю чужое мнение и работая в команде безоговорочно одобрил
бы принятые в ней правила оформления исходного кода.
Задавая вопрос, я неосмотрительно полагал, что автор(ы) отметали другие стили оформления
не просто потому, что они им не нравятся, или несколько непривычны.
Жаль что это не так...

В целом статья же достаточно удачна и информативна, даже для программиста на С++,
коим ваш покорный слуга и является.

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


GZ>

GZ>if (condition)
GZ>    {
GZ>    DoSomething();
GZ>    }
GZ>

GZ>Почему такой стиль оформления фигурными скобками считается не верным.
GZ>Было бы очень интересно узнать.

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

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

GZ>Ставит. В частности в реализации STL, идущей вместе с VS .NET.

Кстати, замечательный пример почти не читаемого кода.

GZ>Мой вопрос был вызван лишь непонимание факта занесения примера форматирования в раздел "не верно".

А завтра прийдет орел который спросит почему такой стиль не верен:

if (xxx) {
aaa();
}

а послезавтра такой:

if (xxx)
{
aaa(); }

не разрешать же их все. Был выбран единый, которым пользуется большинство.

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

GZ>На мой взгляд оба способа расстановки фигурных скобок абсолютно равнозначны и имеют
GZ>право на существование. Я уважаю чужое мнение и работая в команде безоговорочно одобрил
GZ>бы принятые в ней правила оформления исходного кода.
GZ>Задавая вопрос, я неосмотрительно полагал, что автор(ы) отметали другие стили оформления
GZ>не просто потому, что они им не нравятся, или несколько непривычны.
GZ>Жаль что это не так...

Авторы отметали другие стили, чтобы их небыло в одном коде. Читать код в котором меняется стиль форматирования крайне сложно. Нужно было выбрать один из пары десятков вариантво. Выбрали этот. Почему? На этот вопрос тебе уже ответели не раз.

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

VD>Потому что нужно было выбрать один. И так как предложенный тобой почти для всей команды был экзотикой, то останавились на том что в документе. К тому же это соотвествует правилам принятым в МСДН для шарпа.

Наконец-то достойный ответ. Спасибо.

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

VD>Авторы отметали другие стили, чтобы их небыло в одном коде. Читать код в котором меняется стиль форматирования крайне сложно.
Абсолютно согласен.

VD>Нужно было выбрать один из пары десятков вариантво. Выбрали этот. Почему? На этот вопрос тебе уже ответели не раз.
Заметьте, я не предлагал использовать при форматировании все отвергнутые вами _десятки_вариантов_.
Всего лишь интересовался причиной негативного отношения к конкретному варианту расстановки фигурных скобок.
Спасибо, Ваш ответ я понял.

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

VD>Здравствуйте, GregZ, Вы писали:


VD> К тому же это соотвествует правилам принятым в МСДН для шарпа.

не правила, а рекомендации... просьба не путать.

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

GZ>Всего лишь интересовался причиной негативного отношения к конкретному варианту расстановки фигурных скобок.

Нет никакого негативного отношения. Просто все что не соотвествует стилю выбранному большинством считается неправильным, просто потому что введена монополия на описание.

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

VD>> К тому же это соотвествует правилам принятым в МСДН для шарпа.

A>не правила, а рекомендации... просьба не путать.

Пусть так. Но мы создавали правла и приняли такой стиль.

У меня есть вопрос по именованию непубличных полей.


>Непубличные поля (private, protected и protected internal) именуются в стиле Кэмел и начинаются с префикса _.

В то же самое время сам Microsoft запрещает использование этго префикса. Это, конечно, относится для тех, кто пишет Class Library, но кто знает во что выльется каждая библиотека, разработанная в рамках проектов RSDN.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconfieldusageguidelines.asp

>Do not apply a prefix to field names or static field names. Specifically, do not apply a prefix to a field name to >distinguish between static and nonstatic fields. For example, applying a g_ or s_ prefix is incorrect.

вместо этого майкрософт использует суффикс Value.

Я лично, за префикс '_' для private член-данных, но майкрософт рекомендует иначе.

P.S. Может быть я что-то не допонял...

BT>В то же самое время сам Microsoft запрещает использование этго префикса. Это, конечно, относится для тех, кто пишет Class Library, но кто знает во что выльется каждая библиотека, разработанная в рамках проектов RSDN.

"Соглашения по оформлению кода команды RSDN" — где ты здесь микрософт увидел?
Микрософт дает ничего не запрещает и не разрешает. Он дает рекомендации. А твое право этими рекомендациями пользоватся или нет. В большинстве случаев соглашение РСДН совпадает с рекомендациями Микрософт. Но вот в случае с приватными переменными несовпало

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

A>Микрософт дает ничего не запрещает и не разрешает. Он дает рекомендации. А твое право этими рекомендациями пользоватся или нет. В большинстве случаев соглашение РСДН совпадает с рекомендациями Микрософт. Но вот в случае с приватными переменными несовпало

А разве в Class Developers Guide указывается стиль именования приватных переменных? Где то в другом месте я видел рекомендацию не использовать префиксы, но никоим образом не запрет.

AVK>А разве в Class Developers Guide указывается стиль именования приватных переменных?
Да я ошибся. Там только есть рекомендации про регистр.

AVK>Где то в другом месте я видел рекомендацию не использовать префиксы, но никоим образом не запрет.
Я наверное тоже спутал с этим "другим местом". Про запреты это не ко мне. Я наоборот хотел подчеркнуть что все имеет рекомендательный характер.

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

BT>В то же самое время сам Microsoft запрещает использование этго префикса. Это, конечно, относится для тех, кто пишет Class Library, но кто знает во что выльется каждая библиотека, разработанная в рамках проектов RSDN.

BT>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconfieldusageguidelines.asp

Погоди пол гда-годик и МС выдвенет новые рекомендации которые будут в точности обратными этим. Это же вкусы. Кто дорвался тот и навазяывает.

Какая разница пользователю библиотеки как в ней названы приватные поля? Типа декомпилированный код плохо выглядит?