Встал вопрос о написании переменных. Как лучше их указывать veriable или _veriable ? И почему?

CInNet, лучше писать variable, и обращаться к ней this.variable.

А почему? На самый главный вопрос не ответил)

Потому что так говорит Microsoft StyleCop.
SA1309: fields names must not start with an underscore.

Спасибо Павел  Теперь я хоть могу поспорить, что не надо писать никаких "_" перед объявлением переменной =)

Чем аргументировать будешь?

Потому что так говорит Microsoft StyleCop.
SA1309: fields names must not start with an underscore. 

Это сообщение отредактировал(а) CInNet - 19.8.2009, 10:40

Интересно из каких соображений они это написали  

CYBERDREAM, 
очень простые соображения - подчеркивание избыточно. StyleCop требует расставлять this. для  instance member-ов. Он же требует называть свойства с заглавных букв. 

IMHO, вполне однозначно и без _;

Я предпочитаю немного другую нотацию. И она имхо удобнее, меньше загромождение кода. Маленький примерчик, где разрисованы все аспекты оформления, которые я использую для именования переменных и функций:

В целом, так. Приватные поля с маленькой буквы с подчеркиванием спереди, что говорит о том, что они приватные. Публичные поля и методы с большой буквы без подчеркивания. Приватные методы с большой буквы с подчеркиванием. Так при чтении кода сразу разграничиваются общедоступные и скрытые поля и методы, а дополнительно при обращении к полям не надо тыкать везде this'ов, которые загромождают код. Кому как, имхо, такой стиль написания значительно упрощает чтение и сопровождение кода.

mr.Anderson, whom how. Мне проще поставить StyleCop с дефолтными настроками, и прикрутить его к ccnet, чем следить за стилем вручную. 
У this есть один бонус - студийный интеллисенс показывает после . именно то, перед чем надо this по правилам StyleCop ставить. И есть StyleCop For Resharper, который реформатит код.

Опять же IMHO, подчеркивание вообще для всех приватных вещей как-то сомнительно - лично меня очень сильно плющит от _PrivateMethod . При вызове внутри класса не важно приватный или не приватный метод вызывается. Если вдруг меняется область видимости - то подчеркивание убирается, и по коду появляется много левых изменений, что как-то неприятно. Чаще всего (по моему опыту) подчеркиванием выделяют именно поля, чтобы отличить их от свойств - довольно много людей перешло с VB, который не case-sensitive.

Это сообщение отредактировал(а) PashaPash - 19.8.2009, 16:19

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

впрочем, сейчас на проекте приватные поля начинаются с подчёркивания, не сказал бы, что страдаю - главное, чтобы все следовали одному код-стайлу (откровенно хреновые правила сами вымрут со временем)

Согласен полностью с mr.Anderson 

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

mr.Anderson, а чем эта приятность вызвана? т.е. в чём для тебя состоит разница между приватными и публичными методами?

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
по-моему, весомей аргументации и не надо, а басиковые, плюсовые и другие привычки стоит оставить в басике, плюсах и других языках соответственно

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

mihryak, это всё было бы уместным замечанием будь это общепринятыми правилами. И кстати: из самого начала документа


Дотнет - тоже его детище(обсуждалось уже).


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

Использование нескольких языков и так имеет свои неудобства. Усугублять их ещё и разными стилями мне ни к чему. Тот же Брэд Абрамс(кстати кто это  ) из твоей ссылки для васика те же рекомендации даёт.
Рекомендации по поводу формата хороши(даже не спорю), но вот только в студии почему-то можно настроить разный формат и по-умолчанию он вроде даже другой(не помню точно перенастраивал или нет), по крайней мере для JScript'а точно другой. Шарповский кодпровайдер тоже почему-то генерит код с другой расстановкой скобок. Пример, который я приводил как автореализацию свойства сгенерирован стандартным дотнетовским провайдером. Поэтому считать это официальным гайдлайном через чур смело. Я уже не говорю о том, что даже официальный гайдлайн - не догма. А то, что это тебя устраивает, так я об этом сразу сказал:"дело вкуса".

Ну вы и развели тут спор..  

Да ещё и в разделе "для новичков". Всех новичков распугаете  

  

я использую _ в переменных которые объявляются внутри функции, к примеру, как нить так:



как то так =)

А смысл? Внутри метода можно короткие имена использовать. Я, например, вместо returnValue использую просто rv, и ничего...не путаюсь  

Смысл и аргументы такие же, как и для твоего _ - допечатка сразу показывает список локальных переменных, и т.д.

Вообще-то можно определять свои правила, и наверняка в нете есть куча готовых FieldNameShouldStartWithUnderscore. Просто меня вполне устраивает стандартный набор.

Ну если писать методы на несколько экранов, то возможно да и то...область действия локальной переменной ограничивается блоком и только после того как она объявлена. Здесь запутаться трудно. Хотя до абсурда при желании можно довести всё что угодно.  Я сам стал использовать подчёркивание относительно недавно и мне просто понравился результат. Я не все поля так обзываю, а только те, которые мне нужно видеть в одной куче и нахожу этот способ очень удобным.

