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

+1
внешний это педальки газа, тормоза, а внутренний уже работа карбюратора, подсознательно понятней сразу куда лезешь  

Под левыми изменениями я имел ввиду изменения в местах вызова - убирание _ (или добавление). Это довольно сильно "шумит" в diff - вроде код не менялся, а строчка в логе svn/ревью системе подсвечена.  Изменение private->public - довольно редкое. private->protected/internal - частое.

Это немного дырявая абстракция. Protected-методы как тогда называть? А Internal?
Опять же, субьективно, вызывающий код (и пишущий его) не должен знать, на педальку он давит, или топливо в цилиндр впрыскивает. Главное чтобы вызываемый метод назывался AddMoreGas.

ну тогда уж давайте все по Макконеллу  

лично я использую "_имя" только для входящих в конструкторах и не пишу поля (в отличае от св-в и методов) с большой буквы. 

+ для создания свойств еще использую приватные переменные "_имясвойства".

Если использовать префикс this, то в конструкторах отпадает необходимость в _. Тем более что на разницу в имени параметра в конструкторе и соотв. паблик свойства FxCop тоже реагирует.

Я вот одного не пойму, неужели приятно, когда в каком-нибудь приватном методе, работающем активно с полями класса, понатыкано повсюду this'ов? 

mr.Anderson, да, вполне приятно - читабельность повышается. По крайней мере лично мне приятнее, чем понатыканные в том же количестве подчеркивания. 

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

Да, кстати сам я подчёркивание использую вот по каким соображениям:
1. Это короче чем this.
2. При таком подходе в интеллисенс все private поля находятся в одном месте и список прокручивается к этому месту после введения всего-лишь одного символа.
3. Ну и бейсик, конечно. Не буду же я стиль менять когда на шарпе пишу.

Но относиться к этому как к догме имхо не стоит.

Добавлено через 1 минуту и 29 секунд
С точки зрения эстетики полный код (с this) смотрится выразительнее(имхо), но писатьего дольше 

Добавлено через 13 минут и 8 секунд
И ещё: this спасает когда у класса мало членов, а взять например форму какую-нибудь, так там иногда приходится несколько символов ещё и после зыса вводить.

diadiavova, Дело вкуса - это когда ты один на проекте сидишь. А когда код одновременно пишут хотя бы двое, то сразу появляется необходимость в строгих гайдлайнах. А если человек хотя бы 5, то вероятность что вкус у них совпадет - чуть меньше 0. 


Можно писать как угодно, но перед коммитом реформатить. Для правил StyleCop есть StyleCop for Resharper, он из любой картошки делает кубик стандартного размера. И fail билда при несоответствии. Первые 2-3 коммита девелоперы ругаются, потом привыкают. Зато код написан однородно, даже проставлены xml comments. И не надо следить за стилем у новичков (или надеяться на их совесть/чувство вкуса).
Можно еще по пунктам пофлеймить ;)
1. Это на самом деле удлиняет имя на один символ. this. - не удлиняет, он просто задает контекст. По аналогии с однострочными if-ами и {}.
2. При подходе "проперти вместо полей" тебе вообще никогда не надо видеть весь список полей. И отладка намного облегчается.
3. Тут могу только согласиться, но про бейсик была оговорка выше. 

Ну поэтому речь только о private полях.

Ну опять-таки ты юзаешь эту тулзу, а другие нет. Если обсуждение ведётся вообще, а не применительно к кокретной тулзе, то это не арумент.

О того, что имя длиннее ты ничего не теряешь, вот вводить больше символов руками - напрягает. Я кстати иногда вообще использую временные имена, а когда код написан меняю на более длинные и понятные.

Поле объявить короче{get; set;}(про бейсик вообще молчу  ). 

И кстати: сейчас в рефлектор заглянул, так там довольно много таких имён. Так что...5 человек очевидно найдётся и кроме меня  

У нас нет девелоперов ответственных за конкретный класс 

Я просто рассматриваю проблему немного с другой точки зрения - удобства утверждения и поддержания общего стиля для всех проектов, а не удобства конкретного кодера. Конкретный кодер может привыкнуть к новому стилю. А проект к куче разных стилей не прывкнет :(

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

prop Tab Tab. ;)

На странице StyleСop довольно подробно описано про имена в CLR и не в CLR. Если коротко - то StyleСop - это попытка выработать общий стиль в MS, но CLR Team пока не поддалась 

Это сообщение отредактировал(а) PashaPash - 20.8.2009, 14:22

А что такого в этой чёрточке(если не считать стайлкопа). Чем она и кому так мешает? Я никак в толк не возьму какой от неё вред?

Ну видимо мне об этой кнопке ничего неизвестно. А у тебя случайно в запасе нет такой кнопки, чтобы нажал и она всё за тебя написала?  

Ну если бы надо было вручную, то я просто такой подход не использовал бы. Ну я ещё раз повторю, что твои предпочтения сводятся к стайлкопу. Вообще-то это нормально для тех кто им пользуется, но это далеко не все.

Не люблю я сниппеты. Поначалу, когда появились я был в восторге, но потом немного поигрался и не пользуюсь(полагаю не стоит разводить дискуссию ещё и по этому поводу). Я делаю по-другому:
написал макрос и теперь объявляю переменную, ставлю на неё каретку, запускаю макрос и он имплементит свойство(убирая хвостик из имени поля ессно...или добавляя если его там нет)


Воооооооот.  

Вред такой же, как и от других префиксов, не несущих смысловой нагрузки - засорение кода. А какая от нее польза?

о, а это идея...  Кнопка в решарпере - Reformat Code. Решарпер у меня выжил только ради нее ;)
В студии есть что-то похожее, но не настолько глобальное, где-то в Edit.


Если оба подхода - не вручную, то аргумент проперти - длиннее отпадает, так? ;)

Мои предпочтения сводятся к тому, что:
1. Легко встраивается в студию
2. Прикручивается к ccnet/msbuild
3. Поддерживает автоматический реформат кода
4. Выдает подробный хелп по каждому нарушению, а не просто "поставь тут пробел!"
5. По возможности написано Microsoft.

Ну почему "не несущих"? Я ведь написал, что смысл в том, чтобы выделить группу в интеллисенс. Тут вся фишка в том, что этот символ уникален в своём роде. Стандартные идентификаторы как правило начинаются с алфавитных символов, поэтому его удобно использовать для создания групп, которые не будут мельтишить в других классах. Я не всё помечаю этим символом, но когда начал пользоваться этим приёмомпросто заметил, что это удобно и без дополнительных средств помогает вводить меньше кода руками. 


Если я правильно понял назначение кнопки, то Edit.FormatDocument. Форматирует в соответствии с настройками студии. Я обычно эту команду вызываю из макросов после вставки, сгенерированного кода.
Ну вот пример. Создаю поле

Сгенерированный код свойства получается такой

При этом студия настроена на другой формат. Если после вставки кода вызывается команда форматирования то получается так

Вообще в студии очень много всего и ради одной фичи решарпер держать - это слишком. Проще макрос написать.

Ну про сниппеты я уже сказал. Меня ими пользоваться можешь даже не агитировать  

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

есть рекомендуемый code style от собственно создателей, полагаю, что в подавляющем большинстве случаев стоит его придерживаться - это даст по меньшей мере надежду, что код проекта будет понят и не вызовет отторжения у большинства разработчиков
тот же StyleCop - детище Microsoft
по-моему, весомей аргументации и не надо, а басиковые, плюсовые и другие привычки стоит оставить в басике, плюсах и других языках соответственно

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