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

R3>>Почему?
R3>>

Не используйте специальных префиксов, поясняющих, что это класс. Например, FileStream, а не CFileStream.

А>Возможно потому, что это версия для C#, а народ в C# приходит в том числе и из C++.

А разве там советовали не использовать это?

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

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

R3>>>Почему?
R3>>>

Не используйте специальных префиксов, поясняющих, что это класс. Например, FileStream, а не CFileStream.

А>>Возможно потому, что это версия для C#, а народ в C# приходит в том числе и из C++.

R3>А разве там советовали не использовать это?

Насколько мне известно в C++ эти префиксы в порядке вещей, в C# актуальность в них отпадает. На твой вопрос "Почему? Не используйте специальных префиксов...", вероятно акцент сделан для C++ -ников, пришедших в C#.

Здравствуйте, 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>ждемс

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

O>>Потому что поиск по слову BUG (и даже BUG:) срабатывает на DEBUG и на (DEBUG:).

S> Кстати — на взять на вооружение!

возьми лучше на вооружение task view из студии — в опциях настраиваються ключивые слова

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

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

O>>>Аналогично в русском языке (это я привёл пример, как по-моему), пробел ставится перед скобкой, а не после( как в твоём примере ). Ну, и как удобнее читать?

A>>тут хочу поспорить... зачем равнять искуственный язык програмирования с языком разговорным/письменным?! у них разные цели...

A>Это для нас, не англоязычных, он "искусственный", а для англоязычных он самый что-ни-на-есть естесственный. Они программы пишут, что говорят. И в этом я им завидую...

переходи на 1с там говорят на русском писать мона...

а вообще мне не понравилось бы если вместо привычных операторов мне пришлось бы писать на русском код... бррр... как подумаю аж в дрожь бросает...

A>еще одна фича:

A>кто смотрел код от макрософта рефлектором должен был заметить как именуються мемберы классов!!! они все начинаються с m_... странно это очень... в своем стиле они пишут что так не надо делать и тутже смотрим на код и видим что все там не так...

A>может просто существует два старндарта? один для юзеров другой для внутренних рабочих?

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

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

A>а вообще мне не понравилось бы если вместо привычных операторов мне пришлось бы писать на русском код... бррр... как подумаю аж в дрожь бросает...
Это ты еще на славном языке "Рапира" не писал... Грамотный, кстати, был язык, этакий Паскаль по русски...

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

A>проше отслеживать изминения кода по сорсафе и потом раздавать тумаки за нарушение правил, но такое для больших фирм по моему не будет работать... а для команды до 10 человек очень даже работает... только менеджеру приходиться туго на первых порах. через месяц вся команда уже нормально пашет в установленных правилах и нагрузка на менджера спадает... главное только объяснять каждому почему есть такое правило и что за ним стоит.
За ним стоит очередь безработных девелоперов которые с удовольствием поисполняют правила.
A>не обоснованных правил девелопер исполнять не будет

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

A>>а вообще мне не понравилось бы если вместо привычных операторов мне пришлось бы писать на русском код... бррр... как подумаю аж в дрожь бросает...
M>Это ты еще на славном языке "Рапира" не писал... Грамотный, кстати, был язык, этакий Паскаль по русски...

Представляю: указатель — стрела, переменная — ванька-встанька, класс — замок, тип — род.

В Замке зМосква делаем стрелу в ваньку-встаньку ввИван, рода рЧеловеческого.

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

A>повторюсь:
A>- для этих целей очень подходит расцветка... и сразу становиться видно где метод, а где ключевое слово... исключение составлеяет просмотр исходников редактором не приспособленным для работы с ними... аля notepad

Вот ты сам все и объяснил.

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

AVK>>А зачем выполнять работу компилятора? Он и так неплохо отследит, да и студия подсветит.

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

У тебя позиция пробела влияет на твое подуманье перед тем как напишешь код? Однако.

AVK>>В данном случае одинаковая

A>на один символ больше

На один меньше. Внутри скобок 2 пробела, после оператора только 1.

A>я уже привык выхватывать на экране не только ключивые слова, но и конструкции в целом...

Ну тогда извини. Я вот тоже так писал, но потом переучился. В итоге с пробелом все таки получше.

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

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

A>>проше отслеживать изминения кода по сорсафе и потом раздавать тумаки за нарушение правил, но такое для больших фирм по моему не будет работать... а для команды до 10 человек очень даже работает... только менеджеру приходиться туго на первых порах. через месяц вся команда уже нормально пашет в установленных правилах и нагрузка на менджера спадает... главное только объяснять каждому почему есть такое правило и что за ним стоит.
S>За ним стоит очередь безработных девелоперов которые с удовольствием поисполняют правила.
A>>не обоснованных правил девелопер исполнять не будет

не знаю как у вас а у нас дефецит девелоперов

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

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

A>>повторюсь:
A>>- для этих целей очень подходит расцветка... и сразу становиться видно где метод, а где ключевое слово... исключение составлеяет просмотр исходников редактором не приспособленным для работы с ними... аля notepad

AVK>Вот ты сам все и объяснил.

но это же смешно... кто щас в здравом уме смотрит исходники notepad??? хотя бы Far + colorer...

так что думаю это ничего не объясняет, а на оборот усложняет форматирование...

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

например:
само по себе мне слово if не инетересно, намного интереснее его условие! следовательно должно быть выделено условие, а не ключевое слово... ключевое слово в таком контексте играет второстепенную роль. такое практически работает на все киворды, за редким исключением. (хотя не совсем верно — сначало должна пройти стадия распознования киворда, потом стадия сопостовления в которой человек решает что важного есть в такой языковой конструкции, а потом идет анализ этой важной состовляющей... но при должной практике такой процес проходит практически автоматом и распознование кивордов уходит на второй план...)

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

в чем проблема всех стандартов?! на момент написания они морально устаревают и около 30% написаного в них теряет свою актуальность... вот как раз расчитывать на то что код будут смотреть notepad'ом и есть морально устаревшие 30%...

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

Здравствуйте, alku, Вы писали:
A>не знаю как у вас а у нас дефецит девелоперов
Это где такое?

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

S>Здравствуйте, alku, Вы писали:
A>>не знаю как у вас а у нас дефецит девелоперов
S>Это где такое?

Украина, Львов

Здравствуйте, alku, Вы писали:
A>Украина, Львов
Нифига себе. Никогда бы не подумал. У нас так в основном дефицит квалифицированных девелоперов за мелкие деньги Ну, так это везде так — читаем Спольски.

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

VD>>То-то я смотрю в ядре Линукса чет ногу сломит. Значит это были происки наших аноноимов.

А>Без перехода на личности никак?

Не. Никак скорее без юмора.

А>>>Ты хотя бы попытайся оторваться от своих привычек и посмотреть на то, как выглядят эти две переменные _непредвзято_.

VD>>Шутку понял, смешно. (с)

А>Т.е. даже не попытался.

Т.е. ты сам оторваться не хочешь, но считаешь себя правым.