Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

Уху, и при этом полная вырезка относящаяся к очень коммерчески популярному языку Java - который является "близнецом" C#.
Насчёт того что для переменныз юзать lowerCamelCase (или camelBack), а для аксессоров использовать CamelCase - это полностью согласен и за. Тем более лично против использования "_" в наименованиях перменных или классов вообще. У меня он вообще не встречается, и код имхо читабельнее. В крупных OpenSource проектах тоже частенько можно найти где их вообще нету и не используют.

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

В общем вывод - зависит от принятого стиля конкретной конторы/человека. Следовательно утверждение
не верно. Что и требовалось доказать.

Я скажу по собственному опыту - использование знака подчеркивания делает более читабельным код (для меня точно) и чаще ускоряет кодинг.

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

Ну тут да, я загнул. Используют, но явная тендеция - уходить от этой привычки очень распространена.

Читабельность не лучше чем с использованием "_", а учитывая разницу стилей, то если рассматривать разработчика который не знаком с подобным стилем, потребуется ознакомление и привычка. Когда при использовании this. - этого не требуется, т.к. это часть спецификации языка и common sense.
Насчёт ускорения кодинга, ну тут если только в колличестве символов. Обращение к локальным переменным также шустро через this. как и через _.
Тем более, когда обращаешься к мемберам класса (переменным, методам, аксессорам и т.п.), то в голове всегда будет сразу "this." и без разделений так даже проще: хочешь обратиться к личной сущности экземпляра, автоматом набираешь "this.", и получаешь удобный список всех личных сущностей.
При этом многие шустрые разрабы (отличный пример в онлайн туториалах, где народ надрочен и кодит достаточно шустро), всё равно будешь набирать почти полное имя переменной, или хотя бы ту часть, начиная с которой эта переменная останеться одна или будет уже выделена в автодополнении. Редко кто юзает стрелки и темболее мышку чтобы искать нужную переменную, только в случае если ты не знаешь их. Тогда да, _ - сразу отфильтрует остальное от локальных, приватных перемен. Но это в случае если нигде глобально с "_" ничего не начиналось, иначе пойдёт полная каша.

Дело лично каждого. Я лишь заметил такую тенденцию что всё меньше и меньше юзают "_". Да и большинство кода, примеров и т.п. из msdn также меньше и меньше юзает "_", я уже почти вообще не встречаю этого.

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

this.fieldName это ГАРАНТИЯ от компилятора.
_fieldName это соглашение, которое форсится людьми и ими же нарушается.

поэтому я ненавижу всякие ПРЕФИКСЫ.
одинарное подчеркивание, некоторые доходят до двойного и тройного...
так же всякие m_memberName вызывают неприятие.

хороший код опирается на компилятор, плохой - на соглашения между людьми.

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

Двойные и тройные подчеркивания это перебор, префиксы с m_ тоже отвратительны.

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

Я считаю, что использовать префикс "_" нужно в тех ЯП где нет Private (например BlitzMax) в остальных можно обойтись и без этого. Префикс "_" сводит на нет автокомплит в IDE. Вернее он замедляет процесс нахождения нужного элемента для подстановки.

Почему public для полей - плохой тон? Лучше что-ли писать на каждое поле GetValue/SetValue?

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

Да лучше. Лучше вместо поля создать автосвойство. Такой подход в любое время позволит сделать обработку присвоения/взятия значения преобразовав автосвойство в нормальное свойство.
Открытые поля в Net Framework характерны только для структур.

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

правда это не шарп.
использую постфикс _ для приватных элементов класса. с одной стороны это позволяет выносить в интерфейс нормальные имена методов. т.е. например instance_ и instance(). с другой имеется и осмысленное имя переменной и интеллисенс не замедляется. на работе принят стандарт с m_someName;

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

Как уже писал:
Бьёт по производительности. И тут лучше использовать Acessor'ы, для обращения к данным класса. Это реюзабельней, и более масштабируемо, т.к. можно заменить лишь тело аксессора, и везде будут применены изменения. В случае с переменными, так не пройдёт. Плюс внедрение например эвентов при изменении переменной и т.п. - это снова, чтобы это сделать, если использовал прямой доступ, придётся везде менять, во всех проектах где юзается это. А если юзался аксессор, то лишь в нём добавиться одна / две строки кода, и всё. Нигде менять не нужно. Либо менять имя переменной, и делать аксессор тем же именем как была переменная, но учитывая правила наименований сущностей - это будет грубым нарушением, что в результате ни в какие ворота.
Плюс ограничения доступа, если нужно сделать переменную модифицируемой только изнутри, а получаемой от куда угодно, или наоборот и т.п.

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

обычно юзаю префикс для мемберов класса mFieldName !! и все ок !! :)

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

MoKa, я с тобой. Тоже за нормальное именование.
Приватные от не приватных разделяю написанием первого слова в названии.

doSmth() — приватная функция
DoSmth() — не приватная

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

Зачем различать приватные и публичные функции?

Ответ: Использование "_" или "this." для локальным переменных экземпляра класса.
 

Мне это кажется удобным.