1. Назначение this (для не static классов - я в курсе). Это из-за области видимости в методах? Чтобы не порождать конфликт, если в методе используется локальная переменная с таким же типом и именем, что и поле класса?
2. Раз метод пишем мы же, то все локальные переменные и аргументы мы можем называть иначе, чем поля. И никакого конфликта.

Например при расширении класса без this не обойтись)))
При написании конструктора, который вызывает другой конструктор в этом же классе без this не то, чтобы не обойтись - некрасиво без этой конструкции будет.

Это сразу, что в голову пришло, по поводу тех случаев, когда this исключительно полезен)))

вообще микрософтовский стиль рекомендует именовать поля вот так

а локальные переменные без подчеркивания. Если следовать этому стилю
1. из кода будет ясно видно, где локальные переменные а где поля
2. конфликтов не будет


ну да, а в чем вопрос?

azesmcar, странно, я не замечал в майкрософтовском стиле никаких упоминаний подчеркиваний, тем более в конце имени поля. В исходниках фреймворка и MS проектах на codeplex подчеркиваний в конце имени тоже нет. Можно ссылку на определение стиля?

Сейчас поищу, возможно устаревшая информация.

Добавлено @ 23:45
PashaPash

Ты прав, это был другой стандарт (не микрософтовский), почему-то мне запомнился microsoft. А microsoft как раз наоборот, не рекомендует использовать подчеркивания

http://blogs.msdn.com/brada/articles/361363.aspx


Это сообщение отредактировал(а) azesmcar - 3.4.2010, 23:47

Получается полюбому писать this.? Для удобочитаемости?

Это сообщение отредактировал(а) Gunslinger - 4.4.2010, 10:23

По-моему не обязательно, а что вам вообще мешает почитать спецификацию на msdn? 

PashaPash, ага, +1. Я тоже удивился, когда про подчёркивания прочитал)))

Это сообщение отредактировал(а) ДобренькийПапаша - 4.4.2010, 10:58

я в русскоязычном мсдн по с# копаюсь, где у них спецификация не знаю. Короче назначение this понял, дальше буду по читаемости кода смотреть -- ставить или нет.