Аннотация:
Этот документ описывает единый стиль кода, разработанный командой RSDN. В первую очередь он предназначен для использования в проектах, ведущихся в рамках RSDN. Надеемся, что этот стиль будет полезен всем тем, кто так же ищет удобный единый стиль форматирования исходного кода.
Раз уж документ объявляется правилом, то не появляется ли желания перенумеровать описанные там утверждения? А то для использования в реальных разработках приходиться создавать копию документа, нумеровать все и выкладывать у себя вместо того, чтобы дать ссылку на [http://www.rsdn.ru/article/?511
Да и на форуме удобнее будет — написал новичек опрос с кодом, а ему бац: Вы нарушили пункт 14.6.1.12 Соглашений по оформлению кода — бан на месяц по IP.
Здравствуйте, Воронков Василий, Вы писали:
O>>Offtopic: Знаешь, почему ошибки в комменатриях у MS обозначаются BUGBUG: а не просто BUG? ВВ>Почему?
Потому что поиск по слову BUG (и даже BUG:) срабатывает на DEBUG и на (DEBUG:).
А>Авторы: А>RSDN Team
А>Аннотация: А>Этот документ описывает единый стиль кода, разработанный командой RSDN. В первую очередь он предназначен для использования в проектах, ведущихся в рамках RSDN. Надеемся, что этот стиль будет полезен всем тем, кто так же ищет удобный единый стиль форматирования исходного кода.
меня почему-то коребит от того что такие вещи как if и for и т.п. вещи в основном народе пытаеться зщаписывать в таком виде:
if ( some expression )
for ( .... )
foreach ( )
и знаете что корёбит? пробел между скобкой и ключивым словом!
подумайте ведь записать if без скобки не возможно — ошибка компилятора! записать for без скобки — ошибка компилятора... и т.д. так какого разделять ключевое слово и скобку? они не могут жить отдельно!
и не надо говорить что так мол удобней печатать, это все дело привычки, а вот логическую компоновку это нарушает.
пример хорошого для меня кода:
if( const == something )
{
for( int i=0; i < 10; i++ )
{
/// и т.д.
}
}
ключевые слова не отделяються от скобок пробелами...
Здравствуйте, Аноним, Вы писали:
А>> Не используйте подчеркивание для отделения слов внутри идентификаторов, это удлиняет идентификаторы и затрудняет чтение.
А>1). Сравните: "VeryLongNameOfSomeVariable" и "very_long_name_of_some_variable". IMHO второе намного читабельнее. Всё-таки в русском языке мы разделяем слова пробелами, а не изменением регистра букв. А>2). Сравните: "TcpUdpIcmpAndIpClassName" и "TCP_UDP_ICMP_and_IP_class_name". Во втором случае аббревиатуры остались в привычном для глаза виде и при чтении лучше распознаются.
Такие длинные (многосоставные) названия... это мне кажеться в дизайне что-то не додумано. Или язык какой-нить процедурный. А так вроде бы и мотива нет. Что-то похоже на "Меня зовут КлиновыйЛистУпавшийНаЗакатеВСерединеОсени", что-то индейское чес слово.
Здравствуйте, alku, Вы писали:
A>пример хорошого для меня кода:
И не хорошего для меня...
A>
A>if( const == something )
A>
A>ключевые слова не отделяються от скобок пробелами... A>жду коментов...
В данном случае по моему мнению страдает читабельность. Я привык ключевым словом читать if, а не if(, поэтому когда я читаю код, глаз выхватывает ключевые слова и мозг строит из них структуру. Скобки в данном случае лишь сущность группировки, выделение условия как единого целого.
Аналогично в русском языке (это я привёл пример, как по-моему), пробел ставится перед скобкой, а не после( как в твоём примере ). Ну, и как удобнее читать?
Странный спор вы тут затеяли, господа. Мне казалось, что уже все давным давно должны понимать, что спорить о предпочтениях просто глупо. Кроме того, давно пора бы понять, что соглашения нужны не для того, кто пишет код, а для того, кто над ним будет работать позже.
Поэтому, нравятся пробелы после ифов, не нравятся, а ставить надо, потому что так положено.
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Соглашения по оформлению кода команды RSDN
Здравствуйте, alku, Вы писали:
A>и что голосование покажет? то что половина девелоперов предпочитает один стиль от другого?! A>тут мотивации сравнить надо, а не на глаз приятно или нет.
Мотивация тут ровно одна: правила кодирования должны быть. Неудобные правила — лучше, чем вообще никаких. Все. А есть там пробелы или нет — просто о малое по сравнению с разнобоем в стилистике. Я писал код в стилеКэмел, Паскаль, szВенгерка, m_МФЦвенгерка, и даже где_слова_отделяются_подчеркиванием и все с маленькой буквы... Переучивание приходит на второй день работы. Максимум на третий. Поэтому, когда ты соберешся внедрять стиль у себя — не думай слишком долго. Бери любой.
Единственная оговорка — если у вас 90% кода написано в каком-то одном стиле, то переходить на другой не стоит. Даже если это — __тот_самый_стиль.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alku, Вы писали:
A>ключевые слова не отделяються от скобок пробелами...
A>жду коментов...
Ну основная причина была сделать операторы непохожими на методы. Твой же вариант просто не очень хорошо смотрится из-за пробелов внутри скобок (не соответствует оформлению обычного текста и режет глаз).
Да можно и не спрашивать, они уже ответили практически. Есть такая замечательная утилита FxCop, которая проверяет сборки на соответствие различным правилам, в том числе и стандарту кодирования. Так вот, народ начал активно интересоваться, почему же эта утилита активно ругается на собственные сборки Microsoft. И здесь можно почитать ответ, почему же в коде фреймворка встечаются различные анахронизмы вроде m_ и прочего
Кстати, ссылку не приведу, но на прошлой недел читал блог какого то перца из Microsoft, который говорил что в данный момент код у них ежедневно прогоняется FxCop для контроля, потом ложится отчет и разработчики могут использовать его для фонового рефакторинга.
A> internal bool CompareStyles( StyleImpl source, StyleImpl destination )
A> {
A> return ( ( source.FillBackground == destination.FillBackground ) &&
A> ( source.FillForeground == destination.FillForeground ) &&
A> ( source.FillPatern == destination.FillPatern ) &&
A> }
A>
А я обычно && || и т.д. переношу на следующую строку. Поскольку сами выражения семантически в голове держатся, а вот условия которыми они объединены удобнее видеть перед глазами. И что важно если несколько && разделены || то можно выхватить отдельный сегмент условия.
. Когда я этим занимался, заметил несколько неточностей структурирования. Все, что написано в параграфе "Именование идентификаторов — Пространства имен — Импорт пространств имен" относится, скорее, к оформлению кода ("Стиль кода"), чем к именованию идентификаторов. То же касается параграфа "Именование идентификаторов — Типы" и некоторых других (например, "Одна декларация должна содержать не более одного поля и должна располагаться на одной строке." — в "Именование переменных — Поля").
Напротив, часть того, что написано в "Стиль кода — Локальные переменные" относится как раз к именованию ("Используйте стиль Кэмел для регистра букв в именах переменных.", "Счетчики в циклах традиционно называют i, j, k, l, m, n." и др.).
Также, хотелось бы иметь параграф про оформление атрибутов.
И про регионы. Не знаю, правда, используются ли регионы в проектах РСДН.
Прбовал разбивать код на регионы по семантическим признакам, но это оказалось не сильно полезным — в каждом классе свои собственные регионы, большое разнообразие регионов. Сейчас пробуем такой вариант:
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
...
}
Будет ли вторая версия правил? Могу поучаствовать.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alku, Вы писали:
A>>повторюсь: A>>- для этих целей очень подходит расцветка... и сразу становиться видно где метод, а где ключевое слово... исключение составлеяет просмотр исходников редактором не приспособленным для работы с ними... аля notepad
AVK>Вот ты сам все и объяснил.
но это же смешно... кто щас в здравом уме смотрит исходники notepad??? хотя бы Far + colorer...
так что думаю это ничего не объясняет, а на оборот усложняет форматирование...
форматирование не должно отягощаять девелопера иначе он на него начнет "забивать".
в первую очередь форматинг кода расчитан на девелопера, а его основной инструмент студия или редактор с колорингом и удобной навигацией...
так что notepad это пережиток прошлого и я бы сказал "дурная наследственость" от которой надо избавляться. но даже если нормально редактора нету под рукой не стоит говорить что пробелы что-то сильно меняют. это просто другой способ групировки и разбития на логические составлющие...
например:
само по себе мне слово if не инетересно, намного интереснее его условие! следовательно должно быть выделено условие, а не ключевое слово... ключевое слово в таком контексте играет второстепенную роль. такое практически работает на все киворды, за редким исключением. (хотя не совсем верно — сначало должна пройти стадия распознования киворда, потом стадия сопостовления в которой человек решает что важного есть в такой языковой конструкции, а потом идет анализ этой важной состовляющей... но при должной практике такой процес проходит практически автоматом и распознование кивордов уходит на второй план...)
думаю нам бы всем не помешала статья на тему как человек воспринимает информацию. это могло бы нам помочь и выработать правила/форматинг облегчающий понимание...
в чем проблема всех стандартов?! на момент написания они морально устаревают и около 30% написаного в них теряет свою актуальность... вот как раз расчитывать на то что код будут смотреть notepad'ом и есть морально устаревшие 30%...
а держаться за прошлое когда этого всего небыло было бы очень печально надо толкать себя вперед... прошу не обижаться сам такой... тяжело раставаться с тем — что хорошо умееш делать.
B>>if( const == something)
B>>{
B>> for( int i=0; i < 10; i++)
B>> {
B>> /// и т.д.
B>> }
B>>}
B>>
VD>Еще как заругается. Ты вообще оказался самым экстовагантным. Ну, два пробела можно объяснить, но один... больше похоже на то что ты опечатался. И уж точно читать такой код неудобно. Глаз не выхватывает зависимостей.
Глаз пробегает по названию инструкции if(, потом пробел "чик", дальше пойдет условие. Или название метода (может даже длинюче)
Console.WriteLine(<чик>"Hello!"). Т.е. даже очень ничего, потом посмотри как операторы визуально обрамляют внутренности:
if( const == something)
{
for( int i=0; i < 10; i++)
{
/// и т.д.
}
}
Вобщем, один пробел после инструкции лишний "чик" делает и мозг немножко рассеивается Но ладно, не смертельно это.
А> Не используйте подчеркивание для отделения слов внутри идентификаторов, это удлиняет идентификаторы и затрудняет чтение.
1). Сравните: "VeryLongNameOfSomeVariable" и "very_long_name_of_some_variable". IMHO второе намного читабельнее. Всё-таки в русском языке мы разделяем слова пробелами, а не изменением регистра букв.
2). Сравните: "TcpUdpIcmpAndIpClassName" и "TCP_UDP_ICMP_and_IP_class_name". Во втором случае аббревиатуры остались в привычном для глаза виде и при чтении лучше распознаются.
А>1). Сравните: "VeryLongNameOfSomeVariable" и "very_long_name_of_some_variable". IMHO второе намного читабельнее. Всё-таки в русском языке мы разделяем слова пробелами, а не изменением регистра букв.
Ты видать на php долгое время писал, вот тебе и читабельнее Да и памяти вторая строка больше займет
А>2). Сравните: "TcpUdpIcmpAndIpClassName" и "TCP_UDP_ICMP_and_IP_class_name". Во втором случае аббревиатуры остались в привычном для глаза виде и при чтении лучше распознаются.
Ну во первых названия совсем уж бредовые как для именования. А во вторых, это Соглашение в основном предназначено для написания под .NET, а там разделение кода с помощью подчеркивания довольно дико смотрится рядом с тем же кодом фреймворка.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, <Аноним>, Вы писали:
VD>То-то я смотрю в ядре Линукса чет ногу сломит. Значит это были происки наших аноноимов.
Без перехода на личности никак?
А>>Ты хотя бы попытайся оторваться от своих привычек и посмотреть на то, как выглядят эти две переменные _непредвзято_.
VD>Шутку понял, смешно. (с)
Здравствуйте, beretta, Вы писали:
B>Так тоже нельзя, пробел после открывающей скобки, Влад заругается Не помню почему, но мне так привычнее, и читать легче.
B>
B>if( const == something)
B>{
B> for( int i=0; i < 10; i++)
B> {
B> /// и т.д.
B> }
B>}
B>
Еще как заругается. Ты вообще оказался самым экстовагантным. Ну, два пробела можно объяснить, но один... больше похоже на то что ты опечатался. И уж точно читать такой код неудобно. Глаз не выхватывает зависимостей.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alku, Вы писали:
IT>>В нормальных командах соглашения предварительно обсуждаются, принимаются, затем долгое время шлифуются и, конечно же, никогда не объявляются догмой. Если какое-либо правило не устраивает большинство, то оно запросто может быть изменено. Что совсем не означает, что соглашения можно менять каждый день.
A>слово нормальный не применимо... потому как на большой фирме приходиться работать с тем что есть в наличии, а не выбирать себе как на ярмарке... по-этому менеджером всегда ставят "авторитет" — а второй скрипкой тот кто его поддерживает или долгое время работал в команде с этим менеджером... тогда практически пробить что-то не реально. (опять в философию потянуло
Ты уж извини, но это как-то больше смахивает на позицию лузера Типа никто меня не любит, никто не уважает.
IT>>А ты не находишь, что топ-программер потому и топ, что у него больше опыта и знаний, в том числе и в способах оформления кода.
A>проблема в том что все правила должны быть обоснованы, иначе они будут оспорены рано или поздно. топ программер очень редко объясняет почему принято такое правило, а не другое. и в статье присутсвует мнение что все что написано есть аксиомы и не должны быть оспорены.
Какое ещё обоснование? Вероятно мы с тобой по разному понимаем значение слова "предпочтение".
A>>>ну и заканчивая спор могу сказать что от стиля записи скобок сильно не поменяеться мнение топ програмера. IT>>Ну если ты так считаешь и для тебя это не важно, то просто пиши так как гласит соглашение. В чём проблема
A>я давно знал что спор на пустом месте. я просто решил предложить свой стиль и посмотреть на сколько он будет вопринят... не оценили, ну и ладно... чего тут шашкой махать то?
Ладно, не переживай. Я твой стиль оценил. Но это далеко не повод менять существующий вариант
IT>>Понимае чего? Понимание расставления скобок? A>ведь скобки — это удобно!
Удобно и мне так нравится — это не обоснование, не находишь?
A>а как тут его отстоиш если аргументы просто супер, например: A>- отстой A>- так 90% кода написано (когда написано, в каком году, на сколько он уже устарел в свете последних технологий и тулзовеней?) A>- мне не нравиться и все...
Ещё раз — речь идёт о предпочтениях, ты вот тоже заявляешь "ведь скобки — это удобно!". Очень аргументировано
A>то что опубликовано на RSDN просто рекомендация людей, который по той или иной причине считают, что то что они делают — правильно и единственно возможный вариант... но это не правда... это простое навязывание своего видинья. обосновонасти правил в статье не хватает.
A>и мой стиль не чуть не хуже и не лучше... он просто расчитан на других людей.
Которым ты навязываешь своё видиние
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Т.е. ты хочешь сказать, что они там все идиоты и не знают о том, что в диалоге поиска ихней же IDE есть галка "Искать целое слово"?
Да нет же, это намёк на то, что исправление одних ошибок привносит в код другие.
Здравствуйте, <Аноним>, Вы писали:
А>Нет. Всё как-то больше на C и для ядра линукса.
То-то я смотрю в ядре Линукса чет ногу сломит. Значит это были происки наших аноноимов.
А>Ты хотя бы попытайся оторваться от своих привычек и посмотреть на то, как выглядят эти две переменные _непредвзято_.
Шутку понял, смешно. (с)
А>Может предложишь что-нибудь взамен? Мне подобные названия регулярно попадаются.
Вот ты и привык жтому бреду. Номальные названия выглядят как-то так:
TcpServerChannel
UdpClient
...
А>Вот и не надо подводить под это какие-то странные обоснования типа "читабельнее". А>Надо было прямо написать "MS за нас всё придумала. Ни шага в сторону.".
И что характено, Sun с IBM-ом тоже на за нас все решили. Так что придется тебе или привыкать, или писать исключительно для Линукс-кернела, чтобы простой народ не пугать.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alku, Вы писали:
A>>проблема в том что все правила должны быть обоснованы, иначе они будут оспорены рано или поздно. топ программер очень редко объясняет почему принято такое правило, а не другое. и в статье присутсвует мнение что все что написано есть аксиомы и не должны быть оспорены.
VD>Самое смешное, что это ты пытаешся впаривать тому самому топ-програмеру.
VD>Пойми, хороший программист может быть не согласен с правилами, но он скажет "ОК, мне не нравятся эти правила, но я буду их придерживаться потому что это нужно чтобы мнее квалифицированные программисты понимали мой не простой код...". А не орать "уйдите ламеры, я буду писать только так как привык".
вот тянет тебя в крайности и хоть стреляйся. диалог к чему свелся? к войне на мясорубках?
я придложил стиль, но не получил нормального обоснования почему он не катит...
ветка как заветься?! — research...
вот и пожалуйста: я вам предложил, а тут сразу вилы в спину — мол нету в этом стиле ничего хорошого...
но тогда прошу прощения какого называть thread research??? ведь это чуш тогда.
нету тут поиска истины, есть только попытки навязать свои мнения (но на морально устойчивых это не пашет.. гы).
перенесите ка лучше ветку в философию тогда так правильней будет.
Здравствуйте, alku, Вы писали:
A>внутри скобок пробел — отделяет условие;
А по-русски ты тоже пишишь( в скобках )?
A> а скобки как елемент групировки выносим на второй план... хотя я могу и усложнять... люди по разному воспринимают написаное.
Ну, скобки в язки программирования понятно откуда пришли. Так что это чистой воды извращения. Загляни в МСДН... погляди как они там скобки ставят...
A>а зачем быть как все?! "серая масса"?!
А затем, чтобы когда читаешь код не переключаться с одного стиля на другой при переходе на новую строку.
A>и откудова цифра 90%???
Из просмотра кода. Погляди на код МС, Сан и т.п. Загляни в МСДН...
A>главное логичность и удобство...
Кому? Тебе лично? Если ты впрягся в большой проект, то будь добр выполнять его требования. Если каждый будут все делать по своему, то будет бардак и каша.
A> мне очень кажеться что пробел просле ключевого слова не удобен... а вот пробел после скобки выделает нужные данные...
Ну, если ты собираешся писать код исключительно для себя. Или если ты можешь навязать свой стиль в своей конторе (и она не продает код другим), то можешь и дальше так писать. А если нет, то очень советую менять привычки.
A>Так или иначе получаеться что топ-программер не осознано навязывает свое мнение другим и по многим причинам: начиная от авторитета и заканчивая админовскими правами — этот человек не осознано диктует условия в которых приходиться работать команде.
И что происходит если в команду приходит еще один квалифицированный человек? Мордобой и измерение членов вместо работы. Вот что.
A> вот тут и получаються конфликты, если человек не достаточно "гибкий" для работы в команде или имеет достаточный авторитет чтобы возвразить и настоять на своем решении, то конфликт не избежен... это так сказать подооплека всего спора про форматинг... но в нем забывают главное: код должен быть оформлен так чтобы команда которая над ним работает его понимала и не тратила силы на "перестановки скобок". главное сдать проект, а не форматировать код!!!
Вот только ни один проект нельзя сделать если в нем нельзя нормально читать код.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, Аноним, Вы писали:
R3>>>Почему? R3>>>
Не используйте специальных префиксов, поясняющих, что это класс. Например, FileStream, а не CFileStream.
А>>Возможно потому, что это версия для C#, а народ в C# приходит в том числе и из C++.
R3>А разве там советовали не использовать это?
Насколько мне известно в C++ эти префиксы в порядке вещей, в C# актуальность в них отпадает. На твой вопрос "Почему? Не используйте специальных префиксов...", вероятно акцент сделан для C++ -ников, пришедших в C#.
Здравствуйте, alku, Вы писали:
AVK>>А вот это очень плохо. Вы как новичкам правила объясняете, на пальцах?
A>хуже у нас очень распространнен екстрим програминг...
Предположу что спецификой вашей конторы является большое число относительно небольших проектов, а не два-три крупных. Исходя из этого становится понятно почему для вас отсутствие общепринятого стиля или частые его изменения не являются смертельными.
A>>> и самое главное что команда их сама выработал за три дня... AVK>>И у нас тоже команда выработала.
A>осталось только на бумагу записать..
А мы записали . Не на бумагу правда, а в VSS.
A>>>Offtopic: очень не порадовало что почти все "решения" очень рекламируешеся для NET от майкрософт оказались не очень состоятельны для большого проекта. где вылизли огромные потребления по памяти, где по перфомансу пролет...
AVK>>Не знаю, у нас все прилично.
A>я же говорил что зависит от того как юзать...
Здравствуйте, V.Petrovski, Вы писали:
VP>А я в твоем примере вообще не вижу причины ставить скобки
Интересно, что ребята из Редмонда в посленее время ставят скобки даже в таких случаях.
Посмотрите на ATL из беты новой студии. Возможно, кто-то из начальства обнаружил, что
проще всегда ставить скобки, чем тратить недели на отлов ошибок, связанных с тем что
функцию заменили на макрос, да еще на криво написанный. Для библиотек вроде ATL, которая
используется практически повсеместно в C++ проектах под Win32 это очень актуально.
Здравствуйте, Andre, Вы писали:
А>>1). Сравните: "VeryLongNameOfSomeVariable" и "very_long_name_of_some_variable". IMHO второе намного читабельнее. Всё-таки в русском языке мы разделяем слова пробелами, а не изменением регистра букв.
A>Ты видать на php долгое время писал, вот тебе и читабельнее
Нет. Всё как-то больше на C и для ядра линукса.
Ты хотя бы попытайся оторваться от своих привычек и посмотреть на то, как выглядят эти две переменные _непредвзято_.
A>Да и памяти вторая строка больше займет
На целых 5 байт. Если это будет читабельнее, то цена оправдана.
А>>2). Сравните: "TcpUdpIcmpAndIpClassName" и "TCP_UDP_ICMP_and_IP_class_name". Во втором случае аббревиатуры остались в привычном для глаза виде и при чтении лучше распознаются.
A>Ну во первых названия совсем уж бредовые как для именования.
Может предложишь что-нибудь взамен? Мне подобные названия регулярно попадаются.
A>А во вторых, это Соглашение в основном предназначено для написания под .NET, а там разделение кода с помощью подчеркивания довольно дико смотрится рядом с тем же кодом фреймворка.
Вот и не надо подводить под это какие-то странные обоснования типа "читабельнее".
Надо было прямо написать "MS за нас всё придумала. Ни шага в сторону.".
Здравствуйте, orangy, Вы писали:
O>Здравствуйте, alku, Вы писали:
A>>пример хорошого для меня кода: O>И не хорошего для меня...
A>>
A>>if( const == something )
A>>
A>>ключевые слова не отделяються от скобок пробелами... A>>жду коментов... O>В данном случае по моему мнению страдает читабельность. Я привык ключевым словом читать if, а не if(, поэтому когда я читаю код, глаз выхватывает ключевые слова и мозг строит из них структуру. Скобки в данном случае лишь сущность группировки, выделение условия как единого целого.
но не отделимая часть... ты при взгляде должен выхватывать не только ключевое слово, но и правильность конструкции языка.
O>Аналогично в русском языке (это я привёл пример, как по-моему), пробел ставится перед скобкой, а не после( как в твоём примере ). Ну, и как удобнее читать?
тут хочу поспорить... зачем равнять искуственный язык програмирования с языком разговорным/письменным?! у них разные цели...
для програмистского языка важные такие вещи, как:
— компактность записи
— удобство навигации по коду
— читабельность
для литературного языка такого нет! почему?! да потому что литературный язык изначально расчитывался на книги без удобств с поиском и навигацией банальное юзабилити компутера — для книг такого нет!
для примера:
— если поставить скобку сразу за ключивым словом, то нажатием Ctrl+] мы получим сразу переход на закрывающюю скобку
— если не ставить, то у нас на одно действие больше! сдвиг на один символ вправо... Arrow Right or Ctrl+ArrowRight
для выделения ключевых слов в коде служит расскраска, а не пробелы! и тут все зависит от того как человек настроил расскраску и на сколько в расскраске выделяються нужные вещи, такие как ключевые слова. человек должен при взгляде на экран сразу выхватывать ключевые слова.
Здравствуйте, alku, Вы писали:
A>>>ключевые слова не отделяються от скобок пробелами... O>>В данном случае по моему мнению страдает читабельность. Я привык ключевым словом читать if, а не if(, поэтому когда я читаю код, глаз выхватывает ключевые слова и мозг строит из них структуру. Скобки в данном случае лишь сущность группировки, выделение условия как единого целого.
A>но не отделимая часть... ты при взгляде должен выхватывать не только ключевое слово, но и правильность конструкции языка.
Правильность конструкции нужна только при написании кода, но читается код на порядки чаще, чем пишется.
O>>Аналогично в русском языке (это я привёл пример, как по-моему), пробел ставится перед скобкой, а не после( как в твоём примере ). Ну, и как удобнее читать?
A>тут хочу поспорить... зачем равнять искуственный язык програмирования с языком разговорным/письменным?! у них разные цели...
Подискутируем Только сразу хочу предупредить, всё это — дело привычки. Это как о тапочках спорить... И весь смысл данных "Соглашений" исключительно для работы в команде, чтобы код был оформлен единообразно.
A>для програмистского языка важные такие вещи, как: A>- компактность записи
Зачем? Купи монитор побольше Шутка, конечно, но в каждой шутке... Я не вижу смысла в компактности записи, это же не Obfuscated C++.
A>- удобство навигации по коду
Верно, но при чём здесь скобки? См. также дальше.
A>- читабельность
Вот это — самое главное, на мой взгляд. И тщательно отделенные лексемы — залог быстрого и легкого чтения.
A>для примера: A>- если поставить скобку сразу за ключивым словом, то нажатием Ctrl+] мы получим сразу переход на закрывающюю скобку A>- если не ставить, то у нас на одно действие больше! сдвиг на один символ вправо... Arrow Right or Ctrl+ArrowRight
Спорно. Во-первых, зачем переходить на закрывающую скобку? Так что-ли не видно, где она? Я еще понимаю, на фигурную скобку, закрывающую блок или метод, но это уже на мой взгляд слишком большой метод, если на экране не помещается, кандидат на разделение.
A>для выделения ключевых слов в коде служит расскраска, а не пробелы! и тут все зависит от того как человек настроил расскраску и на сколько в расскраске выделяються нужные вещи, такие как ключевые слова. человек должен при взгляде на экран сразу выхватывать ключевые слова.
Ну конечно можно из кода сделать помесь радуги и павлиньего хвоста, но надо ли? Если структура даёт гораздо больше информации? ИМХО.
Здравствуйте, orangy, Вы писали:
O>Здравствуйте, alku, Вы писали:
A>>еще одна фича: O>Ну, поскольку нас тут сегодня не много, я снова влезу
A>>кто смотрел код от макрософта рефлектором должен был заметить как именуються мемберы классов!!! они все начинаються с m_... странно это очень... в своем стиле они пишут что так не надо делать и тутже смотрим на код и видим что все там не так... O>На самом деле, в FCL смешаны как минимум 4 подхода к именованию членов класса: O>_member O>m_member O>member O>_Member
O>Может и другие есть. Так что это косяк MS и никакой глубокой идеи в этом нет.
A>>может просто существует два старндарта? один для юзеров другой для внутренних рабочих? O>Существует неряшливость конкретных разработчиков, пишуших код несоответствующий принятому в компании стандарту.
что-то очень сомнительно... у макрософта все достаточно сторого и произвола девелопера они скорее всего не допустят... код у них проходит слишком много стадий, чтобы такую неряшлевость не заметили...
тестирование, код ревью и т.д. и т.п. вещи... так что думаю что стандартов все-таки много или они существуют для каждой группы разработчиков свои.
хочу заметить одну нашу неточность — стандарта на форматирование нету, есть только рекомендации!!! по-этому лучше дальше в диалоге использвать слово рекомендации, а не стандард.
A>но очень возможно что в if будет и больше условий...
Добавил больше условий.
A>я не навязываю свое мнение, я просто прошу вас помочь оценить удобство разных стилей записи... читабельность не теряеться, но это уже возможно дело привычки...
Да и я не навязываю
A>а вот маленький пример где выделеные скобки все-таки полезны:
Переформатируй аналогично примеру выше, и не нужно будет лишних пробелов.
Здравствуйте, alku, Вы писали:
A>но например коментирование первой строки заставить править и вторую строку
Давайте быть критичными к себе В твоем случае такая же проблема с последней строкой.
Здравствуйте, Smarty, Вы писали:
O>>Потому что поиск по слову BUG (и даже BUG:) срабатывает на DEBUG и на (DEBUG:).
S> Кстати — на взять на вооружение!
возьми лучше на вооружение task view из студии — в опциях настраиваються ключивые слова
Здравствуйте, akasoft, Вы писали:
A>Здравствуйте, alku, Вы писали:
O>>>Аналогично в русском языке (это я привёл пример, как по-моему), пробел ставится перед скобкой, а не после( как в твоём примере ). Ну, и как удобнее читать?
A>>тут хочу поспорить... зачем равнять искуственный язык програмирования с языком разговорным/письменным?! у них разные цели...
A>Это для нас, не англоязычных, он "искусственный", а для англоязычных он самый что-ни-на-есть естесственный. Они программы пишут, что говорят. И в этом я им завидую...
переходи на 1с там говорят на русском писать мона...
а вообще мне не понравилось бы если вместо привычных операторов мне пришлось бы писать на русском код... бррр... как подумаю аж в дрожь бросает...
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, alku, Вы писали:
A>>проше отслеживать изминения кода по сорсафе и потом раздавать тумаки за нарушение правил, но такое для больших фирм по моему не будет работать... а для команды до 10 человек очень даже работает... только менеджеру приходиться туго на первых порах. через месяц вся команда уже нормально пашет в установленных правилах и нагрузка на менджера спадает... главное только объяснять каждому почему есть такое правило и что за ним стоит. S>За ним стоит очередь безработных девелоперов которые с удовольствием поисполняют правила. A>>не обоснованных правил девелопер исполнять не будет
Здравствуйте, <Аноним>, Вы писали:
VD>>То-то я смотрю в ядре Линукса чет ногу сломит. Значит это были происки наших аноноимов.
А>Без перехода на личности никак?
Не. Никак скорее без юмора.
А>>>Ты хотя бы попытайся оторваться от своих привычек и посмотреть на то, как выглядят эти две переменные _непредвзято_.
VD>>Шутку понял, смешно. (с)
А>Т.е. даже не попытался.
Т.е. ты сам оторваться не хочешь, но считаешь себя правым.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Соглашения по оформлению кода команды RSDN
Здравствуйте, alku, Вы писали: A>у нас даже за "нормальные" деньги перекупить тяжко... конкуренция
Что ж, буду знать, куда ломиться. У вас рабочую визу получить легко? A>плюс планка знаний для поступления достаточно высокая....
A>ну с москвой равнять не буду... от города и региона сильно зависит зарплата и возможности... в москве для програмера наверно 1000 баксов "очень средняя" (в плане маленькая) зарплата...
Ну, у нас за такие деньги можно очень даже выбирать. Тут куда ни плюнь — попадешь в программера. А заказчиков как-то намного меньше.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alku, Вы писали:
A>кто смотрел код от макрософта рефлектором должен был заметить как именуються мемберы классов!!! они все начинаються с m_...
Это не правда. То есть, в принципе иногда "m_" встречается. Но очено редко. Кстати, там встречаются и "_", и вообще отсутствие префикса. Правад, я подметил, что код без префиксов обычно отличается очень низким качеством.
A>может просто существует два старндарта? один для юзеров другой для внутренних рабочих?
Просто по большому счету плевать как названы скрытые челены классов. Ведь наружу они не выставляются.
A>сам я ксатити по с++ привычке до сих пор все мемберы класса с m_ начинаю... может это все не так плохо как может показаться... венгерскую натаю народ и так сильно не юзал и использовал ее укороченный вариант: A>- для строк m_str* A>- для bool m_b*
Честно говоря я тоже не вижу ничего плохого ни в "m_", ни в любой дургой. Главное чтобы можно было отличить мемберы от локальных переменных. Это важно. Остальное — откровенное фанатство. Я когда принимали эти правила голосовал как раз за "m_Xxx, s_Xxx, g_Xxx", но народ взерепенился... и чудом отбили подчеркиваение для скрытых переменных.
Что же касается префиксов указывающих тип, то они и правда в 90% случаев не нужны. Но к сожалению иногда они могу значительно упростить чтение кода. Именно по этому мы написали "малопонятные префиксы или суффиксы".
A>иногда для int и long... а все остальное очень походе на то что щас предлагает делать Макрософт...
Вот разница между int и long в дотнете почти не важна. КОмпиляторы и сами все прекрасно контролируют, а на логику это не влияет.
A>я пытаюсь написать документ который просто и банально решит такой вопрос — аля корпоративный стандард на оформление кода. в него кстатит должны войти правила по оформлению и безопасности кода... как только напишеться документ обязательно постараюсь поделиться с общественностью.
Ну, тогда проще взять наш. Он проверен на практике...
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, orangy, Вы писали:
O>>>Offtopic: Знаешь, почему ошибки в комменатриях у MS обозначаются BUGBUG: а не просто BUG? ВВ>>Почему? O>Потому что поиск по слову BUG (и даже BUG:) срабатывает на DEBUG и на (DEBUG:). O>
Т.е. ты хочешь сказать, что они там все идиоты и не знают о том, что в диалоге поиска ихней же IDE есть галка "Искать целое слово"?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, orangy, Вы писали:
O>В данном случае по моему мнению страдает читабельность. Я привык ключевым словом читать if, а не if(, поэтому когда я читаю код, глаз выхватывает ключевые слова и мозг строит из них структуру. Скобки в данном случае лишь сущность группировки, выделение условия как единого целого. O>Аналогично в русском языке (это я привёл пример, как по-моему), пробел ставится перед скобкой, а не после( как в твоём примере ). Ну, и как удобнее читать?
Блни, ты привык так, он так. Разницы между вашими привычками никакой. Вопрос в другом доджно быть единообразно. Вот и приняли вариант из статьи. Он ведь во всех исходниках от МС фигурирует.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alku, Вы писали:
A>>и знаете что корёбит? пробел между скобкой и ключивым словом! VD>Т.е. пробелы внутри скобок тебя не коробят? Ну, ты извращенец.
да и горжусь этим
внутри скобок пробел — отделяет условие; а скобки как елемент групировки выносим на второй план... хотя я могу и усложнять... люди по разному воспринимают написаное.
VD>Что же касется пробелов между ключевыми словами и открывющей скобкой, то я тоже раньше их не ставил, и мен кажется это не логичным. Но так пишет 90% программистов. В кодах МС практически нельзя найти код не удовлетворяющий этому правилу. Да и в МСДН тоже.
а зачем быть как все?! "серая масса"?! и откудова цифра 90%???
главное логичность и удобство... мне очень кажеться что пробел просле ключевого слова не удобен... а вот пробел после скобки выделает нужные данные...
философия:
основная проблема что на читабильность кода нету метрик, по которым можно было бы сказать что код читаемый и "удобваримый" или нет... если вывести такую метрику то от нее можно строить правила оформления кода...
на простой язык такие метрики были выведены, а на алгоритмические языки такое сделать забыли/неуспели/забили/и т.п.
но это все теория на самом деле тон команде задает менеджер или главный программер.. (мне Брукс'овское описание команды понравилось и модель ее постороения) следовательно он как главный должен определять стиль и контролировать код. Это я думаю главный фактор!
Так или иначе получаеться что топ-программер не осознано навязывает свое мнение другим и по многим причинам: начиная от авторитета и заканчивая админовскими правами — этот человек не осознано диктует условия в которых приходиться работать команде. вот тут и получаються конфликты, если человек не достаточно "гибкий" для работы в команде или имеет достаточный авторитет чтобы возвразить и настоять на своем решении, то конфликт не избежен... это так сказать подооплека всего спора про форматинг... но в нем забывают главное: код должен быть оформлен так чтобы команда которая над ним работает его понимала и не тратила силы на "перестановки скобок". главное сдать проект, а не форматировать код!!!
ну и заканчивая спор могу сказать что от стиля записи скобок сильно не поменяеться мнение топ програмера.
он как делал код удобным для себя так и будет это делать. следовательно простой человек, ради которого такой стиль пытаються ввести будет подвержен мнению "авторитета" и не сможет донести свое понимание до других, пока сам не станет достаточно авторитетным.
психология — а не програминг. но похожа на правду...
думаю дальше спор про скобки вести безполезно... каждый остался при своем мнении...
Здравствуйте, alku, Вы писали:
A>проблема в том что потеряеш ориентир и будеш воспринимать код как простоя язык... а на код действуют свои мерки и они намного суровее чем на простой разговорный/литературный язык.
Сам придумал? Я вот ни разу не перепутал код и простой язык. А если бы перепутал, то посторался бы изучить этот язык.
И вообще, логика какая-то извращенная. Оформляем код через зад, чтобы отличать его от литиратурных текстов.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, beretta, Вы писали:
B>Console.WriteLine(<чик>"Hello!"). Т.е. даже очень ничего, потом посмотри как операторы визуально обрамляют внутренности:
B>
B>if( const == something)
B>{
B> for( int i=0; i < 10; i++)
B> {
B> /// и т.д.
B> }
B>}
B>
Погано, надо признать, смотрятся.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alku, Вы писали:
A>главное логичность и удобство... мне очень кажеться что пробел просле ключевого слова не удобен... а вот пробел после скобки выделает нужные данные...
Ключевое слово тут — кажется
A>философия: A>основная проблема что на читабильность кода нету метрик, по которым можно было бы сказать что код читаемый и "удобваримый" или нет... если вывести такую метрику то от нее можно строить правила оформления кода...
Точно, поэтому спорить на эту тему просто глупо.
A>но это все теория на самом деле тон команде задает менеджер или главный программер.. (мне Брукс'овское описание команды понравилось и модель ее постороения) следовательно он как главный должен определять стиль и контролировать код. Это я думаю главный фактор!
В нормальных командах соглашения предварительно обсуждаются, принимаются, затем долгое время шлифуются и, конечно же, никогда не объявляются догмой. Если какое-либо правило не устраивает большинство, то оно запросто может быть изменено. Что совсем не означает, что соглашения можно менять каждый день.
A>Так или иначе получаеться что топ-программер не осознано навязывает свое мнение другим и по многим причинам: начиная от авторитета и заканчивая админовскими правами — этот человек не осознано диктует условия в которых приходиться работать команде. вот тут и получаються конфликты, если человек не достаточно "гибкий" для работы в команде или имеет достаточный авторитет чтобы возвразить и настоять на своем решении, то конфликт не избежен... это так сказать подооплека всего спора про форматинг... но в нем забывают главное: код должен быть оформлен так чтобы команда которая над ним работает его понимала и не тратила силы на "перестановки скобок". главное сдать проект, а не форматировать код!!!
А ты не находишь, что топ-программер потому и топ, что у него больше опыта и знаний, в том числе и в способах оформления кода.
A>ну и заканчивая спор могу сказать что от стиля записи скобок сильно не поменяеться мнение топ програмера.
Ну если ты так считаешь и для тебя это не важно, то просто пиши так как гласит соглашение. В чём проблема
A>он как делал код удобным для себя так и будет это делать. следовательно простой человек, ради которого такой стиль пытаються ввести будет подвержен мнению "авторитета" и не сможет донести свое понимание до других, пока сам не станет достаточно авторитетным.
Понимае чего? Понимание расставления скобок?
Ты пойми простую вещь. Стиль расставления скобок — это всего лишь предпочтения. Никакого такого особого понимания в этом нет. Соглашения преследуют одну цель — сделать код проекта однообразным и доступным для понимания другим программерам команды без напряга. Зачем это надо я уже говорил. Затем, что код написанный программистом в команде, этому программисту не пренадлежит. Завтра он может быть переписан, дописан, отдебажен, зарефакторен, выброшен кем угодно другим.
A>психология — а не програминг. но похожа на правду...
A>думаю дальше спор про скобки вести безполезно... каждый остался при своем мнении...
Разница знаешь в чём? Ты не сумел отстоять своё мнение. А знаешь почему? Потому что это вовсе не то мнение, которое имеет смысл отстаивать. Просто пойми, хочешь работать в команде, играй по её правилам. Если не понятно почему, читай басни Крылова.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Тебя трогают вопрсы истотии? Или тебе работать надо?
Э-э-э, Влад!.. Это (про непохожесть операторов на имена процедур) решение придумали до нас. История полезна, иногда экономит время.
A>>А ещё чёрно-белые принтеры и пр. "деревянные игрушки"...
VD>И ты часто печатаешь код? Да и жирным можно выделять...
Иногда. Когда упрусь. Или когда надо быстро изучить что-то новое и сложное. Но очень быстро. С бумаги восприятие другое.
Я? Ни в коем разе. Я никогда ничего не пытаюсь. Я если захотел, то делаю.
A>заказчика на такой код не жалуеться — ему главное чтобы работало и только потом его волнуют вопросы документированости кода, а про стиль он вообще очень редко вспоминает... и то в основном именование enum и некоторых переменных... такой мелочью как простоновка пробелов в скобках или перед скобками волнует почему-то только девелопера.
Код нужен не заказчику. Код нужен твоей же фирме. Его ведь еще читать, а то и менять прийдется.
A>если впрягся в большой проект то будь добр и его сапорт в дальнейшем делай...
Один? В большом проекте и один? Ну, ну...
A> а если писать так чтобы от тебя отстали, то получаеться что в сфере бизнеса и получения стабильной прибыли буде жопа.
А я о чем?
A> очень редко проекты пишуться так чтобы потом кто-то другой лез в него и ковырял.
Что то тебя колбасит. То ты умные вещи говоришь, то ... не очень.
Код пишится исключительно чтобы потом его ковыряли. Иначе его можно было бы уничтожать сразу после получения исполняемых модулей.
A> но даже в таком случае должна сработать этика человека который будет работать и он обязан будет держать стиль кода.
Обычно после орлов не соблюдающих никаких норм код приходится переписывать или, в лучшем случае, рефакторить.
A> Основные деньги приносит сапорт — потому что доход стабилен. а с проектами может быть и пролет и выиграш... но он в основном разовый....
А. Ну, ну... Тогда конечно. Тогда лушче вообще все в столбик писать. А стиль — это вред. Ведь чем хуже выглядит код, тем больше работы для сапорта.
A>следовательно совет про смену стиля не уместен... не надо навязывать своего видинья.
Стиль навязывается коллективом. Все кто не хочет этого понимать и принимать идут работать в городом одиночистве. А точнее идут в лес.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alku, Вы писали:
A>проблема в том что все правила должны быть обоснованы, иначе они будут оспорены рано или поздно. топ программер очень редко объясняет почему принято такое правило, а не другое. и в статье присутсвует мнение что все что написано есть аксиомы и не должны быть оспорены.
Самое смешное, что это ты пытаешся впаривать тому самому топ-програмеру.
Пойми, хороший программист может быть не согласен с правилами, но он скажет "ОК, мне не нравятся эти правила, но я буду их придерживаться потому что это нужно чтобы мнее квалифицированные программисты понимали мой не простой код...". А не орать "уйдите ламеры, я буду писать только так как привык".
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, akasoft, Вы писали:
A>Здравствуйте, alku, Вы писали:
A>>если публикуете то будьте готовы выслушать чужие мнения и оценить их, а не "спускать в унитаз". вы же не принимаете по статье не одного изминения. все сводиться к тому что вы заняли глухую оборону и ни чего не хотите слышать и менять.
A>Это защитная реакция такая. Направленная на поддержание стабильности.
может и да может и нет... кто его разберет стабильность это или застой... а там глядиш и болото.
жизнь — в движении, остоновился значить мертв.
A>Ты сказал своё мнение, тебе ответили. Чего ещё надо? Ты думал переубедить коллектив силой нескольких десятков постов?
по крайней мере я не думал что будет такой негатив на предложение.
A>Но и тебе никто не навязывал, если у тебя есть свой коллектив — ну опубликуй правила своего коллектива.
так их написать сначало надо... думал взять за основу RSDN, а они мне не понравились значиться с нуля прийдеться рожать.
A>А давать оценки разные, по собственному видению — ну так для этого мы тут и пишем. Это и есть обмен мнениями.
хор у вас, а не одиночные тенора... вот только кто дережер то? а впрочем не важно... главное что вы у нас есть (это типо благодарность)
A>И ещё, если тебе пишет красненький IT, — это мнение именно IT, если красненький Влад — это мнение Влада. Мнение коллектива выражает некто "RSDN Team", но он редко пишет...
абстрактный какой-то "RSDN Team" получаеться... кто это? что это? может там и нет никого?
а вообще "...стране нужны паровозы, стране нужен метал..." (с)класика
по-этому надо треп прекращать и делать "код".
A>переходи на 1с там говорят на русском писать мона...
В Net тоже можно. A>а вообще мне не понравилось бы если вместо привычных операторов мне пришлось бы писать на русском код... бррр... как подумаю аж в дрожь бросает...
Это все дело привычки. Привыкнув к 1С написанию рука так и тянется обозвать методы и переменные по русски, нежели выдумывать англоязычные названия или их транслит. А на это иногда может уйти время и потерять мысль. Иногда это просто бесит. Мои нововведения руского написания методов и переменных ввстречены в штыки. Но ничего плохого не вижу оссобенно для людей с плохим знанием английского. А переход с одной раскладки на другую вырабатываются очень быстро.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alku, Вы писали:
A>а то глянул в код другого проекта страшно стало, все методы в трай кетчах, проверок на входные параметры нету, лоигка лееров размыта... короче полный пи... а все от того что менеджер и "движок" команды оказалсяч не готов к переходу на NET и самое плохое что не захотел воспользоваться опытом других NET проектов.
Это ты уже говоришь не о соглашениях, а о best practices. Это несколько разные документы.
Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: Соглашения по оформлению кода команды RSDN
Здравствуйте, alku, Вы писали:
AVK>>Найдем если будут нормальные аргументы, а не я привык или на одно нажатие на кнопочку меньше. A>in bold — кстати очень серьезный аргумент если вдуматься — повышыние скорости работы, а потом как рефлекс... A>это все сказываеться на том как эфективно програмист может использовать IDE и следовательно сколько он времени тратит на перевод своего "фокуса" с кода на утилитарные действия... еффект как от печати на клаве в слепую. скорость повышаеться.
Я в свое время писал на паскале с его begin/end. Так вот — лично для меня производительность от количества буковок в процедурных скобках нее зависит вобще никак. На собственно набор текста на клавиатуре уходит очень мало времени. Если же начинает уходить много то это повод задуматься над тем все ли правильно в дизайне.
Здравствуйте, mihailik, Вы писали:
M>ЭНули в строчку не помещаются.
Упакуй их архиватором а вообще-то как-то стали RSDN себя жестко вести (по моему мнению)
... << RSDN@Home 1.1.2 stable >>
Re[18]: Соглашения по оформлению кода команды RSDN
KGP>а вообще-то как-то стали RSDN себя жестко вести (по моему мнению)
По-моему нет.
Если спор по техническим вопросам, жёсткость здесь побочное качество. Какая разница, жётско-не жёстко, всё равно имеют смысл только конкретные аргументы.
А если на душевные темы, то и поорать друг на друга не грех.
VP>Потому, что не красив
На вкус и цвет... это не довод.
VP>Непонятно к чему ты эти скобки хочешь больше отнести к DoSomething(), или к if? VP>А когда при чтении кода возникают вот такие вопросы это плохо.
if (condition)
{
if (newCondition)
{
DoSomething();
}
}
И теперь возникают?
Если да, то только вследствии костности мышления.
Никаких объективных причин ставить фигурные скобки так, как предлагает статья я не вижу.
А>Авторы: А>RSDN Team
А>Аннотация: А>Этот документ описывает единый стиль кода, разработанный командой RSDN. В первую очередь он предназначен для использования в проектах, ведущихся в рамках RSDN. Надеемся, что этот стиль будет полезен всем тем, кто так же ищет удобный единый стиль форматирования исходного кода.
еще одна фича:
кто смотрел код от макрософта рефлектором должен был заметить как именуються мемберы классов!!! они все начинаються с m_... странно это очень... в своем стиле они пишут что так не надо делать и тутже смотрим на код и видим что все там не так...
может просто существует два старндарта? один для юзеров другой для внутренних рабочих?
сам я ксатити по с++ привычке до сих пор все мемберы класса с m_ начинаю... может это все не так плохо как может показаться... венгерскую натаю народ и так сильно не юзал и использовал ее укороченный вариант:
— для строк m_str*
— для bool m_b*
иногда для int и long... а все остальное очень походе на то что щас предлагает делать Макрософт...
объяснюсь почему меня эта тема очень волнует:
— щас на фирме я пытаюсь написать стандарт на оформление кода для c# проектов...
в основном это надо для студентов, но и "старым" программерам тоже иногда полезно...
а то очень часто возникает ситуация, что два програмера не могут сойтись во мнении сколько должна занимать табуляция, надо ли вообще использовать табуляции... как надо записывать операторы, декларации и т.д. и т.п.
я пытаюсь написать документ который просто и банально решит такой вопрос — аля корпоративный стандард на оформление кода. в него кстатит должны войти правила по оформлению и безопасности кода... как только напишеться документ обязательно постараюсь поделиться с общественностью.
Здравствуйте, alku, Вы писали:
A>еще одна фича:
Ну, поскольку нас тут сегодня не много, я снова влезу
A>кто смотрел код от макрософта рефлектором должен был заметить как именуються мемберы классов!!! они все начинаються с m_... странно это очень... в своем стиле они пишут что так не надо делать и тутже смотрим на код и видим что все там не так...
На самом деле, в FCL смешаны как минимум 4 подхода к именованию членов класса:
_member
m_member
member
_Member
Может и другие есть. Так что это косяк MS и никакой глубокой идеи в этом нет.
A>может просто существует два старндарта? один для юзеров другой для внутренних рабочих?
Существует неряшливость конкретных разработчиков, пишуших код несоответствующий принятому в компании стандарту.
Здравствуйте, alku, Вы писали:
A>>>может просто существует два старндарта? один для юзеров другой для внутренних рабочих? O>>Существует неряшливость конкретных разработчиков, пишуших код несоответствующий принятому в компании стандарту.
A>что-то очень сомнительно... у макрософта все достаточно сторого и произвола девелопера они скорее всего не допустят...
Факт есть факт Допускают. Например, код мог выйти из исследовательских лабораторий, или вообще адаптирован из кода сторонних компаний, приобретенных MS. Теоретически мог быть какой-нибудь outsourcing (хотя я таких случаев не знаю).
A>код у них проходит слишком много стадий, чтобы такую неряшлевость не заметили...
Могли заметить, и даже наказать. Но не исправить, ибо это а) дорого б) потенциально опасно в) имеет низкий приоритет.
A>так что думаю что стандартов все-таки много или они существуют для каждой группы разработчиков свои.
Ну давай мы проще поступим, я спрошу у MS
A>хочу заметить одну нашу неточность — стандарта на форматирование нету, есть только рекомендации!!! по-этому лучше дальше в диалоге использвать слово рекомендации, а не стандард.
На RSDN есть рекомендации, соглашения и всё что угодно, но не стандарты. В серьезной компании есть стандарты, но никак не рекомендации. Миллионы и гигабайты строк кода, написаных в разном стиле невозможно сопровождать. Люди не вечны, тем более их работа на одном месте. На смену одним приходят другие, которые должны легко читать чужой код.
Offtopic: Знаешь, почему ошибки в комменатриях у MS обозначаются BUGBUG: а не просто BUG?
разумееться один метод форматирования не может претендовать на панацею от всех бед... среда разработки объединяет в себе много вещей которые облегчают чтение кода. это раскраска, форматирование, навигация && outlinning и т.д.
зачем прыгать по открытой закрытой скобке? ну иногда все-таки в if записыветься больше чем одно условие... про рефакторинг можно не расказыать — это возможный кандидат на вынесеине в переменную и т.п. но иногда случаеться.
для примера:
procteted void TestMethod( string data, string format )
{
/// check input parametersif( data == null || data.Length == 0 )
throw new ArgumentNullException( "data" );
if( format == null || format.Length == 0 )
throw new ArgumentNullException( "format" );
/// другой код
}
но очень возможно что в if будет и больше условий... или они будут занимать намного больше места.
я не навязываю свое мнение, я просто прошу вас помочь оценить удобство разных стилей записи... читабельность не теряеться, но это уже возможно дело привычки...
а вот маленький пример где выделеные скобки все-таки полезны:
Здравствуйте, orangy, Вы писали:
O>Здравствуйте, alku, Вы писали:
A>>так что думаю что стандартов все-таки много или они существуют для каждой группы разработчиков свои. O>Ну давай мы проще поступим, я спрошу у MS
если есть возможность, то почему бы не спросить?!
A>>хочу заметить одну нашу неточность — стандарта на форматирование нету, есть только рекомендации!!! по-этому лучше дальше в диалоге использвать слово рекомендации, а не стандард. O>На RSDN есть рекомендации, соглашения и всё что угодно, но не стандарты. В серьезной компании есть стандарты, но никак не рекомендации. Миллионы и гигабайты строк кода, написаных в разном стиле невозможно сопровождать. Люди не вечны, тем более их работа на одном месте. На смену одним приходят другие, которые должны легко читать чужой код.
к чему и стремимся... главное команда, а не один человек...
O>Offtopic: Знаешь, почему ошибки в комменатриях у MS обозначаются BUGBUG: а не просто BUG?
Offtopic конечно, но интересно... не думал на эту тему искать во всем скрытый смысл требует времени
Здравствуйте, Andre, Вы писали:
A>Сорри, немного ошибся ссылкой. Более парвильная ссылка здесь
это обсуждение (по линку которое) доказывает что надо развивать стандарт не сверху-вниз а с низу-вверх...
т.е. от девелоперов до менеджеров и тулзов, а не наоборот.
FxCop мне кстати не очень понравился... местами уж больно академические заморочки, а местами рулит...
но как вещь для проверки правильности жрет слишком много времени... мы пробовали приминять во время написания... а вот на финальной стадии разработки очень даже помогает.
проше отслеживать изминения кода по сорсафе и потом раздавать тумаки за нарушение правил, но такое для больших фирм по моему не будет работать... а для команды до 10 человек очень даже работает... только менеджеру приходиться туго на первых порах. через месяц вся команда уже нормально пашет в установленных правилах и нагрузка на менджера спадает... главное только объяснять каждому почему есть такое правило и что за ним стоит. не обоснованных правил девелопер исполнять не будет
Здравствуйте, Andre, Вы писали:
O>>Ну давай мы проще поступим, я спрошу у MS A>Да можно и не спрашивать, они уже ответили практически.
Да, точно, я это читал, но забыл. Спасибо
Здравствуйте, orangy, Вы писали:
O>Здравствуйте, Воронков Василий, Вы писали:
O>>>Offtopic: Знаешь, почему ошибки в комменатриях у MS обозначаются BUGBUG: а не просто BUG? ВВ>>Почему? O>Потому что поиск по слову BUG (и даже BUG:) срабатывает на DEBUG и на (DEBUG:). O>
я в свое время тулзу написал для поиска таких вещей — для вижуалки шестой... здесь
заветься эта фича Code managment... спасибо макрософтам что в новой студии прикрутили.
Здравствуйте, alku, Вы писали:
A>но не отделимая часть... ты при взгляде должен выхватывать не только ключевое слово, но и правильность конструкции языка.
А зачем выполнять работу компилятора? Он и так неплохо отследит, да и студия подсветит.
A>тут хочу поспорить... зачем равнять искуственный язык програмирования с языком разговорным/письменным?! у них разные цели...
Затем что если можно обойтись одинаковыми правилами то лучше это сделать. Просто потому что так человеку проще.
A>для програмистского языка важные такие вещи, как: A>- компактность записи
В данном случае одинаковая
A>- удобство навигации по коду
В данном случае оба варианта равноценны.
A>- читабельность
В данном случае вариант RSDN лучше.
A>для выделения ключевых слов в коде служит расскраска, а не пробелы!
Читабельность кода должна оставаться на уровне вне зависчимости от используемого редактора.
Здравствуйте, alku, Вы писали:
A>объяснюсь почему меня эта тема очень волнует: A>- щас на фирме я пытаюсь написать стандарт на оформление кода для c# проектов... A>в основном это надо для студентов, но и "старым" программерам тоже иногда полезно... A>а то очень часто возникает ситуация, что два програмера не могут сойтись во мнении сколько должна занимать табуляция, надо ли вообще использовать табуляции... как надо записывать операторы, декларации и т.д. и т.п.
использование табуляции как раз-таки и придумано для того, чтобы не спорили сколько пробелов делать для отступов
так что вопрос только использовать ее или нет (я за использование )
A>я пытаюсь написать документ который просто и банально решит такой вопрос — аля корпоративный стандард на оформление кода. в него кстатит должны войти правила по оформлению и безопасности кода... как только напишеться документ обязательно постараюсь поделиться с общественностью.
Здравствуйте, orangy, Вы писали:
O>Здравствуйте, Воронков Василий, Вы писали:
O>>>Offtopic: Знаешь, почему ошибки в комменатриях у MS обозначаются BUGBUG: а не просто BUG? ВВ>>Почему? O>Потому что поиск по слову BUG (и даже BUG:) срабатывает на DEBUG и на (DEBUG:). O>
Здравствуйте, s.ts, Вы писали:
O>>>>Offtopic: Знаешь, почему ошибки в комменатриях у MS обозначаются BUGBUG: а не просто BUG? ВВ>>>Почему? O>>Потому что поиск по слову BUG (и даже BUG:) срабатывает на DEBUG и на (DEBUG:). O>> ST>дурь какая
Конечно дурь Это шутка была. Но тем не менее:
BUGBUG comments -- comments containing the exact string "BUGBUG" that could be grepped for later in the source code – were placeholders left by developers to mark something to be revisited later. A BUGBUG comment might have mentioned a potential improvement in an algorithm, or it might have said, "need to check the return code here" or "should handle the message being too long."
Здравствуйте, alku, Вы писали:
O>>Аналогично в русском языке (это я привёл пример, как по-моему), пробел ставится перед скобкой, а не после( как в твоём примере ). Ну, и как удобнее читать?
A>тут хочу поспорить... зачем равнять искуственный язык програмирования с языком разговорным/письменным?! у них разные цели...
Это для нас, не англоязычных, он "искусственный", а для англоязычных он самый что-ни-на-есть естесственный. Они программы пишут, что говорят. И в этом я им завидую...
Здравствуйте, akasoft, Вы писали:
A>Это для нас, не англоязычных, он "искусственный", а для англоязычных он самый что-ни-на-есть естесственный. Они программы пишут, что говорят. И в этом я им завидую...
Ну так есть же русифицированные языки программирования.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alku, Вы писали:
A>>ключевые слова не отделяються от скобок пробелами...
A>>жду коментов...
AVK>Ну основная причина была сделать операторы непохожими на методы. Твой же вариант просто не очень хорошо смотрится из-за пробелов внутри скобок (не соответствует оформлению обычного текста и режет глаз).
повторюсь:
— для этих целей очень подходит расцветка... и сразу становиться видно где метод, а где ключевое слово... исключение составлеяет просмотр исходников редактором не приспособленным для работы с ними... аля notepad
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alku, Вы писали:
A>>но не отделимая часть... ты при взгляде должен выхватывать не только ключевое слово, но и правильность конструкции языка.
AVK>А зачем выполнять работу компилятора? Он и так неплохо отследит, да и студия подсветит.
компилятор запускать надо, а подумать и написать правильно проще.
A>>тут хочу поспорить... зачем равнять искуственный язык програмирования с языком разговорным/письменным?! у них разные цели...
AVK>Затем что если можно обойтись одинаковыми правилами то лучше это сделать. Просто потому что так человеку проще.
программеры — не люди шутка.
A>>для програмистского языка важные такие вещи, как: A>>- компактность записи
AVK>В данном случае одинаковая
на один символ больше
A>>- удобство навигации по коду AVK>В данном случае оба варианта равноценны.
на одно тело-движение больше при навигации
A>>- читабельность
AVK>В данном случае вариант RSDN лучше.
не хочу обижать но мне кажеться что это из разряда мое болото лучше...
в обоих случая читабельность одинаковая, просто это дело привычки...
я уже привык выхватывать на экране не только ключивые слова, но и конструкции в целом...
A>>для выделения ключевых слов в коде служит расскраска, а не пробелы! AVK>Читабельность кода должна оставаться на уровне вне зависчимости от используемого редактора.
фраза 70-х годов... на дворе уже 21 век... щас вообще ни кто код без IDE не пишет (исключения всегда найдуться)... и без расцветки редактор считаеться слишком простым чтобы им пользоваться
Здравствуйте, orangy, Вы писали:
O>Здравствуйте, alku, Вы писали:
A>>но например коментирование первой строки заставить править и вторую строку O>Давайте быть критичными к себе В твоем случае такая же проблема с последней строкой.
Здравствуйте, s.ts, Вы писали:
ST>Здравствуйте, alku, Вы писали:
A>>объяснюсь почему меня эта тема очень волнует: A>>- щас на фирме я пытаюсь написать стандарт на оформление кода для c# проектов... A>>в основном это надо для студентов, но и "старым" программерам тоже иногда полезно... A>>а то очень часто возникает ситуация, что два програмера не могут сойтись во мнении сколько должна занимать табуляция, надо ли вообще использовать табуляции... как надо записывать операторы, декларации и т.д. и т.п.
ST>использование табуляции как раз-таки и придумано для того, чтобы не спорили сколько пробелов делать для отступов ST>так что вопрос только использовать ее или нет (я за использование )
а смысл? все-равно каждый настраивает по своему... кто 4 пробела любит, кого-то восемь прет.
я уже два раза сталкивался с ситуацией когда к проекту подключают "крутого" программера и настоять на един стандарте не получаеться с пробелами и табуляциями пусть разбираються философы мне проще тулзу запустиь tabify all && untabify all
економия байт уже не актуальна
A>>я пытаюсь написать документ который просто и банально решит такой вопрос — аля корпоративный стандард на оформление кода. в него кстатит должны войти правила по оформлению и безопасности кода... как только напишеться документ обязательно постараюсь поделиться с общественностью.
ST>ждемс
A>еще одна фича:
A>кто смотрел код от макрософта рефлектором должен был заметить как именуються мемберы классов!!! они все начинаються с m_... странно это очень... в своем стиле они пишут что так не надо делать и тутже смотрим на код и видим что все там не так...
A>может просто существует два старндарта? один для юзеров другой для внутренних рабочих?
Просто скорее всего значительная часть кода писалась еще до введения какого-либо стандарта кодирования. Возможно даже, что различные стили использовались намеренно — с целью сравнительной оценки их удобства. А потом банально не хватило времени на причесывание.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alku, Вы писали:
A>а вообще мне не понравилось бы если вместо привычных операторов мне пришлось бы писать на русском код... бррр... как подумаю аж в дрожь бросает...
Это ты еще на славном языке "Рапира" не писал... Грамотный, кстати, был язык, этакий Паскаль по русски...
Здравствуйте, alku, Вы писали:
A>проше отслеживать изминения кода по сорсафе и потом раздавать тумаки за нарушение правил, но такое для больших фирм по моему не будет работать... а для команды до 10 человек очень даже работает... только менеджеру приходиться туго на первых порах. через месяц вся команда уже нормально пашет в установленных правилах и нагрузка на менджера спадает... главное только объяснять каждому почему есть такое правило и что за ним стоит.
За ним стоит очередь безработных девелоперов которые с удовольствием поисполняют правила. A>не обоснованных правил девелопер исполнять не будет
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Merle, Вы писали:
A>>а вообще мне не понравилось бы если вместо привычных операторов мне пришлось бы писать на русском код... бррр... как подумаю аж в дрожь бросает... M>Это ты еще на славном языке "Рапира" не писал... Грамотный, кстати, был язык, этакий Паскаль по русски...
Представляю: указатель — стрела, переменная — ванька-встанька, класс — замок, тип — род.
В Замке зМосква делаем стрелу в ваньку-встаньку ввИван, рода рЧеловеческого.
Здравствуйте, alku, Вы писали:
A>повторюсь: A>- для этих целей очень подходит расцветка... и сразу становиться видно где метод, а где ключевое слово... исключение составлеяет просмотр исходников редактором не приспособленным для работы с ними... аля notepad
Здравствуйте, alku, Вы писали:
AVK>>А зачем выполнять работу компилятора? Он и так неплохо отследит, да и студия подсветит.
A>компилятор запускать надо, а подумать и написать правильно проще.
У тебя позиция пробела влияет на твое подуманье перед тем как напишешь код? Однако.
AVK>>В данном случае одинаковая
A>на один символ больше
На один меньше. Внутри скобок 2 пробела, после оператора только 1.
A>я уже привык выхватывать на экране не только ключивые слова, но и конструкции в целом...
Ну тогда извини. Я вот тоже так писал, но потом переучился. В итоге с пробелом все таки получше.
Здравствуйте, alku, Вы писали: A>Украина, Львов
Нифига себе. Никогда бы не подумал. У нас так в основном дефицит квалифицированных девелоперов за мелкие деньги Ну, так это везде так — читаем Спольски.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: Соглашения по оформлению кода команды RSDN
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, alku, Вы писали: A>>Украина, Львов S>Нифига себе. Никогда бы не подумал. У нас так в основном дефицит квалифицированных девелоперов за мелкие деньги Ну, так это везде так — читаем Спольски.
у нас даже за "нормальные" деньги перекупить тяжко... конкуренция плюс планка знаний для поступления достаточно высокая....
ну с москвой равнять не буду... от города и региона сильно зависит зарплата и возможности... в москве для програмера наверно 1000 баксов "очень средняя" (в плане маленькая) зарплата...
а если студентов брать так с ними мороки куча, месяц как минимум за студентом с "горшком" ходить будеш, это если самому работой не заниматься...
Здравствуйте, alku, Вы писали:
A>переходи на 1с там говорят на русском писать мона...
Не пойдёт, т.к. в основе лежит аглоязычный визуал бейсик. Нет русских языков программирования, одни русскоязычные да русифицированные. Ну, может есть у военных или у космонавтов (что почти то же самое), но мне об этом ничего не известно...
A>а вообще мне не понравилось бы если вместо привычных операторов мне пришлось бы писать на русском код... бррр... как подумаю аж в дрожь бросает...
Это уже есть, потому как появилась привычка, и понимание правил другого разговорного языка. Увы, не мы изобрели процессор...
... << RSDN@Home 1.1.3 beta 2 >>
Re[15]: Соглашения по оформлению кода команды RSDN
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, alku, Вы писали:
A>>у нас даже за "нормальные" деньги перекупить тяжко... конкуренция S>Что ж, буду знать, куда ломиться. У вас рабочую визу получить легко?
а это что такое — рабочая виза?. мы же не закордон какой-то... у нас все просто... приехал квартиру снял, работу нашел и без проблем... даже загран-паспорта не надо.
A>>плюс планка знаний для поступления достаточно высокая...
вот с этим могут быть проблемы. так что тут надо сначало переговорить, а потом ломиться. но с работой проблем никаких нету
A>>ну с москвой равнять не буду... от города и региона сильно зависит зарплата и возможности... в москве для програмера наверно 1000 баксов "очень средняя" (в плане маленькая) зарплата...
S>Ну, у нас за такие деньги можно очень даже выбирать. Тут куда ни плюнь — попадешь в программера. А заказчиков как-то намного меньше.
от москвы у нас зарплаты в два раз меньше будут... но жить дешевле: еда + квартира + по мелочам...
вообще-то надо просто на фирмы "большие" поступать — будет и работа и деньги и все что поплдолжено
спецу работу найти довольно просто...
R3>Не используйте специальных префиксов, поясняющих, что это класс. Например, FileStream, а не CFileStream.
Так решили ребята писавшие FCL. Если это не соблюдать то классы будут резко отличаться от классов FCL. Однако это всего лишь правило. Иногда куда выгодее ввести префикс. Например, они могу оказаться нужны если имеются классы с аналогичным разванием и эти классы часто испошьзуются совместно со своими.
Кстати, МС и сам это правило иногда нарушает. Например, все классы CodeDom имеют префикс Code.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S> Возможно даже, что различные стили использовались намеренно — с целью сравнительной оценки их удобства. А потом банально не хватило времени на причесывание.
Это вряд ли.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, orangy, Вы писали:
O>Может и другие есть. Так что это косяк MS и никакой глубокой идеи в этом нет.
Согласен.
A>>может просто существует два старндарта? один для юзеров другой для внутренних рабочих? O>Существует неряшливость конкретных разработчиков, пишуших код несоответствующий принятому в компании стандарту.
А вот тут не факт. Сдается мен что в МС просто стили если и выдерживаются, то внутри отдельных команд. У них же типа командно-ячеечная организация. А может просто какой-то код унаследованый.
В ихнем докуменете вообще не оковаривается скрытая часть. Им же важно было как класс выглядит извне. Они же правила для библиотек писали.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, orangy, Вы писали:
O>Факт есть факт Допускают. Например, код мог выйти из исследовательских лабораторий, или вообще адаптирован из кода сторонних компаний, приобретенных MS. Теоретически мог быть какой-нибудь outsourcing (хотя я таких случаев не знаю).
Да он мог быть даже с С++ портирован. А там в МС m_ вообще стандарт.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alku, Вы писали:
A>и знаете что корёбит? пробел между скобкой и ключивым словом!
Т.е. пробелы внутри скобок тебя не коробят? Ну, ты извращенец.
Что же касется пробелов между ключевыми словами и открывющей скобкой, то я тоже раньше их не ставил, и мен кажется это не логичным. Но так пишет 90% программистов. В кодах МС практически нельзя найти код не удовлетворяющий этому правилу. Да и в МСДН тоже.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Smarty, Вы писали:
S> S>Много лучше, чем в статье. Но ведь сейчас начнется — а я так привык!!! И никуда — аргумент непрошибаем.
Дело в том, что именно ты так привык. Ничего хорошего в таком стиле нет. Пробем мужду ифом и скобкой что есть, что нет. Дело привчки, а вот пробелы после открывающей скобки и перед открывающий — это точно бардак которому нет оправдений и который нужно искоренять.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну основная причина была сделать операторы непохожими на методы.
Откровенно говоря плохое основание. Текст редактируется в IDE, а она подсвечивает ключевые слова. Так что не ошибешся.
AVK> Твой же вариант просто не очень хорошо смотрится из-за пробелов внутри скобок (не соответствует оформлению обычного текста и режет глаз).
Вот тут полностью согласен.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alku, Вы писали:
A>но например коментирование первой строки заставить править и вторую строку
У тебя наверно плохая папять. Тут же много раз говорилось, код пишится не для облегчения его написания. Он пишится для того чтобы его читать. Если тебе нужно временно что-то зкомпнтарить, то сделай себе пару макросов и роблем не будет.
В твоем же случае, если нужно постоянно коментировать код, легко можно сделать так:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AndrewVK, Вы писали:
AVK>>Ну основная причина была сделать операторы непохожими на методы.
VD>Откровенно говоря плохое основание. Текст редактируется в IDE, а она подсвечивает ключевые слова. Так что не ошибешся.
AVK>> Твой же вариант просто не очень хорошо смотрится из-за пробелов внутри скобок (не соответствует оформлению обычного текста и режет глаз).
VD>Вот тут полностью согласен.
проблема в том что потеряеш ориентир и будеш воспринимать код как простоя язык... а на код действуют свои мерки и они намного суровее чем на простой разговорный/литературный язык.
Здравствуйте, beretta, Вы писали:
B>Вобщем, один пробел после инструкции лишний "чик" делает и мозг немножко рассеивается
Сколько не медитировал, никаких "чик" в мозгу не произошло. Потому что грамматике не соответствует. Мозг отдыхает, когда написано, как в книжке. Книжки часто читаем? Не только специальную, но художественную литературу?
Если бы чаще, чем "редко", то и вопросов бы не было. Сказалась бы привычка...
Здравствуйте, VladD2, Вы писали:
AVK>>Ну основная причина была сделать операторы непохожими на методы. VD>Откровенно говоря плохое основание. Текст редактируется в IDE, а она подсвечивает ключевые слова. Так что не ошибешся.
Но было так не всегда.
А ещё чёрно-белые принтеры и пр. "деревянные игрушки"...
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alku, Вы писали:
A>>и откудова цифра 90%???
VD>Из просмотра кода. Погляди на код МС, Сан и т.п. Загляни в МСДН...
макрософт не показатель — ее код составляет от общего меньше 10%... главное проги которые народ пишет.
A>>главное логичность и удобство...
VD>Кому? Тебе лично? Если ты впрягся в большой проект, то будь добр выполнять его требования. Если каждый будут все делать по своему, то будет бардак и каша.
A>> мне очень кажеться что пробел просле ключевого слова не удобен... а вот пробел после скобки выделает нужные данные...
VD>Ну, если ты собираешся писать код исключительно для себя. Или если ты можешь навязать свой стиль в своей конторе (и она не продает код другим), то можешь и дальше так писать. А если нет, то очень советую менять привычки.
слегка звучит дико... оснований нету... пытаешся авторитетом давить?!
заказчика на такой код не жалуеться — ему главное чтобы работало и только потом его волнуют вопросы документированости кода, а про стиль он вообще очень редко вспоминает... и то в основном именование enum и некоторых переменных... такой мелочью как простоновка пробелов в скобках или перед скобками волнует почему-то только девелопера.
если впрягся в большой проект то будь добр и его сапорт в дальнейшем делай... а если писать так чтобы от тебя отстали, то получаеться что в сфере бизнеса и получения стабильной прибыли буде жопа. очень редко проекты пишуться так чтобы потом кто-то другой лез в него и ковырял. но даже в таком случае должна сработать этика человека который будет работать и он обязан будет держать стиль кода. Основные деньги приносит сапорт — потому что доход стабилен. а с проектами может быть и пролет и выиграш... но он в основном разовый....
следовательно совет про смену стиля не уместен... не надо навязывать своего видинья.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, alku, Вы писали:
A>>а вот маленький пример где выделеные скобки все-таки полезны:
IT>И чем они полезны? Ух, аж в глазах рябит. Сравни лучше вот с этим:
чем длинее выражение тем тяжелее найти его конец... а скобка помогает сделать это быстро при помощи клавиш навигации: найти парную скобку
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, alku, Вы писали:
A>>главное логичность и удобство... мне очень кажеться что пробел просле ключевого слова не удобен... а вот пробел после скобки выделает нужные данные...
IT>Ключевое слово тут — кажется
кажеться вставленно чтобы никого не обидить, ну и повод был к словам предраться.
A>>философия: A>>основная проблема что на читабильность кода нету метрик, по которым можно было бы сказать что код читаемый и "удобваримый" или нет... если вывести такую метрику то от нее можно строить правила оформления кода...
IT>Точно, поэтому спорить на эту тему просто глупо.
согласен
A>>но это все теория на самом деле тон команде задает менеджер или главный программер.. (мне Брукс'овское описание команды понравилось и модель ее постороения) следовательно он как главный должен определять стиль и контролировать код. Это я думаю главный фактор!
IT>В нормальных командах соглашения предварительно обсуждаются, принимаются, затем долгое время шлифуются и, конечно же, никогда не объявляются догмой. Если какое-либо правило не устраивает большинство, то оно запросто может быть изменено. Что совсем не означает, что соглашения можно менять каждый день.
слово нормальный не применимо... потому как на большой фирме приходиться работать с тем что есть в наличии, а не выбирать себе как на ярмарке... по-этому менеджером всегда ставят "авторитет" — а второй скрипкой тот кто его поддерживает или долгое время работал в команде с этим менеджером... тогда практически пробить что-то не реально. (опять в философию потянуло
A>>Так или иначе получаеться что топ-программер не осознано навязывает свое мнение другим и по многим причинам: начиная от авторитета и заканчивая админовскими правами — этот человек не осознано диктует условия в которых приходиться работать команде. вот тут и получаються конфликты, если человек не достаточно "гибкий" для работы в команде или имеет достаточный авторитет чтобы возвразить и настоять на своем решении, то конфликт не избежен... это так сказать подооплека всего спора про форматинг... но в нем забывают главное: код должен быть оформлен так чтобы команда которая над ним работает его понимала и не тратила силы на "перестановки скобок". главное сдать проект, а не форматировать код!!!
IT>А ты не находишь, что топ-программер потому и топ, что у него больше опыта и знаний, в том числе и в способах оформления кода.
проблема в том что все правила должны быть обоснованы, иначе они будут оспорены рано или поздно. топ программер очень редко объясняет почему принято такое правило, а не другое. и в статье присутсвует мнение что все что написано есть аксиомы и не должны быть оспорены.
A>>ну и заканчивая спор могу сказать что от стиля записи скобок сильно не поменяеться мнение топ програмера. IT>Ну если ты так считаешь и для тебя это не важно, то просто пиши так как гласит соглашение. В чём проблема
я давно знал что спор на пустом месте. я просто решил предложить свой стиль и посмотреть на сколько он будет вопринят... не оценили, ну и ладно... чего тут шашкой махать то?
IT>Понимае чего? Понимание расставления скобок?
ведь скобки — это удобно!
A>>думаю дальше спор про скобки вести безполезно... каждый остался при своем мнении...
IT>Разница знаешь в чём? Ты не сумел отстоять своё мнение. А знаешь почему? Потому что это вовсе не то мнение, которое имеет смысл отстаивать. Просто пойми, хочешь работать в команде, играй по её правилам. Если не понятно почему, читай басни Крылова.
а как тут его отстоиш если аргументы просто супер, например:
— отстой
— так 90% кода написано (когда написано, в каком году, на сколько он уже устарел в свете последних технологий и тулзовеней?)
— мне не нравиться и все...
странный вы народ... относитесь к спору как будто я у вас в команде работаю...
не работаю я с вами в одной команде... я вообще далеко от вас... и у меня своя команда есть...
спорить про стили бесмысленно, но при этом в статье не дать не одной алтернативы тоже глупо... хотя статью можно рассматривать как внутренний документ который используеться командой RSDN для оформления кода.
то что опубликовано на RSDN просто рекомендация людей, который по той или иной причине считают, что то что они делают — правильно и единственно возможный вариант... но это не правда... это простое навязывание своего видинья. обосновонасти правил в статье не хватает.
и мой стиль не чуть не хуже и не лучше... он просто расчитан на других людей.
A>>внутри скобок пробел — отделяет условие;
VD>А по-русски ты тоже пишишь( в скобках )?
В русском языке функция скобок — скрытие "опционального" текста, комментариев (того, что можно и не читать). В операторе for, if, while условие наоборот нужно выделить.
Кстати по той же причине я удивляюсь светло-зелёной раскраске комментариев в Visual Studio. Комментарии в исходниках — самое главное, на что нужно сразу обращать внимание. Их нужно не скрывать, а наоборот выделять.
P.S. Кстати, насчёт префиксов. Открыл FxCop 1.30 (сегодня вышел). Там все приватные переменные через "m_" объявлены. А ты говоришь почти не встречается! Основоположники чистоты кода всё-таки
VD>>Из просмотра кода. Погляди на код МС, Сан и т.п. Загляни в МСДН...
A>макрософт не показатель — ее код составляет от общего меньше 10%... главное проги которые народ пишет.
Хм, сомненья гложут. Я подозреваю, что на сегодня в Микрософте пишут хороший процент мирового C#-кода.
А>Вот и не надо подводить под это какие-то странные обоснования типа "читабельнее". А>Надо было прямо написать "MS за нас всё придумала. Ни шага в сторону.".
Паранойей балуемся? Пиши как хочешь, кто тебе мешает?
Но твои Линуксовые замашки обычному среднему .NET-программисту просто нафиг непонятны. Так что, если будешь работать в обычной средней .NET-комманде, придётся впитывать принятые правила поведения.
Здравствуйте, mihailik, Вы писали:
VD>>>Из просмотра кода. Погляди на код МС, Сан и т.п. Загляни в МСДН...
A>>макрософт не показатель — ее код составляет от общего меньше 10%... главное проги которые народ пишет.
M>Хм, сомненья гложут. Я подозреваю, что на сегодня в Микрософте пишут хороший процент мирового C#-кода.
O>>Существует неряшливость конкретных разработчиков, пишуших код несоответствующий принятому в компании стандарту.
A>что-то очень сомнительно... у макрософта все достаточно сторого и произвола девелопера они скорее всего не допустят... код у них проходит слишком много стадий, чтобы такую неряшлевость не заметили... A>тестирование, код ревью и т.д. и т.п. вещи... так что думаю что стандартов все-таки много или они существуют для каждой группы разработчиков свои.
Фигня. Ты посмотри mscorcfg, там такая грязища. И тянут это от версии к версии без всякого причёсывания.
Я бы на их месте делал то же самое: отладил, протестировал, залил — работает? Раз работает то больше не трогать, пока на эту часть больше ничего не завязано.
В конечном счёте всё измеряется баксами, нужно мозги к этому настраивать.
Здравствуйте, mihailik, Вы писали:
M>Кстати по той же причине я удивляюсь светло-зелёной раскраске комментариев в Visual Studio. Комментарии в исходниках — самое главное, на что нужно сразу обращать внимание. Их нужно не скрывать, а наоборот выделять.
Но им же это не надо, у них язык один, и он же разговорный! А коментарии у них опциональны.
Здравствуйте, mihailik, Вы писали:
M>Да и ходят слухи, что разные части .NET Framework публикуются для избранных университетов и всяких организаций под особыми лицензиями.
Ну, именно C#-кода в Роторе приблизительно в 10 раз меньше чем в Моно.
Но дело не только в Шарп-коде. Есть полтора гига МСДН-а. И большинство примеров там именно в таком стиле. А МСДН — это почти библия для Виндовс-программиста.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, akasoft, Вы писали:
A>Иногда. Когда упрусь. Или когда надо быстро изучить что-то новое и сложное. Но очень быстро. С бумаги восприятие другое.
Незнаю. Я читаю код с бумаги в основном только в статьях.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alku, Вы писали:
A>а так — проехали... не очем спор вести. каждый доказал что свое болото ближе...
Дело в том, что со многими из этих правил тот же ИТ был не согласен. И очень многие его предпочтения были отклонены. Причем эти предпочтения совподали с мнением МС, но все же команда есть команда.
Я тоже был вынужден серьезно перестроиться. Не скажу что мне это было приятно. Но таки это намного приятнее чем переключаться при чтении разных кусков кода.
A>скучно и предсказуемо было с самого начала что этим все и закончиться...
Слабая отмазка.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>А ты не находишь, что топ-программер потому и топ, что у него больше опыта и знаний, в том числе и в способах оформления кода.
Кстати, достаточно поглядеть на рейтинг тех кто защищает правлиа, чтобы в этом убидиться.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alku, Вы писали:
A>>слегка звучит дико... оснований нету... пытаешся авторитетом давить?!
VD>Я? Ни в коем разе. Я никогда ничего не пытаюсь. Я если захотел, то делаю.
A>>заказчика на такой код не жалуеться — ему главное чтобы работало и только потом его волнуют вопросы документированости кода, а про стиль он вообще очень редко вспоминает... и то в основном именование enum и некоторых переменных... такой мелочью как простоновка пробелов в скобках или перед скобками волнует почему-то только девелопера.
VD>Код нужен не заказчику. Код нужен твоей же фирме. Его ведь еще читать, а то и менять прийдется.
опять пролет... фирме код нужен до тех пор пока он будет приносить прибыль... а потом действительно хоть на свалку... только сроки за которые фирма надееться получать от написаного кода могут тянуться на года... например фирма до сих пор хранит сорсы проги написаной на win3.1 толку от тех сорсов довольно мало... на данный момент там полезного дай бог чтобы 10% кода оказалось... коду пора на свалку, но его еще держат... надеються что еще может понадобиться...
A>>если впрягся в большой проект то будь добр и его сапорт в дальнейшем делай... VD>Один? В большом проекте и один? Ну, ну...
не утрируй плиз... главных програмеров на проект много быть не должно иначе точно посоряться а тебе это надо? или фирме это надо? самое интересное что при дифиците ресурсов большой проект дествительно моежт начать разрабатывать один программер он же и менеджер, и архитектор и т.д.
A>> а если писать так чтобы от тебя отстали, то получаеться что в сфере бизнеса и получения стабильной прибыли буде жопа.
VD>А я о чем?
A>> очень редко проекты пишуться так чтобы потом кто-то другой лез в него и ковырял.
VD>Что то тебя колбасит. То ты умные вещи говоришь, то ... не очень.
VD>Код пишится исключительно чтобы потом его ковыряли. Иначе его можно было бы уничтожать сразу после получения исполняемых модулей.
в крайности впадать не надо... сам себе противоречиш... хорошо написаный код может лежать без тача годами... кому он нужен до тех пор пока за него не будет платить деньги?! что-то плохо у тебя с бизнес обоснованиями все во круг денег и прибыли вертиться, а идеология это либо для бедных или очень богатых... (для тех кому делать нечего тоже)
A>> но даже в таком случае должна сработать этика человека который будет работать и он обязан будет держать стиль кода. VD>Обычно после орлов не соблюдающих никаких норм код приходится переписывать или, в лучшем случае, рефакторить.
у этого кода ошибка в том что мы его не писали ?!
A>> Основные деньги приносит сапорт — потому что доход стабилен. а с проектами может быть и пролет и выиграш... но он в основном разовый....
VD>А. Ну, ну... Тогда конечно. Тогда лушче вообще все в столбик писать. А стиль — это вред. Ведь чем хуже выглядит код, тем больше работы для сапорта.
не смешно... индусы так и делают! поработай с индусами и получиш по самые помидоры... там уже рефакторинг не помогает, проще переписывать код... переписать дешевле выходит чем тратить время на рефакторинг.
A>>следовательно совет про смену стиля не уместен... не надо навязывать своего видинья.
VD>Стиль навязывается коллективом. Все кто не хочет этого понимать и принимать идут работать в городом одиночистве. А точнее идут в лес.
Пушким прям... у лукоморья дуб зеленый... и програмист в цепях сидит...
пролет опять же: стиль навязываеться топ программером и в некоторых случаях его стиль слегка правят. такое разве что не заметно на фирмах которые CMM(I) level 3 сдали... они просто эту стадию уже пережили и у них это уже все принято и на бумаге написано.
Здравствуйте, VladD2, Вы писали:
A>>скучно и предсказуемо было с самого начала что этим все и закончиться...
VD>Слабая отмазка.
отмазка от чего? от войны на мясорубках?
если публикуете то будьте готовы выслушать чужие мнения и оценить их, а не "спускать в унитаз". вы же не принимаете по статье не одного изминения. все сводиться к тому что вы заняли глухую оборону и ни чего не хотите слышать и менять. (щас услышу аргумент что пока и менять то нечего...)
а вы уверены что так и есть правильно? "...а судьи кто?.." (с)Грибоедов "Горе от ума"
то что вы выставили есть мнение только вашой команды и ничего более, а на сайт народу много ходити я не уверен что предложеный вами вариант достаточно хорош... ничего личного, но без доработки я бы эти "рекомендации" в свою команду не пустил.
а вообще надо искать компромисы. найдем ли мы их? что-то очень сомнительно.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, IT, Вы писали:
IT>>А ты не находишь, что топ-программер потому и топ, что у него больше опыта и знаний, в том числе и в способах оформления кода.
VD>Кстати, достаточно поглядеть на рейтинг тех кто защищает правлиа, чтобы в этом убидиться.
да будь ты хоть семь пядей во лбу програмер, но человеком могеш оказаться паршивым... (сории ничего личного)...
а работать приходиться с людьми, а не с машинами. поэтому топ програмер должен почти всегда быть открыт для предложений и стараться их не откидывать, а по крайней мере убеждать что в определенных случаях его мнение принять будет лучше, а не предложенный кем-нибудь вариант. богатсво выбора сужать не надо искуственно. (опять философия, блин тут с вами философом скоро станеш)... не откидывайте вариант сразу — дайте ему отлежаться, попробуйте поработать с ним... (хотя не предвзято это не получиться, это разве что на "белых крысах" испытывать или студентах и только тогда говорите что он не пригоден.
а это щас давление авторитетом, мол мы експы набрали столько что вам не унести и мы знаем что лучше... до research не дотягивает, так просто — форум поговорить.
M>>Комментарии в исходниках — самое главное, на что нужно сразу обращать внимание. Их нужно не скрывать, а наоборот выделять.
A>Но им же это не надо, у них язык один, и он же разговорный! А коментарии у них опциональны.
Не понял
... << RSDN@Home 1.1.3 stable >>
Re[10]: Соглашения по оформлению кода команды RSDN
Здравствуйте, alku, Вы писали:
A>если публикуете то будьте готовы выслушать чужие мнения и оценить их, а не "спускать в унитаз". вы же не принимаете по статье не одного изминения. все сводиться к тому что вы заняли глухую оборону и ни чего не хотите слышать и менять.
Это защитная реакция такая. Направленная на поддержание стабильности.
Ты сказал своё мнение, тебе ответили. Чего ещё надо? Ты думал переубедить коллектив силой нескольких десятков постов?
Но и тебе никто не навязывал, если у тебя есть свой коллектив — ну опубликуй правила своего коллектива.
А давать оценки разные, по собственному видению — ну так для этого мы тут и пишем. Это и есть обмен мнениями.
И ещё, если тебе пишет красненький IT, — это мнение именно IT, если красненький Влад — это мнение Влада. Мнение коллектива выражает некто "RSDN Team", но он редко пишет...
Здравствуйте, alku, Вы писали:
A>>Это защитная реакция такая. Направленная на поддержание стабильности. A>может и да может и нет... кто его разберет стабильность это или застой... а там глядиш и болото. A>жизнь — в движении, остоновился значить мертв.
Я за спираль. Идёшь вокруг горы и думаешь, хватит силёнок поднятся на пол-метра? Или ещё кружок пройти, поесть, на солнышке погреться... А потом рвануть сразу на 2 метра. Но там точно будет холоднее...
A>>Ты сказал своё мнение, тебе ответили. Чего ещё надо? Ты думал переубедить коллектив силой нескольких десятков постов? A>по крайней мере я не думал что будет такой негатив на предложение.
Да где он? Лениво ответили двое-трое, и весь негатив. Им не понравилось твоё предложение, и они нашли сил тебе об этом написать. Другие просто проигнорировали.
Делай выводы. Либо мир не готов тебя принять, либо ты не готов принять мир, либо одно из трёх...
A>>Но и тебе никто не навязывал, если у тебя есть свой коллектив — ну опубликуй правила своего коллектива. A>так их написать сначало надо... думал взять за основу RSDN, а они мне не понравились значиться с нуля прийдеться рожать.
Не понял. А говорил есть коллектив... И что же он есть...
... << RSDN@Home 1.1.3 beta 2 >>
Re[10]: Соглашения по оформлению кода команды RSDN
Здравствуйте, mihailik, Вы писали:
M>У кого разговорный язык? Какой именно?
У англоязычных. У них этот язык и разговорный, и машин на нём говорить заставляют.
А нам остаётся только переводить и долго мучится, или поставить крест на "великомогучем" и говорить на английском русском. Почему нет? Есть английский американский.
VD>Дело в том, что именно ты так привык. Ничего хорошего в таком стиле нет. Пробем мужду ифом и скобкой что есть, что нет. Дело привчки
Не понял. Есть конкретная причина, повторить?
VD>, а вот пробелы после открывающей скобки и перед открывающий — это точно бардак которому нет оправдений и который нужно искоренять.
В чём заключается этот бардак? Ты что, считаешь правила русского языка применимыми и для C#?
VD>>И ты часто печатаешь код? Да и жирным можно выделять...
A>Иногда. Когда упрусь. Или когда надо быстро изучить что-то новое и сложное. Но очень быстро. С бумаги восприятие другое.
Специально для этого я сделал подключаемый протокол расцветки кода.
A>У англоязычных. У них этот язык и разговорный, и машин на нём говорить заставляют.
Между английским языком и китайским меньше различий, чем между английским и паскалем, согласен?
Поэтому аналогии здесь нужно проводить, но аккуратно. Понимая, что ты имеешь ввиду. Я вот не понял, что ты говорил про комментарии.
Комментарии в C# предназначены для конкретных, сугубо утилитарных целей. На каком бы языке ни говорил читающий, всё равно выделенные, яркие комментарии будут лучше, чем замытые на светлом фоне.
Общий тезис такой. В правилах кодирования конечный судья — здравый смысл. И на всё должна быть причина, если мы решаем что-то внедрять или запрещать.
... << RSDN@Home 1.1.3 stable >>
Re[13]: Соглашения по оформлению кода команды RSDN
Здравствуйте, alku, Вы писали:
A>слово нормальный не применимо... потому как на большой фирме приходиться работать с тем что есть в наличии, а не выбирать себе как на ярмарке...
У нас на фирме, которая вобщем то довольно большая, правила кодирования были поправлены по моей просьбе в первую же неделю после моего устройства. В принципе изменений было немного, но тем не менее.
Здравствуйте, alku, Вы писали:
A>если публикуете то будьте готовы выслушать чужие мнения и оценить их, а не "спускать в унитаз".
А почему ты решил что твое мнение спустили в унитаз? Мы его выслушали, многие в команде с ним не согласны, и никто не поподдержал. Что ты еще хочешь от нас?
A> вы же не принимаете по статье не одного изминения.
Почему, принимаем. Но ты пока в меньшинстве. Согласись, принимать точку зрения большинства это нормальный подход.
A> все сводиться к тому что вы заняли глухую оборону и ни чего не хотите слышать и менять.
Могу прояснить если ты не в курсе. Эти правила написаны не от балды, а составлены на основании нескольких документов и мнения команды. Кроме того они неоднократно и очень тщательно обсуждались. Или ты считаешь что мы должны менять правила по первому твоему требованию?
A>а вы уверены что так и есть правильно?
Нет.
A> "...а судьи кто?.."
Мы сами. Даже если твой вариант и не хуже то он совершенно точно не лучше. Подстраивать под твои привычки правила по меньшей мере странно.
A>то что вы выставили есть мнение только вашой команды и ничего более,
Разумеется. А разве мы где то утверждали обратное?
A> а на сайт народу много ходити я не уверен что предложеный вами вариант достаточно хорош... ничего личного, но без доработки я бы эти "рекомендации" в свою команду не пустил.
А тебя никто и не заставляет. Я бы вот к примеру вполне согласен был бы с этими правилами и сильно несогласен с пробелами внутри скобок. Ничего личного, но твои "рекомендации" я бы в команду не пустил.
A>а вообще надо искать компромисы. найдем ли мы их?
Найдем если будут нормальные аргументы, а не я привык или на одно нажатие на кнопочку меньше.
Здравствуйте, mihailik, Вы писали:
A>>Им не понравилось твоё предложение, и они нашли сил тебе об этом написать. Другие просто проигнорировали.
M>Да нет, Влад вон очень ругается, совсем не лениво. Мол, полная фигня и лажа эти пробелы — убери их нафиг.
Правильно ругается, фигня и лажа.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alku, Вы писали:
A>>слово нормальный не применимо... потому как на большой фирме приходиться работать с тем что есть в наличии, а не выбирать себе как на ярмарке...
AVK>У нас на фирме, которая вобщем то довольно большая, правила кодирования были поправлены по моей просьбе в первую же неделю после моего устройства. В принципе изменений было немного, но тем не менее.
а я не говорю что у нас правил нету... они есть, но не на бумаге. и самое главное что команда их сама выработал за три дня... а теперь пишем, но иногда возникают мелкию нюансы... и я хочу от таких нюансов избавиться раз и на долго, и чтобы стандарт был не только в одной команде, но и в других проектах тоже... тогда переход людей между командами не будет вызывать "отторжения" кода... ну и должно на качество кода сильно повлиять.
а то глянул в код другого проекта страшно стало, все методы в трай кетчах, проверок на входные параметры нету, лоигка лееров размыта... короче полный пи... а все от того что менеджер и "движок" команды оказалсяч не готов к переходу на NET и самое плохое что не захотел воспользоваться опытом других NET проектов.
но какого девелоперы должны страдать от такого? после разговора с ними они почти все пожаловались на очень хреновый код и его качество, а это все люди с довольно большим стажем работы... (правда это уже второй или третий состав на проекте
вот и чтобы такое не повторялось я хочу написать стандард для c# проектов, который надеюсь будет поддержан всеми командами работающих по направления NET. (что не удивительно бывшие с++ намного лучше оформляют код и намного он у них надежней чем у делфистов... дурное наследие?! или само-контроль выше?!)
Offtopic: очень не порадовало что почти все "решения" очень рекламируешеся для NET от майкрософт оказались не очень состоятельны для большого проекта. где вылизли огромные потребления по памяти, где по перфомансу пролет... конечно многое зависит от того как правильно использовать технологии, но оказываеться что не все так радужно как хотелось бы.
стандард если в него включить не только форматинг, но и еще немного правил повышающих стабильность кода + некоторые известные нюансы будет очень полезен всем.
Re[11]: Соглашения по оформлению кода команды RSDN
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alku, Вы писали:
A>>а вообще надо искать компромисы. найдем ли мы их?
AVK>Найдем если будут нормальные аргументы, а не я привык или на одно нажатие на кнопочку меньше.
in bold — кстати очень серьезный аргумент если вдуматься — повышыние скорости работы, а потом как рефлекс...
это все сказываеться на том как эфективно програмист может использовать IDE и следовательно сколько он времени тратит на перевод своего "фокуса" с кода на утилитарные действия... еффект как от печати на клаве в слепую. скорость повышаеться.
Re[15]: Соглашения по оформлению кода команды RSDN
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, mihailik, Вы писали:
A>>>Им не понравилось твоё предложение, и они нашли сил тебе об этом написать. Другие просто проигнорировали.
M>>Да нет, Влад вон очень ругается, совсем не лениво. Мол, полная фигня и лажа эти пробелы — убери их нафиг.
IT>Правильно ругается, фигня и лажа.
аргумент плиз... у меня есть: работать становиться как минимум на одно тело-движение меньше.
а там как в мультике про дюймовочку:
"...
— сколько она ест?
— пол зернышка в день.
— а в год? давайте посчитаем уважаемы кроты..."(с)Союзмультфильм
Здравствуйте, alku, Вы писали:
AVK>>Найдем если будут нормальные аргументы, а не я привык или на одно нажатие на кнопочку меньше. A>in bold — кстати очень серьезный аргумент если вдуматься — повышыние скорости работы, а потом как рефлекс...
А если ещё более серьёзно вдуматься, то вот такой вообще немеряно повышает скорость работы:
public class MyClass:ClassBase{public MyClass(int param):base(param){_param=param}public int Param{{get{return _param;}set{_param=value}}}
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, alku, Вы писали:
A>>а вот маленький пример где выделеные скобки все-таки полезны:
IT>И чем они полезны? Ух, аж в глазах рябит. Сравни лучше вот с этим:
Опять же на вкус и цвет товарищей нет. Мне нравится когда в больших или малых условиях они выделены в скобки. Глаз сразу выдирает их.
Без скобок начинается потеря быстрого восприятия.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
IT>>И чем они полезны? Ух, аж в глазах рябит. Сравни лучше вот с этим:
S> Опять же на вкус и цвет товарищей нет. Мне нравится когда в больших или малых условиях они выделены в скобки. Глаз сразу выдирает их. S> Без скобок начинается потеря быстрого восприятия.
Хочешь устроить голосование — Лишние скобки против выравнивания столбиком?
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Соглашения по оформлению кода команды RSDN
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, alku, Вы писали:
AVK>>>Найдем если будут нормальные аргументы, а не я привык или на одно нажатие на кнопочку меньше. A>>in bold — кстати очень серьезный аргумент если вдуматься — повышыние скорости работы, а потом как рефлекс...
IT>А если ещё более серьёзно вдуматься, то вот такой вообще немеряно повышает скорость работы:
IT>
IT>public class MyClass:ClassBase{public MyClass(int param):base(param){_param=param}public int Param{{get{return _param;}set{_param=value}}}
IT>
вот любите вы палку прегинать... если вдуматься — то надо думать гы...
тут и идиоту будет понятно что читать такое не удобно...
говорю же что надо балансировать на гранях:
— удобство
— компактность
— читабильность
— елегантность
если хотя бы по этим граням правило проходит, то его стоит расматривать.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Serginio1, Вы писали:
IT>>>И чем они полезны? Ух, аж в глазах рябит. Сравни лучше вот с этим:
S>> Опять же на вкус и цвет товарищей нет. Мне нравится когда в больших или малых условиях они выделены в скобки. Глаз сразу выдирает их. S>> Без скобок начинается потеря быстрого восприятия.
IT>Хочешь устроить голосование — Лишние скобки против выравнивания столбиком?
и что голосование покажет? то что половина девелоперов предпочитает один стиль от другого?!
тут мотивации сравнить надо, а не на глаз приятно или нет.
Здравствуйте, alku, Вы писали:
A>а я не говорю что у нас правил нету... они есть, но не на бумаге.
А вот это очень плохо. Вы как новичкам правила объясняете, на пальцах?
A> и самое главное что команда их сама выработал за три дня...
И у нас тоже команда выработала.
A>а то глянул в код другого проекта страшно стало, все методы в трай кетчах, проверок на входные параметры нету, лоигка лееров размыта...
К правилам кодирования это отношения не имеет, это уже ошибки дизайна и некачественная реализация.
A>Offtopic: очень не порадовало что почти все "решения" очень рекламируешеся для NET от майкрософт оказались не очень состоятельны для большого проекта. где вылизли огромные потребления по памяти, где по перфомансу пролет...
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alku, Вы писали:
A>>а я не говорю что у нас правил нету... они есть, но не на бумаге.
AVK>А вот это очень плохо. Вы как новичкам правила объясняете, на пальцах?
хуже у нас очень распространнен екстрим програминг... первую неделю кто-то сидит с человеком и ему объясняет правила... в основном за неделю новый человек начинает догонять что к чему... вот только времени это жрет немало... документ должен слегка поправить такую ситуацию. и не все хорошо правила с бумаги воспринимают, а так сразу практическое приминение. некоторый буст (boost) у людей замечен даже. ну и это еще очень зависит от стремительности проекта... есле человека в проект две недели вводить мона, то тогда и бумага сойдет.
A>> и самое главное что команда их сама выработал за три дня... AVK>И у нас тоже команда выработала.
осталось только на бумагу записать.. но я решил сначало порыть в инете и посмотреть кто и как код форматит, а потом уже писать... может я что новое найду , а может и не найду.
A>>а то глянул в код другого проекта страшно стало, все методы в трай кетчах, проверок на входные параметры нету, лоигка лееров размыта...
AVK>К правилам кодирования это отношения не имеет, это уже ошибки дизайна и некачественная реализация.
имеет но косвенное... самое хреновое что на проекте состав меняли и от первоначального состава только менеджер и остался... а новому тиму которому надо за короткие сроки вернуть проект к жизне приходиться тяжко. вот и хочу что бы в будущем хотябы часть работы и "отторжения" была отстрелена...
A>>Offtopic: очень не порадовало что почти все "решения" очень рекламируешеся для NET от майкрософт оказались не очень состоятельны для большого проекта. где вылизли огромные потребления по памяти, где по перфомансу пролет...
AVK>Не знаю, у нас все прилично.
я же говорил что зависит от того как юзать... "...за державу обидно..."(с)"Белое солнце пустыни"
Re[13]: Соглашения по оформлению кода команды RSDN
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alku, Вы писали:
AVK>>>Найдем если будут нормальные аргументы, а не я привык или на одно нажатие на кнопочку меньше. A>>in bold — кстати очень серьезный аргумент если вдуматься — повышыние скорости работы, а потом как рефлекс... A>>это все сказываеться на том как эфективно програмист может использовать IDE и следовательно сколько он времени тратит на перевод своего "фокуса" с кода на утилитарные действия... еффект как от печати на клаве в слепую. скорость повышаеться.
AVK>Я в свое время писал на паскале с его begin/end. Так вот — лично для меня производительность от количества буковок в процедурных скобках нее зависит вобще никак. На собственно набор текста на клавиатуре уходит очень мало времени. Если же начинает уходить много то это повод задуматься над тем все ли правильно в дизайне.
не до конца ты прав... это может означать что человек точно знает что надо сделать и ему довольно мало нужно времени на обдумвание... иногда такое называют "механикой" — думая что это просто набор действий может делать любой автомат, а у девелопера со стажем это уже "автоматом" идет применение патернов, шаблонов кодирования и т.д.
процес очень похож на печатанье в слепую... руки делают, а голова только шалоны подставляет
Re[14]: Соглашения по оформлению кода команды RSDN
Здравствуйте, alku, Вы писали:
A>не до конца ты прав... это может означать что человек точно знает что надо сделать и ему довольно мало нужно времени на обдумвание...
Нееее. Тут то и засада. Если не нужно время на обдумывание значит интеллектуальная наполненность кода низкая, а значит крайне высоки шансы путем автоматизации существенно этот код подсократить. Не знаю конечно что у тебя за задачки, но как только начинал ощущать что я пишу много несложного кода то всегда удавалось просто выкинуть этот код к черту и заменить на автоматику.
A>процес очень похож на печатанье в слепую... руки делают, а голова только шалоны подставляет
Вот вот, рутинная работа бестолкового автомата. О том и речь.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alku, Вы писали:
AVK>>>А вот это очень плохо. Вы как новичкам правила объясняете, на пальцах?
A>>хуже у нас очень распространнен екстрим програминг...
AVK>Предположу что спецификой вашей конторы является большое число относительно небольших проектов, а не два-три крупных. Исходя из этого становится понятно почему для вас отсутствие общепринятого стиля или частые его изменения не являются смертельными.
почему есть и крупные, но на NET пока крупных сильно нету, фирма то большая... проектов много...
основные проекты на с++ пишуться + Delphi... щас вот Веб сильно идет...
а все остальное в масштабах основных проектов дествительно мелковато смотриться.
щас больше восьми "глобальных" напрвалений/проектов которые на фирме развиваються паралельно...
а народ то один и тотже... поэтому часто случаються перестановки между тимами и проектами.
на новых направлениях стараемся опробовать "новые" методики работы аля екстрим программинг (в урезаном виде) и т.д.
звучит жизне-утверждающе
A>>>> и самое главное что команда их сама выработал за три дня... AVK>>>И у нас тоже команда выработала.
A>>осталось только на бумагу записать..
AVK>А мы записали . Не на бумагу правда, а в VSS.
все там будем
A>>>>Offtopic: очень не порадовало что почти все "решения" очень рекламируешеся для NET от майкрософт оказались не очень состоятельны для большого проекта. где вылизли огромные потребления по памяти, где по перфомансу пролет...
AVK>>>Не знаю, у нас все прилично.
A>>я же говорил что зависит от того как юзать...
AVK>В смысле у вас хреново юзают или что?
в смысле людей жалко, что из-за одного хренового менеджера проект подставили и людей на нем.
это из разряда "заставь дурака богу молиться так он и лоб расшибет".
полюбому менеджерами не рождаютсяь ими становяться... но это лирика...
главное что там такого бы бардака не было если бы со старта нормально за дело взялись... но и это лирика...
Re[15]: Соглашения по оформлению кода команды RSDN
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alku, Вы писали:
A>>не до конца ты прав... это может означать что человек точно знает что надо сделать и ему довольно мало нужно времени на обдумвание...
AVK>Нееее. Тут то и засада. Если не нужно время на обдумывание значит интеллектуальная наполненность кода низкая, а значит крайне высоки шансы путем автоматизации существенно этот код подсократить. Не знаю конечно что у тебя за задачки, но как только начинал ощущать что я пишу много несложного кода то всегда удавалось просто выкинуть этот код к черту и заменить на автоматику.
а иногда просто требуеться много рутины... на примере: ты пробовал по человечески подключить контрол к студии IDE??? так чтобы и сериализация и локализация и т.д. и т.п. — куча кода с низким "смысловым" содержанием... а все для того чтобы студия нормально какую-то фичу воспринимала... слегка преувеличиваю... сначала всегда на проекте рутина, а логика и работа остаеться на потом... (но это сильно зависит от профиля в котором работаеш... на некоторых проектах народи груды багов разгребает, в других тоны кода пишет, в третьих одним "балобольством" занимаеться и т.д.) для проектов характерно что сначало пишеться движек, а потом на него начинает навинчиваться логика... но до этого надо написать движек, а это куча враперов, стореджей, интерфейсов и т.д. а вот в момент когда пойдет логика, тогда написаное ранее в основном читатеться и тогда надо чтобы было все понятно и однотипно.
A>>процес очень похож на печатанье в слепую... руки делают, а голова только шалоны подставляет
AVK>Вот вот, рутинная работа бестолкового автомата. О том и речь.
"палка по двух концах"...
Re[12]: Соглашения по оформлению кода команды RSDN
Здравствуйте, alku, Вы писали:
A>а иногда просто требуеться много рутины... на примере: ты пробовал по человечески подключить контрол к студии IDE???
Дотнетовский пробовал и не раз (и даже не два ). Рутины не обнаружил.
A> так чтобы и сериализация и локализация и т.д. и т.п. — куча кода с низким "смысловым" содержанием...
Почему низким? Там же все практически декларативно, по сути чистые данные без лишних примесей.
A> а все для того чтобы студия нормально какую-то фичу воспринимала...
Почему именно студия? ComponentModel она общая, не только в студии работает.
A> слегка преувеличиваю... сначала всегда на проекте рутина, а логика и работа остаеться на потом...
Ну не знаю, у меня обычно вначале все очень непросто, а уж потом настает рутина. Ты наверное много гуя пишешь? Но там тоже есть подходы, если хорошо попотеть вначале.
A>для проектов характерно что сначало пишеться движек, а потом на него начинает навинчиваться логика... но до этого надо написать движек, а это куча враперов, стореджей, интерфейсов и т.д.
Ну это как писать . В дотнете по крайней мере надобность во врапперах возникает не очень часто, да и автоматизировать это тоже можно.
A> а вот в момент когда пойдет логика, тогда написаное ранее в основном читатеться и тогда надо чтобы было все понятно и однотипно.
Странный подход. Я бы для начала потренировался на кошках и реализовал логику, убедился что она работает, померил бы количественные характеристики, а потом начал писать окружение. Это если логика нетривиальная.
Здравствуйте, mihailik, Вы писали:
M>>>Понты.
A>> A>>Опыт...
M>И это понты. Ты считаешь, мы здесь книжек не читаем? И неопытные совсем?
M>Этот как еда. Можно много похавать, а можно с пользой для здоровья. Когда знания порождают понты, это как выхлопные газы после большого обеда.
Точно. Кстати сказать, твой пост тоже ничем от понтов не отличается. Везде сплошные понты
Если нам не помогут, то мы тоже никого не пощадим.
Re[13]: Соглашения по оформлению кода команды RSDN
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alku, Вы писали:
A>>на новых направлениях стараемся опробовать "новые" методики работы аля екстрим программинг (в урезаном виде) и т.д.
AVK>Не рекомендую пробовать на крупных проектах, разве что очень отдельные вещи вроде юнит тестирования.
юнит тестинг как раз и прежился... парный программинг не очень, только на стартовом этапе.
Re[17]: Соглашения по оформлению кода команды RSDN
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alku, Вы писали:
A>>а иногда просто требуеться много рутины... на примере: ты пробовал по человечески подключить контрол к студии IDE???
AVK>Дотнетовский пробовал и не раз (и даже не два ). Рутины не обнаружил.
A>> так чтобы и сериализация и локализация и т.д. и т.п. — куча кода с низким "смысловым" содержанием... AVK>Почему низким? Там же все практически декларативно, по сути чистые данные без лишних примесей.
на десяток пропертей иногда приходиться декларить десяток ShouldSerailize, десяток ивентов "Property changed", потом еще десяток виртуальных методов аля On<PropertyName>Changed( EventArgs e ) и т.д. рутина и мона делать по шаблону.
A>> а все для того чтобы студия нормально какую-то фичу воспринимала... AVK>Почему именно студия? ComponentModel она общая, не только в студии работает.
рабатаю я в основном со студией потому и примеры о ней.
A>> слегка преувеличиваю... сначала всегда на проекте рутина, а логика и работа остаеться на потом...
AVK>Ну не знаю, у меня обычно вначале все очень непросто, а уж потом настает рутина. Ты наверное много гуя пишешь? Но там тоже есть подходы, если хорошо попотеть вначале.
все зависит от задачи... если писать бизнес прогу, то там дествительно проблемы с начальной архитектурой, и по мере работы про систему становиться ясно все больше и больше, а вот например для компонентов?! — для них характерно что сначало известна логика и надо под нее сделать хорошую архитектуру, а потом ее постоянно расширять (ну или типо того)
A>>для проектов характерно что сначало пишеться движек, а потом на него начинает навинчиваться логика... но до этого надо написать движек, а это куча враперов, стореджей, интерфейсов и т.д.
AVK>Ну это как писать . В дотнете по крайней мере надобность во врапперах возникает не очень часто, да и автоматизировать это тоже можно.
возникает... но это уже я автоматизнул по-этому занимает минуты три...
A>> а вот в момент когда пойдет логика, тогда написаное ранее в основном читатеться и тогда надо чтобы было все понятно и однотипно.
AVK>Странный подход. Я бы для начала потренировался на кошках и реализовал логику, убедился что она работает, померил бы количественные характеристики, а потом начал писать окружение. Это если логика нетривиальная.
если заранее известна архитектура или логика продумана, то отподает надобнасть в "кошках" говорю же от проекта зависит в реальной проге для пользователя логика не известна почти до середины проекта, а потом начинаеться геморой в плане не удачное решение, тут прийдеться через зад выкручиваться и т.д. а все от того что нету достаточно полной информации на начальном этапе проектирования. (но не всегда)
Re[11]: Соглашения по оформлению кода команды RSDN
возможно опечатки:
секция "поля" комментарий "надо так" возможно пропущена ";"
секция "комментарии" ссылка "XML documentation-комментарии" поврежденная.
теперь вопрос: есть ли официальные рекомендации по оформлению кода и документации к нему?
хотелось бы почитать не только от Microsoft, но и, к примеру, от GNU. можно на английском.
wrote in message news:611887@news.rsdn.ru... > теперь вопрос: есть ли официальные рекомендации по оформлению кода и документации к нему? > хотелось бы почитать не только от Microsoft, но и, к примеру, от GNU. можно на английском.
От GNU для C# конечно ничего нет
Posted via RSDN NNTP Server 1.8 beta
Re[3]: Соглашения по оформлению кода команды RSDN
От:
Аноним
Дата:
22.04.04 17:24
Оценка:
Здравствуйте, Воронков Василий, Вы писали:
ВВ>От GNU для C# конечно ничего нет
я имел в виду по Си/Си++
Re[13]: Соглашения по оформлению кода команды RSDN
вообще-то вроде всё это было разработано 'RSDN Team' и вероятнее для 'RSDN Team'.
Но на скромные 'наезды' был дан ЖЕСТОКИЙ отпор.
Победа за 'RSDN Team', они никого не пощадили.
... << RSDN@Home 1.1.2 stable >>
Re[14]: Соглашения по оформлению кода команды RSDN
Здравствуйте, KGP, Вы писали:
KGP>вообще-то вроде всё это было разработано 'RSDN Team' и вероятнее для 'RSDN Team'. KGP>Но на скромные 'наезды' был дан ЖЕСТОКИЙ отпор. KGP>Победа за 'RSDN Team', они никого не пощадили.
А ты думал?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Соглашения по оформлению кода команды RSDN
Что означает непубличные поля? Это не содержащие public или именно перечисленые в статье "private, protected и protected internal". Просто internal куда отнести?
Здравствуйте, beretta, Вы писали:
B>Что означает непубличные поля? Это не содержащие public или именно перечисленые в статье "private, protected и protected internal". Просто internal куда отнести?
Общая идея такая... Если поле используется вместо свойства, т.е. для предоставления публичного (для других программистов) доступа, то оно оформляется как свойство. Если это некое техническое поле используемое в целях оптимизации и т.п., то оформляется как непубличное.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2!, Вы писали :
V> Общая идея такая... Если поле используется вместо свойства, т.е. для V> предоставления публичного (для других программистов) доступа, то оно V> оформляется как свойство. Если это некое техническое поле V> используемое в целях оптимизации и т.п., то оформляется как V> непубличное.
А в контексте private _myField; Т.е. в соглашении для полей написано, что их следует помечать префиксом _ для непубличных, так вот в статье как непубличные помечены private, protected и protected internal. И тут вопрос, считать непубличными перечисленные в статье или все не public, есть ведь еще просто internal.
.: Быстро делаются только злые дела (принц Флоризель) :.
Здравствуйте, beretta, Вы писали:
B>А в контексте private _myField; Т.е. в соглашении для полей написано, что их следует помечать префиксом _ для непубличных, так вот в статье как непубличные помечены private, protected и protected internal. И тут вопрос, считать непубличными перечисленные в статье или все не public, есть ведь еще просто internal.
Мне кажется я уже ответил на этот вопрос. Попробую еще раз. Если internal поле используется для внутренних нужд (как то скрытой связи между объектами), то форматировать его нужно как скрытое. Если оно преднозначено для использования другими программистами (частого использования), то как публичное.
Если ты о своих инспекторах, то как задавать ему человеческую логигу мне не очень ясно.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали :
V> Если ты о своих инспекторах, то как задавать ему человеческую логигу V> мне не очень ясно.
А просто, какой смысл указывать internal если не для внутренних связей, т.е. поле internal без связи между классами в сборке — глюк. Только глюк из другой оперы.
.: Успевает всюду тот, кто никуда не торопится. / Филип Филипович / :.
Здравствуйте, beretta, Вы писали:
B>А просто, какой смысл указывать internal если не для внутренних связей, т.е. поле internal без связи между классами в сборке — глюк. Только глюк из другой оперы.
Ну, предположим, ты сделал переменную которую потом будем юзать я, Воронков, АВК...
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Соглашения по оформлению кода команды RSDN
От:
Аноним
Дата:
05.07.04 07:27
Оценка:
A>>
A>>if( const == something )
A>>
O>Аналогично в русском языке (это я привёл пример, как по-моему), пробел ставится перед скобкой, а не после( как в твоём примере ). Ну, и как удобнее читать?
Непубличные поля (private, protected и protected internal) именуются в стиле Кэмел и начинаются с префикса _.
А вот пример кода из этой же статьи:
public class MouseEventArgs : EventArgs
{
private int x;
private int y;
public MouseEventArgs(int x, int y)
{
this.x = x;
this.y = y;
}
public int X { get { return x; } }
public int Y { get { return y; } }
}
Я конечно понимаю, что это не ваш код, но всё равно стоит исправить.
BTW приведенный в примере вариант мне нравится гораздо больше, чем ваш, с подчеркиванием. Имхо, изнутри класса нет смысла различать с каким полем мы работаем — с приватным или публичным. Гораздо важнее просто знать что это именно поле класса, а для этого лучше уж "this." везде писать — через пару дней практики руки сами начинают это слово мгновенно набивать.
Кстати, если уж вводить подчеркивание для приватных членов класса, то почему только для полей, чем методы провинились?
Здравствуйте, eugals, Вы писали:
E>BTW приведенный в примере вариант мне нравится гораздо больше, чем ваш, с подчеркиванием. Имхо, изнутри класса нет смысла различать с каким полем мы работаем — с приватным или публичным. Гораздо важнее просто знать что это именно поле класса, а для этого лучше уж "this." везде писать — через пару дней практики руки сами начинают это слово мгновенно набивать.
Использование подчеркивания в имени приватного члена класса помогает не спутать его с соответствующим ему свойством. Если имена члена класса и его акцессора отличаются только регистром (а это вполне обычная ситуация), то перепутать достаточно несложно. Особенно, когда тебе помогает интеллисенс.
Здравствуйте, Андрей Майоров, Вы писали:
АМ>Здравствуйте, eugals, Вы писали:
АМ> Использование подчеркивания в имени приватного члена класса помогает не спутать его с соответствующим ему свойством. Если имена члена класса и его акцессора отличаются только регистром (а это вполне обычная ситуация), то перепутать достаточно несложно. Особенно, когда тебе помогает интеллисенс.
Далеко (очень далеко) не каждому приватному полю соответствует публичная проперть.
Потому, что не красив
Непонятно к чему ты эти скобки хочешь больше отнести к DoSomething(), или к if?
А когда при чтении кода возникают вот такие вопросы это плохо.
Здравствуйте, GregZ, Вы писали:
GZ>И теперь возникают?
конечно GZ>Если да, то только вследствии костности мышления.
нет, это похоже ты ни как неможешь поверь в то, что так как ты ставишь скобки никто не ставит GZ>Никаких объективных причин ставить фигурные скобки так, как предлагает статья я не вижу.
А я в твоем примере вообще не вижу причины ставить скобки
P.S.
Можешь ставить скобки так как тебе хочеться, если ты работаешь один, а если ты работаешь в команде, то тебя думаю будут бить.
Здравствуйте, V.Petrovski, Вы писали:
GZ>>Если да, то только вследствии костности мышления. VP>нет, это похоже ты ни как неможешь поверь в то, что так как ты ставишь скобки никто не ставит
Ставит. В частности в реализации STL, идущей вместе с VS .NET.
GZ>>Никаких объективных причин ставить фигурные скобки так, как предлагает статья я не вижу. VP>А я в твоем примере вообще не вижу причины ставить скобки
Пример надуман. И служит лишь для демонстрации вопроса.
VP>P.S. VP>Можешь ставить скобки так как тебе хочеться, если ты работаешь один, а если ты работаешь в команде, то тебя думаю будут бить.
Для работы в команде единый стиль программирования не роскошь, а прямая необходимость.
Никто с этой истиной спорить не собирается.
Мой вопрос был вызван лишь непонимание факта занесения примера форматирования в раздел "не верно".
Здравствуйте, GregZ, Вы писали:
GZ>Для работы в команде единый стиль программирования не роскошь, а прямая необходимость. GZ>Никто с этой истиной спорить не собирается. GZ>Мой вопрос был вызван лишь непонимание факта занесения примера форматирования в раздел "не верно".
Занчит вся команда RSDN решила, что такой вариант растановки скобок не верен.
Здравствуйте, V.Petrovski, Вы писали:
VP>Занчит вся команда RSDN решила, что такой вариант растановки скобок не верен.
Вопрос был: Почему такой стиль оформления фигурными скобками считается не верным.
Здравствуйте, GregZ, Вы писали:
GZ>Почему такой стиль оформления фигурными скобками считается не верным. GZ>Было бы очень интересно узнать.
По правилам. Не нравятся такие — можешь внедрить другие правила (у себя в команде).
... << RSDN@Home 1.1.4 beta 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
GZ>>Почему такой стиль оформления фигурными скобками считается не верным. GZ>>Было бы очень интересно узнать. S>По правилам. Не нравятся такие — можешь внедрить другие правила (у себя в команде).
ok.
На мой взгляд оба способа расстановки фигурных скобок абсолютно равнозначны и имеют
право на существование. Я уважаю чужое мнение и работая в команде безоговорочно одобрил
бы принятые в ней правила оформления исходного кода.
Задавая вопрос, я неосмотрительно полагал, что автор(ы) отметали другие стили оформления
не просто потому, что они им не нравятся, или несколько непривычны.
Жаль что это не так...
В целом статья же достаточно удачна и информативна, даже для программиста на С++,
коим ваш покорный слуга и является.
GZ>Почему такой стиль оформления фигурными скобками считается не верным. GZ>Было бы очень интересно узнать.
Потому что нужно было выбрать один. И так как предложенный тобой почти для всей команды был экзотикой, то останавились на том что в документе. К тому же это соотвествует правилам принятым в МСДН для шарпа.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GregZ, Вы писали:
GZ>Ставит. В частности в реализации STL, идущей вместе с VS .NET.
Кстати, замечательный пример почти не читаемого кода.
GZ>Мой вопрос был вызван лишь непонимание факта занесения примера форматирования в раздел "не верно".
А завтра прийдет орел который спросит почему такой стиль не верен:
if (xxx) {
aaa();
}
а послезавтра такой:
if (xxx)
{
aaa(); }
не разрешать же их все. Был выбран единый, которым пользуется большинство.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GregZ, Вы писали:
GZ>На мой взгляд оба способа расстановки фигурных скобок абсолютно равнозначны и имеют GZ>право на существование. Я уважаю чужое мнение и работая в команде безоговорочно одобрил GZ>бы принятые в ней правила оформления исходного кода. GZ>Задавая вопрос, я неосмотрительно полагал, что автор(ы) отметали другие стили оформления GZ>не просто потому, что они им не нравятся, или несколько непривычны. GZ>Жаль что это не так...
Авторы отметали другие стили, чтобы их небыло в одном коде. Читать код в котором меняется стиль форматирования крайне сложно. Нужно было выбрать один из пары десятков вариантво. Выбрали этот. Почему? На этот вопрос тебе уже ответели не раз.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Потому что нужно было выбрать один. И так как предложенный тобой почти для всей команды был экзотикой, то останавились на том что в документе. К тому же это соотвествует правилам принятым в МСДН для шарпа.
Здравствуйте, VladD2, Вы писали:
VD>Авторы отметали другие стили, чтобы их небыло в одном коде. Читать код в котором меняется стиль форматирования крайне сложно.
Абсолютно согласен.
VD>Нужно было выбрать один из пары десятков вариантво. Выбрали этот. Почему? На этот вопрос тебе уже ответели не раз.
Заметьте, я не предлагал использовать при форматировании все отвергнутые вами _десятки_вариантов_.
Всего лишь интересовался причиной негативного отношения к конкретному варианту расстановки фигурных скобок.
Спасибо, Ваш ответ я понял.
Здравствуйте, GregZ, Вы писали:
GZ>Всего лишь интересовался причиной негативного отношения к конкретному варианту расстановки фигурных скобок.
Нет никакого негативного отношения. Просто все что не соотвествует стилю выбранному большинством считается неправильным, просто потому что введена монополия на описание.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
У меня есть вопрос по именованию непубличных полей.
>Непубличные поля (private, protected и protected internal) именуются в стиле Кэмел и начинаются с префикса _.
В то же самое время сам Microsoft запрещает использование этго префикса. Это, конечно, относится для тех, кто пишет Class Library, но кто знает во что выльется каждая библиотека, разработанная в рамках проектов RSDN.
BT>В то же самое время сам Microsoft запрещает использование этго префикса. Это, конечно, относится для тех, кто пишет Class Library, но кто знает во что выльется каждая библиотека, разработанная в рамках проектов RSDN.
"Соглашения по оформлению кода команды RSDN" — где ты здесь микрософт увидел?
Микрософт дает ничего не запрещает и не разрешает. Он дает рекомендации. А твое право этими рекомендациями пользоватся или нет. В большинстве случаев соглашение РСДН совпадает с рекомендациями Микрософт. Но вот в случае с приватными переменными несовпало
Здравствуйте, Andre, Вы писали:
A>Микрософт дает ничего не запрещает и не разрешает. Он дает рекомендации. А твое право этими рекомендациями пользоватся или нет. В большинстве случаев соглашение РСДН совпадает с рекомендациями Микрософт. Но вот в случае с приватными переменными несовпало
А разве в Class Developers Guide указывается стиль именования приватных переменных? Где то в другом месте я видел рекомендацию не использовать префиксы, но никоим образом не запрет.
AVK>А разве в Class Developers Guide указывается стиль именования приватных переменных?
Да я ошибся. Там только есть рекомендации про регистр.
AVK>Где то в другом месте я видел рекомендацию не использовать префиксы, но никоим образом не запрет.
Я наверное тоже спутал с этим "другим местом". Про запреты это не ко мне. Я наоборот хотел подчеркнуть что все имеет рекомендательный характер.
... << RSDN@Home 1.1.4 :: rev. 205 >> :: Технология — Нажми на кнопку
RT>Этот документ описывает единый стиль кода, разработанный командой RSDN. В первую очередь он предназначен для использования в проектах, ведущихся в рамках RSDN. Надеемся, что этот стиль будет полезен всем тем, кто так же ищет удобный единый стиль форматирования исходного кода.
Вот тут положил файл настроек для MSVS 2005, удовлетворяющий (если я нигде не наврал) соглашениям.
Вопрос: верно ли я понимаю, что сдедующие куски кода оформлены в соответствии с соглашениями? Если нет, то почему?
foreach(object o in items) // внутри for-а один if-elseif(condition) // со "сложным" if-ом "простой" else
{
int a = 0;
a++;
a++;
a++;
a++;
a++;
}
else
bla-bla-bla;
Help will always be given at Hogwarts to those who ask for it.
Re: Соглашения по оформлению кода команды RSDN
От:
Аноним
Дата:
02.06.08 08:43
Оценка:
Здравствуйте, RSDN Team, Вы писали:
Здравствуйте, объясните пожалуйста что такое lightweight поля, что под этим имеется ввиду в данной статье?