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

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

у нас даже за "нормальные" деньги перекупить тяжко... конкуренция плюс планка знаний для поступления достаточно высокая....

ну с москвой равнять не буду... от города и региона сильно зависит зарплата и возможности... в москве для програмера наверно 1000 баксов "очень средняя" (в плане маленькая) зарплата...

а если студентов брать так с ними мороки куча, месяц как минимум за студентом с "горшком" ходить будеш, это если самому работой не заниматься...

Здравствуйте, alku, Вы писали:
A>у нас даже за "нормальные" деньги перекупить тяжко... конкуренция
Что ж, буду знать, куда ломиться. У вас рабочую визу получить легко?
A>плюс планка знаний для поступления достаточно высокая....

A>ну с москвой равнять не буду... от города и региона сильно зависит зарплата и возможности... в москве для програмера наверно 1000 баксов "очень средняя" (в плане маленькая) зарплата...
Ну, у нас за такие деньги можно очень даже выбирать. Тут куда ни плюнь — попадешь в программера. А заказчиков как-то намного меньше.

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

R3>Ну так есть же русифицированные языки программирования.

Это всё не то. Потому как основано на грамматике и пр. особенностях других языков. На них на всех лежит тень совместимости с английским...

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

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

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

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

Это уже есть, потому как появилась привычка, и понимание правил другого разговорного языка. Увы, не мы изобрели процессор...

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

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

A>>у нас даже за "нормальные" деньги перекупить тяжко... конкуренция
S>Что ж, буду знать, куда ломиться. У вас рабочую визу получить легко?

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

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

A>>ну с москвой равнять не буду... от города и региона сильно зависит зарплата и возможности... в москве для програмера наверно 1000 баксов "очень средняя" (в плане маленькая) зарплата...

S>Ну, у нас за такие деньги можно очень даже выбирать. Тут куда ни плюнь — попадешь в программера. А заказчиков как-то намного меньше.

от москвы у нас зарплаты в два раз меньше будут... но жить дешевле: еда + квартира + по мелочам...
вообще-то надо просто на фирмы "большие" поступать — будет и работа и деньги и все что поплдолжено
спецу работу найти довольно просто...

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

R3>Почему?
R3>

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

Так решили ребята писавшие FCL. Если это не соблюдать то классы будут резко отличаться от классов FCL. Однако это всего лишь правило. Иногда куда выгодее ввести префикс. Например, они могу оказаться нужны если имеются классы с аналогичным разванием и эти классы часто испошьзуются совместно со своими.

Кстати, МС и сам это правило иногда нарушает. Например, все классы CodeDom имеют префикс Code.

Здравствуйте, 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>я пытаюсь написать документ который просто и банально решит такой вопрос — аля корпоративный стандард на оформление кода. в него кстатит должны войти правила по оформлению и безопасности кода... как только напишеться документ обязательно постараюсь поделиться с общественностью.

Ну, тогда проще взять наш. Он проверен на практике...

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

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

Это вряд ли.

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

O>Может и другие есть. Так что это косяк MS и никакой глубокой идеи в этом нет.

Согласен.

A>>может просто существует два старндарта? один для юзеров другой для внутренних рабочих?
O>Существует неряшливость конкретных разработчиков, пишуших код несоответствующий принятому в компании стандарту.

А вот тут не факт. Сдается мен что в МС просто стили если и выдерживаются, то внутри отдельных команд. У них же типа командно-ячеечная организация. А может просто какой-то код унаследованый.

В ихнем докуменете вообще не оковаривается скрытая часть. Им же важно было как класс выглядит извне. Они же правила для библиотек писали.

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

O>Факт есть факт Допускают. Например, код мог выйти из исследовательских лабораторий, или вообще адаптирован из кода сторонних компаний, приобретенных MS. Теоретически мог быть какой-нибудь outsourcing (хотя я таких случаев не знаю).

Да он мог быть даже с С++ портирован. А там в МС m_ вообще стандарт.

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

O>>>Offtopic: Знаешь, почему ошибки в комменатриях у MS обозначаются BUGBUG: а не просто BUG?
ВВ>>Почему?
O>Потому что поиск по слову BUG (и даже BUG:) срабатывает на DEBUG и на (DEBUG:).
O>

