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

[moka]

Сообщение от pax

Кстати вот:
http://en.wikipedia.org/wiki/Naming_convention_(programming)

Уху, и при этом полная вырезка относящаяся к очень коммерчески популярному языку Java - который является "близнецом" C#.

ocal variables, instance variables, and class variables are also written in lowerCamelCase. Variable names should not start with underscore (_) or dollar sign ($) characters, even though both are allowed. Certain coding conventions state that underscores should be used to prefix all instance variables, for improved reading and program understanding.

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

[pax]

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

Сообщение от MoKa

Также использование "_" для приватных переменных объекта, в C# давно никто не юзает тоже.

не верно. Что и требовалось доказать.

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

[moka]

Сообщение от pax

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

не верно. Что и требовалось доказать.

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

Сообщение от pax

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

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

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

[ffinder]

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

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

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

[pax]

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

[Randomize]

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

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

[pax]

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

public float Life{get; private set;} 


Открытые поля в Net Framework характерны только для структур.

[HolyDel]

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

[moka]

Сообщение от Randomize

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

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

[IGR]

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

[johnk]

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

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

[pax]

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

[johnk]

Сообщение от pax

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

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