Ну то есть это как раз то о чём я и говорил: твои правила хороши если использовать стайлкоп, а не в общем случае. А с этим как бы никто и не спорил  

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

http://msdn.microsoft.com/en-us/library/dd...8VS.100%29.aspx



Это сообщение отредактировал(а) diadiavova - 23.8.2009, 12:36

Смысл в том, что сразу заметны "внутренние переменные", мне так удобнее
Ну я например не люблю которые, бессмысленные имена переменных.

Как-то так:

Ну рефлектор так и показывает, только что это значит на самом деле - фиг знает.  

Всмысле? В сборке такие имена и есть. Ты спросил во что преобразуются в шарпе автопроперти - я ответил. Или тебя смущают знаки меньше/больше? Так можно имя и пустой строкой сделать, и цифрой, и пробелом (подобными извращениями обфускаторы очень любят заниматься) - на уровне метаданных сборки (простейший способ поиграться - Mono.Cecil). Для шарп-кода это было бы невалидно, конечно.

Это сообщение отредактировал(а) Любитель - 24.8.2009, 10:26

Любитель, ну просто в васике можно было так же сделать, а они вместо этого намутили хрень.

diadiavova, оживим тему:

Аналог для C#: http://msdn.microsoft.com/en-us/library/w8...04(VS.100).aspx - без подчеркиваний.


Если использовать поля (а не свойства по всему классу, на нескольно экранов ;), то возможно что _ и нужно. А вообще область применения поля ограничивается get/set соотв. свойства. Цепочка "я не использую свойства <- они длинее на 10 символов <- я не пользуюсь сниппетами <- просто не пользуюсь и все". "Просто захотелось", и теперь везеде в коде надо вписывать на один символ больше.


Автореализуемые свойства - это проблема компилятора, он не заморачивается на читабельности. Стиль нужен для кода который пишут люди и сопровождают люди. Мегаклассы для анонимных делегатов и типов - не повод писать вообще как попало и называть методы c1____aaa__111. 

Это сообщение отредактировал(а) PashaPash - 25.8.2009, 17:58

Зачем? 


Это были просто иллюстрации того, что приём используется.

Это ты о чём? Там речь вроде как шла о применении приёма внутри методов. Метод на несколько экранов - ни есть хорошо. Или ты не согласен?

Да это как сказать. Иногда в сеттере выполняются действия, которых надо избежать при внутреннем обращении.

Сниппетами не пользуюсь потому, что не нахожу их удобными. В целом мой подход позволяет меньше вводить руками. Если бы предлагаемый тобой способ был короче, то я - не догматик, но поскольку пробовал разные приёмы и в данный момент остановился на этом, как на более удобном. 
И ещё: стараюсь минимизировать использование одноимённых идентификаторов в одной области видимости, это может запутать не только человека, но и машину. Поэтому в принципе считаю регистрозависимость плохой идеей. Возможно мои предпочтения отчасти обусловлены и этим обстоятельством.

да скучно...

что прием используется в VB и с сгенеренном компилятором коде. Ни то ни другое отношения к стилю человеческого когда на C# не имеют.

Я пытался по аналогии для полей описать ситуацию.

Тогда иногда можно называть поля с _ .  

"Меньше вводить" увеличивается на 1 при каждом использовании, а их будет минимум 2. Ведь ты не экономишь символы, используюя public-поля вместо свойств. Почему тогда экономишь на private, потенциально добавляя проблем следующему разработчику? Проперти удобнее полей по ряду причин. Хотя бы просто из-за возможности поставить breakpoint. Ситуация "где-то в классе на 9000 строк меняется значение поля на X, и надо как-то найти где и в какой момент" не слишком редкая. Если подход короче в написании, но сложнее в поддержке - это плохой подход 

А почему ты никогда во флейме не появляешься? Там весело.

О человеческих стилях я сказал уже.

Не понял...ну да ладно.

А я так и делаю. Когда удобно - называю. У меня не все поля такие.


При использовании я практически только его и ввожу, потом появляется интеллисенс. Сопсно ради этого всё и делается.

Ну я ведь уже упоминал о волшебном макросе  

О каких проблемах речь?

Внешние не только удобнее но и безопаснее, на счёт внутренних я бы поспорил.

Внутри класса при необходимости это легко изменить...и не обязательно руками.

Я делаю флейм вокруг себя ;)

А интеллисенс нужен чтобы обратиться именно к полю, а не свойству. Не слишком частая ситуация, чтобы вводить ради нее стиль с _. Особенно с учетом сниппетов волшебного макроса.

О проблемах "он не получит все плюшки свойств".


Легко, если ты дебагаешь локальное приложение на локальной машине, и вообще можешь менять исходники. И даже в этом случае надо пересобрать/перезапустить/повторить (а пока компилируется/стартует - полазить по нету и по форумам). Впрочем, у каждого свои критерии удобности и соотношенеи свой код в редакторе/чужой код в дебаге. У меня что-то в последнее время 2-е перевешивает :(

К прайвит члену, к которому нужно обращаться неоднократно. 

Да вообще-то частая

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

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

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