Т.е. ты хочешь сказать, что они там все идиоты и не знают о том, что в диалоге поиска ихней же IDE есть галка "Искать целое слово"?

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

A>здесь можно почитать ответ, почему же в коде фреймворка встечаются различные анахронизмы вроде m_ и прочего

Я плякль...

"Мы, ребятишки, делаем эту пургу для вас и сами пользоваться ею не хтим... Темболее что кое какие правила она проходит."

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

A>и знаете что корёбит? пробел между скобкой и ключивым словом!

Т.е. пробелы внутри скобок тебя не коробят? Ну, ты извращенец.

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

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

S>
S>Много лучше, чем в статье. Но ведь сейчас начнется — а я так привык!!! И никуда — аргумент непрошибаем.

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

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

AVK>Ну основная причина была сделать операторы непохожими на методы.

Откровенно говоря плохое основание. Текст редактируется в IDE, а она подсвечивает ключевые слова. Так что не ошибешся.

AVK> Твой же вариант просто не очень хорошо смотрится из-за пробелов внутри скобок (не соответствует оформлению обычного текста и режет глаз).

Вот тут полностью согласен.

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

O>В данном случае по моему мнению страдает читабельность. Я привык ключевым словом читать if, а не if(, поэтому когда я читаю код, глаз выхватывает ключевые слова и мозг строит из них структуру. Скобки в данном случае лишь сущность группировки, выделение условия как единого целого.
O>Аналогично в русском языке (это я привёл пример, как по-моему), пробел ставится перед скобкой, а не после( как в твоём примере ). Ну, и как удобнее читать?

Блни, ты привык так, он так. Разницы между вашими привычками никакой. Вопрос в другом доджно быть единообразно. Вот и приняли вариант из статьи. Он ведь во всех исходниках от МС фигурирует.

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

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

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

A>но например коментирование первой строки заставить править и вторую строку

У тебя наверно плохая папять. Тут же много раз говорилось, код пишится не для облегчения его написания. Он пишится для того чтобы его читать. Если тебе нужно временно что-то зкомпнтарить, то сделай себе пару макросов и роблем не будет.

В твоем же случае, если нужно постоянно коментировать код, легко можно сделать так:

        internal bool CompareStyles( StyleImpl source, StyleImpl destination )
    {
      return  true
                // && ( source.FillBackground == destination.FillBackground ) 
                && source.FillForeground == destination.FillForeground
         ... skipped ...
    }

И, кстати, очень советую не коментарить, а использвоать #if.

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

B>Так тоже нельзя, пробел после открывающей скобки, Влад заругается Не помню почему, но мне так привычнее, и читать легче.

B>

B>if( const == something)
B>{
B>  for( int i=0; i < 10; i++)
B>  {
B>    /// и т.д.
B>  }
B>}
B>

Еще как заругается. Ты вообще оказался самым экстовагантным. Ну, два пробела можно объяснить, но один... больше похоже на то что ты опечатался. И уж точно читать такой код неудобно. Глаз не выхватывает зависимостей.

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

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

A>>и знаете что корёбит? пробел между скобкой и ключивым словом!
VD>Т.е. пробелы внутри скобок тебя не коробят? Ну, ты извращенец.

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

VD>Что же касется пробелов между ключевыми словами и открывющей скобкой, то я тоже раньше их не ставил, и мен кажется это не логичным. Но так пишет 90% программистов. В кодах МС практически нельзя найти код не удовлетворяющий этому правилу. Да и в МСДН тоже.

а зачем быть как все?! "серая масса"?! и откудова цифра 90%???

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

философия:
основная проблема что на читабильность кода нету метрик, по которым можно было бы сказать что код читаемый и "удобваримый" или нет... если вывести такую метрику то от нее можно строить правила оформления кода...
на простой язык такие метрики были выведены, а на алгоритмические языки такое сделать забыли/неуспели/забили/и т.п.

но это все теория на самом деле тон команде задает менеджер или главный программер.. (мне Брукс'овское описание команды понравилось и модель ее постороения) следовательно он как главный должен определять стиль и контролировать код. Это я думаю главный фактор!

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

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

психология — а не програминг. но похожа на правду...

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