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

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

А почему ты решил что твое мнение спустили в унитаз? Мы его выслушали, многие в команде с ним не согласны, и никто не поподдержал. Что ты еще хочешь от нас?

A> вы же не принимаете по статье не одного изминения.

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

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

Могу прояснить если ты не в курсе. Эти правила написаны не от балды, а составлены на основании нескольких документов и мнения команды. Кроме того они неоднократно и очень тщательно обсуждались. Или ты считаешь что мы должны менять правила по первому твоему требованию?

A>а вы уверены что так и есть правильно?

Нет.

A> "...а судьи кто?.."

Мы сами. Даже если твой вариант и не хуже то он совершенно точно не лучше. Подстраивать под твои привычки правила по меньшей мере странно.

A>то что вы выставили есть мнение только вашой команды и ничего более,

Разумеется. А разве мы где то утверждали обратное?

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

А тебя никто и не заставляет. Я бы вот к примеру вполне согласен был бы с этими правилами и сильно несогласен с пробелами внутри скобок. Ничего личного, но твои "рекомендации" я бы в команду не пустил.

A>а вообще надо искать компромисы. найдем ли мы их?

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

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

A>>Им не понравилось твоё предложение, и они нашли сил тебе об этом написать. Другие просто проигнорировали.

M>Да нет, Влад вон очень ругается, совсем не лениво. Мол, полная фигня и лажа эти пробелы — убери их нафиг.

Правильно ругается, фигня и лажа.

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

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

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

AVK>У нас на фирме, которая вобщем то довольно большая, правила кодирования были поправлены по моей просьбе в первую же неделю после моего устройства. В принципе изменений было немного, но тем не менее.

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

