Привет всем!
У меня возник вопрос по стилю кодирования в C#. Я на С# только сейчас начала что-то писать. До этого привыкла писать на C++. В C++ привыкла писать переменные класса как "m_var" или просто "_var". Некоторые так делают и в C#. Но, смотря чужие коды, все больше и больше замечаю, что все пишут этот "this.var" (меня он как-то раздражает малость...). Я вот в C++ только один раз видела в каком-то скачанном примере "this->var". Так вот — как принято у нормальных людей в С# писать? Причем, Resharper на этот "this.var" ругается, чтобы его удалить как лишний...
Здравствуйте, Kalina9001, Вы писали:
XJ>>Причем, Resharper на этот "this.var" ругается, чтобы его удалить как лишний...
K>Только если его не настроить
Я, конечно, понимаю, что его (как и большинство программ ) можно настроить , но дело в том, что, так как я ламер, то я не знаю, как его нормальные люди настраивают В смысле — какие именно настройки ставят опытные C#-программисты.
XJ>Привет всем! XJ>У меня возник вопрос по стилю кодирования в C#. Я на С# только сейчас начала что-то писать. До этого привыкла писать на C++. В C++ привыкла писать переменные класса как "m_var" или просто "_var". Некоторые так делают и в C#. Но, смотря чужие коды, все больше и больше замечаю, что все пишут этот "this.var" (меня он как-то раздражает малость...). Я вот в C++ только один раз видела в каком-то скачанном примере "this->var". Так вот — как принято у нормальных людей в С# писать? Причем, Resharper на этот "this.var" ругается, чтобы его удалить как лишний...
Отличать локальные переменные и параметры функций от полей классов полезно.
Что подходить для этого лучше: this.var или _var или еще что то, ответить не берусь — дело вкуса.
Лично использую _var.
Здравствуйте, XJess, Вы писали:
XJ>Привет всем! XJ>У меня возник вопрос по стилю кодирования в C#. Я на С# только сейчас начала что-то писать. До этого привыкла писать на C++. В C++ привыкла писать переменные класса как "m_var" или просто "_var". Некоторые так делают и в C#. Но, смотря чужие коды, все больше и больше замечаю, что все пишут этот "this.var" (меня он как-то раздражает малость...). Я вот в C++ только один раз видела в каком-то скачанном примере "this->var". Так вот — как принято у нормальных людей в С# писать? Причем, Resharper на этот "this.var" ругается, чтобы его удалить как лишний...
Про венгерскую нотацию — в той интерпретации в какой она используется, смысла в ней нет (IMHO, конечно). Я много лет писал с префиксами, не понимая зачем я это делаю, но так было принято в той компании, где я работал. Тут еще момент — чтобы все в компании писали одинаково, иначе бардак будет. Но оказалось не я один не понимаю, зачем мне тип переменной. А изначальный смысл венгерской нотации был значительно интереснее, как оказалось позже
Писать с подчеркиванием — неплохо, я так иногда делаю, когда надо внутри класса сделать свойство. Например,
private int _myVar;
private int myVar
{
get...
set...
}
Но если использовать подчеркивания повсеместно, то код становится не читабельным:
_result+= _x + _y*_y - _z;
Ужас, как мне кажется.
Про this — тут дело вкуса. В C++ я никогда не писал this.x, а в C# стал, но только в конструкторе. Опять же из-за венгерской нотации, точнее из-за ее отмены.
private int count;
public MyClass(int count)
{
this.count = count;
}
Мне кажется, что так лучше, чем изобретать отдельные имена для переменной, параметра да еще и свойства. А писать m_count для переменной я как-то смысла не вижу. Лень, наверное...
Итого — пишите 1) как нравится 2) едино, как принято в компании 3) со смыслом 4) чтобы можно было читать код.
Здравствуйте, XJess, Вы писали:
XJ>Привет всем! XJ>У меня возник вопрос по стилю кодирования в C#. Я на С# только сейчас начала что-то писать. До этого привыкла писать на C++. В C++ привыкла писать переменные класса как "m_var" или просто "_var". Некоторые так делают и в C#. Но, смотря чужие коды, все больше и больше замечаю, что все пишут этот "this.var" (меня он как-то раздражает малость...). Я вот в C++ только один раз видела в каком-то скачанном примере "this->var". Так вот — как принято у нормальных людей в С# писать? Причем, Resharper на этот "this.var" ругается, чтобы его удалить как лишний...
переменные члены класса — с префиксом '_' (private, protected — других не завожу).
локальные переменные и параметры методов с маленькой буквы.
свойства/методы классов с большой буквы (private, protected, public, internal — все).
(по-умолчанию решарпер так и настроен).
пример:
class MyClass{
private int _member;
public MyClass(int member){
_member = member;
}
public int Member { get { return _member; } }
}
никакой путаницы, никаких бессмысленных префиксов (член или локальная переменная, тип переменной), this нужен в оооочень редком случае.
Casing & Naming Guidelines
Casing and naming guidelines apply only to public and protected identifiers, and privately implemented interface members. Teams are free to choose their own guidelines for internal and private identifiers.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, XJess, Вы писали:
XJ>У меня возник вопрос по стилю кодирования в C#. Я на С# только сейчас начала что-то писать. До этого привыкла писать на C++. В C++ привыкла писать переменные класса как "m_var" или просто "_var". Некоторые так делают и в C#. Но, смотря чужие коды, все больше и больше замечаю, что все пишут этот "this.var" (меня он как-то раздражает малость...). Я вот в C++ только один раз видела в каком-то скачанном примере "this->var". Так вот — как принято у нормальных людей в С# писать? Причем, Resharper на этот "this.var" ругается, чтобы его удалить как лишний...
По поводу статических полей сказано по ссылкам тут
. Экзесплярные поля (* есть исключения) я называю в camelCase без всяких подчерков и не использую "this." при обращении к ним. К каждому полю у меня есть свойство и всюду, где это возможно, используются именно свойства, поэтому путаницы с параметрами нет.
* Исключения такие: например, создоваемые дизайнерами (WinForms, WPF) контролы я именую в PascalCase, часто с суфиксом из типа контрола a-la CompanyTextBox, ServerComboBox, DetailsGrid или DetailsView. Так же в PascalCase временно называю поля, которые потом будут заменены на свойства, но в порыве взмаха пера возиться с этим не охота.
Help will always be given at Hogwarts to those who ask for it.
Re: Стиль кодирования - переменные класса
От:
Аноним
Дата:
02.08.10 14:31
Оценка:
зачем пишут this?
очень просто — чтобы спровоцировать студию на подсказку . На фиг помнить стопитцот полей и методов? А потом просто лень уже удалять это this-> или this. )
XJ>У меня возник вопрос по стилю кодирования в C#. Я на С# только сейчас начала что-то писать. До этого привыкла писать на C++. В C++ привыкла писать переменные класса как "m_var" или просто "_var". Некоторые так делают и в C#. Но, смотря чужие коды, все больше и больше замечаю, что все пишут этот "this.var" (меня он как-то раздражает малость...). Я вот в C++ только один раз видела в каком-то скачанном примере "this->var". Так вот — как принято у нормальных людей в С# писать? Причем, Resharper на этот "this.var" ругается, чтобы его удалить как лишний...
Решарперу верить Выучить комбинацию Shift-Ctrl-Alt-F
Здравствуйте, XJess, Вы писали:
XJ>Привет всем! XJ>У меня возник вопрос по стилю кодирования в C#. Я на С# только сейчас начала что-то писать. До этого привыкла писать на C++. В C++ привыкла писать переменные класса как "m_var" или просто "_var". Некоторые так делают и в C#. Но, смотря чужие коды, все больше и больше замечаю, что все пишут этот "this.var" (меня он как-то раздражает малость...). Я вот в C++ только один раз видела в каком-то скачанном примере "this->var". Так вот — как принято у нормальных людей в С# писать? Причем, Resharper на этот "this.var" ругается, чтобы его удалить как лишний...
Ну тут дело не в "нормальности" в любом случае это некоторая вкусовщина.
А вот привычка писать this.var, как раз растёт от желания "подложить соломки" и убедится в том, что обращение происходит к полю а не локальной переменной. Это соломка не требуется, если переменные и так визуально отличаются от полей префиксом. Т.е. this._var уже перебор. Кстати, в R# эта проверка настраивается.
IMHO, писать 'm_var' это прежиток C++, ибо получается "масло масляное". Пишу _var. Вообще, умолчания R# по именованию очень осмысленные — использую с минимальныой модификацией.
Это запомнить на порядок сложнее . Кстати, из этой же оперы вставка :: перед методами WinAPI бывалыми С++ кодерами. Хотя они конечно будут с умным видом доказывать, что они избегают конфликтов, поэтому пишут везде ::CreateFile.
H>IMHO, писать 'm_var' это прежиток C++, ибо получается "масло масляное". Пишу _var.
Да, здравый аргумент, коллега, безусловно. Буква m в данном случае добавляет масла и делает запись пережитком. Я бы даже сказал, это очевидный аргумент. Преимущество и современность '_' перед 'm_' очевидны. Просто в первом случае меньше масла. Можно даже сказать, вообще нет.
Да уж, префикс 'm_' немедленно напоминает старые пыльные времена микрософтовского C++, этот унылый эмэфсишный венгерский мирок.
А вот подчеркивание — совершенно другое дело. Вроде бы и делает то же самое, что и 'm_', но с устаревшим C++ совершенно не ассоциируется.
Забавно, что некоторые коллеги с опытом программирования на C и C++ отмечают, что такая запись несколько нелепым образом вызывает у них неприятные ассоциации со старым добрым плохим сишным кодом безграмотных программистов, не знавших, что с давних времен в стандарте языка С идентификаторы, начинающиеся с подчеркивания, не рекомендовались к использованию, так как предназначались для применения в стандартных библиотеках. Вообще, это занятная тема — программирование на C# с точки зрения кондового сишника.
Да, буква m добавляет масла, maslo, maslo. Пережиток с маслом.
Интересно, а пережитки с маслом тоже падают маслом вниз, как и бутерброды?
Здравствуйте, Аноним, Вы писали:
А>зачем пишут this?
А>очень просто — чтобы спровоцировать студию на подсказку . На фиг помнить стопитцот полей и методов? А потом просто лень уже удалять это this-> или this. )
_FR>Casing & Naming Guidelines
_FR>Casing and naming guidelines apply only to public and protected identifiers, and privately implemented interface members. Teams are free to choose their own guidelines for internal and private identifiers.