но какого девелоперы должны страдать от такого? после разговора с ними они почти все пожаловались на очень хреновый код и его качество, а это все люди с довольно большим стажем работы... (правда это уже второй или третий состав на проекте
вот и чтобы такое не повторялось я хочу написать стандард для c# проектов, который надеюсь будет поддержан всеми командами работающих по направления NET. (что не удивительно бывшие с++ намного лучше оформляют код и намного он у них надежней чем у делфистов... дурное наследие?! или само-контроль выше?!)

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

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

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

A>>а вообще надо искать компромисы. найдем ли мы их?

AVK>Найдем если будут нормальные аргументы, а не я привык или на одно нажатие на кнопочку меньше.
in bold — кстати очень серьезный аргумент если вдуматься — повышыние скорости работы, а потом как рефлекс...

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

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

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

A>>>Им не понравилось твоё предложение, и они нашли сил тебе об этом написать. Другие просто проигнорировали.

M>>Да нет, Влад вон очень ругается, совсем не лениво. Мол, полная фигня и лажа эти пробелы — убери их нафиг.

IT>Правильно ругается, фигня и лажа.

аргумент плиз... у меня есть: работать становиться как минимум на одно тело-движение меньше.
а там как в мультике про дюймовочку:
"...
— сколько она ест?
— пол зернышка в день.
— а в год? давайте посчитаем уважаемы кроты..."(с)Союзмультфильм

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

O>>

O>>    if (data == null 
O>>        || data.Length == 0
O>>        || data.Length == 1
O>>       throw new ArgumentNullException( "data" );
O>>

M>Вредительство!!! Бей хакера!!!
Согласен, но речь была совсем не о том

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


A>переходи на 1с там говорят на русском писать мона...
В Net тоже можно.
A>а вообще мне не понравилось бы если вместо привычных операторов мне пришлось бы писать на русском код... бррр... как подумаю аж в дрожь бросает...
Это все дело привычки. Привыкнув к 1С написанию рука так и тянется обозвать методы и переменные по русски, нежели выдумывать англоязычные названия или их транслит. А на это иногда может уйти время и потерять мысль. Иногда это просто бесит. Мои нововведения руского написания методов и переменных ввстречены в штыки. Но ничего плохого не вижу оссобенно для людей с плохим знанием английского. А переход с одной раскладки на другую вырабатываются очень быстро.

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

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


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

До Net это можно было и в J++

Здравствуйте, 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" <1@news.rsdn.ru> wrote in message news:592801@news.rsdn.ru...

>

> public class MyClass:ClassBase{public MyClass(int param):base(param){_param=param}public int Param{{get{return _param;}set{_param=value}}}
>

Зато появляется ограничение на количество "символов" в реализации класса

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

A>а то глянул в код другого проекта страшно стало, все методы в трай кетчах, проверок на входные параметры нету, лоигка лееров размыта... короче полный пи... а все от того что менеджер и "движок" команды оказалсяч не готов к переходу на NET и самое плохое что не захотел воспользоваться опытом других NET проектов.

Это ты уже говоришь не о соглашениях, а о best practices. Это несколько разные документы.

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

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

A>>а вот маленький пример где выделеные скобки все-таки полезны:

IT>И чем они полезны? Ух, аж в глазах рябит. Сравни лучше вот с этим:

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

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

IT>>И чем они полезны? Ух, аж в глазах рябит. Сравни лучше вот с этим:

S> Опять же на вкус и цвет товарищей нет. Мне нравится когда в больших или малых условиях они выделены в скобки. Глаз сразу выдирает их.
S> Без скобок начинается потеря быстрого восприятия.

Хочешь устроить голосование — Лишние скобки против выравнивания столбиком?

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

IT>>Правильно ругается, фигня и лажа.

A>аргумент плиз...

Нате вам аргументы

Автор: IT
Дата: 02.04.04

.

Здравствуйте, 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>тут мотивации сравнить надо, а не на глаз приятно или нет.
Мотивация тут ровно одна: правила кодирования должны быть. Неудобные правила — лучше, чем вообще никаких. Все. А есть там пробелы или нет — просто о малое по сравнению с разнобоем в стилистике. Я писал код в стилеКэмел, Паскаль, szВенгерка, m_МФЦвенгерка, и даже где_слова_отделяются_подчеркиванием и все с маленькой буквы... Переучивание приходит на второй день работы. Максимум на третий. Поэтому, когда ты соберешся внедрять стиль у себя — не думай слишком долго. Бери любой.
Единственная оговорка — если у вас 90% кода написано в каком-то одном стиле, то переходить на другой не стоит. Даже если это — __тот_самый_стиль.

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

A>а я не говорю что у нас правил нету... они есть, но не на бумаге.

А вот это очень плохо. Вы как новичкам правила объясняете, на пальцах?

A> и самое главное что команда их сама выработал за три дня...

И у нас тоже команда выработала.

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

К правилам кодирования это отношения не имеет, это уже ошибки дизайна и некачественная реализация.

A>Offtopic: очень не порадовало что почти все "решения" очень рекламируешеся для NET от майкрософт оказались не очень состоятельны для большого проекта. где вылизли огромные потребления по памяти, где по перфомансу пролет...

Не знаю, у нас все прилично.

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

AVK>>Найдем если будут нормальные аргументы, а не я привык или на одно нажатие на кнопочку меньше.
A>in bold — кстати очень серьезный аргумент если вдуматься — повышыние скорости работы, а потом как рефлекс...
A>это все сказываеться на том как эфективно програмист может использовать IDE и следовательно сколько он времени тратит на перевод своего "фокуса" с кода на утилитарные действия... еффект как от печати на клаве в слепую. скорость повышаеться.

Я в свое время писал на паскале с его begin/end. Так вот — лично для меня производительность от количества буковок в процедурных скобках нее зависит вобще никак. На собственно набор текста на клавиатуре уходит очень мало времени. Если же начинает уходить много то это повод задуматься над тем все ли правильно в дизайне.

IT>Правильно ругается, фигня и лажа.

Не, неправильно. Полезная вещь. Рулез!