Теперь я хоть могу поспорить, что не надо писать никаких "_" перед объявлением переменной =)| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > .NET для новичков > Правило написания переменных |
| Автор: CInNet 18.8.2009, 17:25 |
| Встал вопрос о написании переменных. Как лучше их указывать veriable или _veriable ? И почему? |
| Автор: PashaPash 18.8.2009, 18:18 |
| CInNet, лучше писать variable, и обращаться к ней this.variable. |
| Автор: CInNet 18.8.2009, 18:24 |
| А почему? На самый главный вопрос не ответил) |
| Автор: PashaPash 18.8.2009, 18:34 |
| Потому что так говорит Microsoft StyleCop. SA1309: fields names must not start with an underscore. |
| Автор: CInNet 18.8.2009, 18:55 |
| Спасибо Павел Теперь я хоть могу поспорить, что не надо писать никаких "_" перед объявлением переменной =) |
| Автор: NightmareZ 18.8.2009, 19:20 | ||
Чем аргументировать будешь? |
| Автор: CInNet 19.8.2009, 10:39 | ||
Потому что так говорит Microsoft StyleCop. SA1309: fields names must not start with an underscore. |
| Автор: CYBERDREAM 19.8.2009, 10:58 |
Интересно из каких соображений они это написали  |
| Автор: PashaPash 19.8.2009, 13:42 | ||
| CYBERDREAM, очень простые соображения - подчеркивание избыточно. StyleCop требует расставлять this. для instance member-ов. Он же требует называть свойства с заглавных букв.
IMHO, вполне однозначно и без _; |
| Автор: mr.Anderson 19.8.2009, 15:37 | ||
Я предпочитаю немного другую нотацию. И она имхо удобнее, меньше загромождение кода. Маленький примерчик, где разрисованы все аспекты оформления, которые я использую для именования переменных и функций:
В целом, так. Приватные поля с маленькой буквы с подчеркиванием спереди, что говорит о том, что они приватные. Публичные поля и методы с большой буквы без подчеркивания. Приватные методы с большой буквы с подчеркиванием. Так при чтении кода сразу разграничиваются общедоступные и скрытые поля и методы, а дополнительно при обращении к полям не надо тыкать везде this'ов, которые загромождают код. Кому как, имхо, такой стиль написания значительно упрощает чтение и сопровождение кода. |
| Автор: PashaPash 19.8.2009, 16:16 |
| mr.Anderson, whom how. Мне проще поставить StyleCop с дефолтными настроками, и прикрутить его к ccnet, чем следить за стилем вручную. У this есть один бонус - студийный интеллисенс показывает после . именно то, перед чем надо this по правилам StyleCop ставить. И есть StyleCop For Resharper, который реформатит код. Опять же IMHO, подчеркивание вообще для всех приватных вещей как-то сомнительно - лично меня очень сильно плющит от _PrivateMethod . При вызове внутри класса не важно приватный или не приватный метод вызывается. Если вдруг меняется область видимости - то подчеркивание убирается, и по коду появляется много левых изменений, что как-то неприятно. Чаще всего (по моему опыту) подчеркиванием выделяют именно поля, чтобы отличить их от свойств - довольно много людей перешло с VB, который не case-sensitive. |
| Автор: mihryak 19.8.2009, 17:01 |
| не пишу ни подчёркивание, ни this, локальных переменных в разумных пределах избегаю, а использование приватных св-в и методов никак не отделяю для себя от использования публичных впрочем, сейчас на проекте приватные поля начинаются с подчёркивания, не сказал бы, что страдаю - главное, чтобы все следовали одному код-стайлу (откровенно хреновые правила сами вымрут со временем) |
| Автор: Enteropoly 19.8.2009, 17:38 |
| Согласен полностью с mr.Anderson |
| Автор: mr.Anderson 19.8.2009, 19:15 | ||
То применяется рефакторинг, и "левых" изменений там попросту нет))) Лично мне бывает просто приятно знать, вызываю я внутренний метод или же внешний при работе внутри класса. Возможно, субъективно. |
| Автор: mihryak 19.8.2009, 23:20 |
| mr.Anderson, а чем эта приятность вызвана? т.е. в чём для тебя состоит разница между приватными и публичными методами? |
| Автор: mr.Anderson 20.8.2009, 00:35 | ||
mihryak, разницы по сути никакой. Просто мне как-то удобнее знать, какой из методов я сейчас вызываю. Поэтому в конце своего мессага я и написал
|
| Автор: Heinzz 20.8.2009, 07:43 | ||
+1 внешний это педальки газа, тормоза, а внутренний уже работа карбюратора, подсознательно понятней сразу куда лезешь |
| Автор: PashaPash 20.8.2009, 11:59 | ||||
Под левыми изменениями я имел ввиду изменения в местах вызова - убирание _ (или добавление). Это довольно сильно "шумит" в diff - вроде код не менялся, а строчка в логе svn/ревью системе подсвечена. Изменение private->public - довольно редкое. private->protected/internal - частое.
Это немного дырявая абстракция. Protected-методы как тогда называть? А Internal? Опять же, субьективно, вызывающий код (и пишущий его) не должен знать, на педальку он давит, или топливо в цилиндр впрыскивает. Главное чтобы вызываемый метод назывался AddMoreGas. |
| Автор: Heinzz 20.8.2009, 12:47 | ||
ну тогда уж давайте все по Макконеллу  лично я использую "_имя" только для входящих в конструкторах и не пишу поля (в отличае от св-в и методов) с большой буквы. + для создания свойств еще использую приватные переменные "_имясвойства". |
| Автор: PashaPash 20.8.2009, 12:58 | ||
Если использовать префикс this, то в конструкторах отпадает необходимость в _. Тем более что на разницу в имени параметра в конструкторе и соотв. паблик свойства FxCop тоже реагирует. |
| Автор: mr.Anderson 20.8.2009, 13:07 |
| Я вот одного не пойму, неужели приятно, когда в каком-нибудь приватном методе, работающем активно с полями класса, понатыкано повсюду this'ов? |
| Автор: PashaPash 20.8.2009, 13:17 |
| mr.Anderson, да, вполне приятно - читабельность повышается. По крайней мере лично мне приятнее, чем понатыканные в том же количестве подчеркивания. |
| Автор: diadiavova 20.8.2009, 13:32 |
| А вы не думаете, что всё это - всего лишь дело вкуса? Кто-то выбирает стиль по эстетическим соображениям, кто-то пишет помимо шарпа на регистронезависимом бейсике, это тоже откладывает отпечаток на стиль, кто-то пользуется тулзой, у которой свои правила, у кого-то соображения чисто практические. Только вот предмета для спора я тут не вижу. Да, кстати сам я подчёркивание использую вот по каким соображениям: 1. Это короче чем this. 2. При таком подходе в интеллисенс все private поля находятся в одном месте и список прокручивается к этому месту после введения всего-лишь одного символа. 3. Ну и бейсик, конечно. Не буду же я стиль менять когда на шарпе пишу. Но относиться к этому как к догме имхо не стоит. Добавлено через 1 минуту и 29 секунд С точки зрения эстетики полный код (с this) смотрится выразительнее(имхо), но писатьего дольше Добавлено через 13 минут и 8 секунд И ещё: this спасает когда у класса мало членов, а взять например форму какую-нибудь, так там иногда приходится несколько символов ещё и после зыса вводить. |
| Автор: PashaPash 20.8.2009, 13:49 | ||
diadiavova, Дело вкуса - это когда ты один на проекте сидишь. А когда код одновременно пишут хотя бы двое, то сразу появляется необходимость в строгих гайдлайнах. А если человек хотя бы 5, то вероятность что вкус у них совпадет - чуть меньше 0.
Можно писать как угодно, но перед коммитом реформатить. Для правил StyleCop есть StyleCop for Resharper, он из любой картошки делает кубик стандартного размера. И fail билда при несоответствии. Первые 2-3 коммита девелоперы ругаются, потом привыкают. Зато код написан однородно, даже проставлены xml comments. И не надо следить за стилем у новичков (или надеяться на их совесть/чувство вкуса). Можно еще по пунктам пофлеймить ;) 1. Это на самом деле удлиняет имя на один символ. this. - не удлиняет, он просто задает контекст. По аналогии с однострочными if-ами и {}. 2. При подходе "проперти вместо полей" тебе вообще никогда не надо видеть весь список полей. И отладка намного облегчается. 3. Тут могу только согласиться, но про бейсик была оговорка выше. |
| Автор: diadiavova 20.8.2009, 14:05 | ||||||||
Ну поэтому речь только о private полях.
Ну опять-таки ты юзаешь эту тулзу, а другие нет. Если обсуждение ведётся вообще, а не применительно к кокретной тулзе, то это не арумент.
О того, что имя длиннее ты ничего не теряешь, вот вводить больше символов руками - напрягает. Я кстати иногда вообще использую временные имена, а когда код написан меняю на более длинные и понятные.
Поле объявить короче{get; set;}(про бейсик вообще молчу ). И кстати: сейчас в рефлектор заглянул, так там довольно много таких имён. Так что...5 человек очевидно найдётся и кроме меня |
| Автор: PashaPash 20.8.2009, 14:21 | ||||||||||
У нас нет девелоперов ответственных за конкретный класс
Я просто рассматриваю проблему немного с другой точки зрения - удобства утверждения и поддержания общего стиля для всех проектов, а не удобства конкретного кодера. Конкретный кодер может привыкнуть к новому стилю. А проект к куче разных стилей не прывкнет :(
я не ввожу руками, я давлю одну мегакнопку "сделать зашибись" . Временные имена ты ведь тоже не вручную потом правишь.
prop Tab Tab. ;)
На странице StyleСop довольно подробно описано про имена в CLR и не в CLR. Если коротко - то StyleСop - это попытка выработать общий стиль в MS, но CLR Team пока не поддалась |
| Автор: diadiavova 20.8.2009, 14:40 | ||||||||||
Ну видимо мне об этой кнопке ничего неизвестно. А у тебя случайно в запасе нет такой кнопки, чтобы нажал и она всё за тебя написала?
Ну если бы надо было вручную, то я просто такой подход не использовал бы. Ну я ещё раз повторю, что твои предпочтения сводятся к стайлкопу. Вообще-то это нормально для тех кто им пользуется, но это далеко не все.
Не люблю я сниппеты. Поначалу, когда появились я был в восторге, но потом немного поигрался и не пользуюсь(полагаю не стоит разводить дискуссию ещё и по этому поводу). Я делаю по-другому: написал макрос и теперь объявляю переменную, ставлю на неё каретку, запускаю макрос и он имплементит свойство(убирая хвостик из имени поля ессно...или добавляя если его там нет)
Воооооооот.  |
| Автор: PashaPash 20.8.2009, 16:40 | ||||||
Вред такой же, как и от других префиксов, не несущих смысловой нагрузки - засорение кода. А какая от нее польза?
о, а это идея... Кнопка в решарпере - Reformat Code. Решарпер у меня выжил только ради нее ;)В студии есть что-то похожее, но не настолько глобальное, где-то в Edit.
Если оба подхода - не вручную, то аргумент проперти - длиннее отпадает, так? ;) Мои предпочтения сводятся к тому, что: 1. Легко встраивается в студию 2. Прикручивается к ccnet/msbuild 3. Поддерживает автоматический реформат кода 4. Выдает подробный хелп по каждому нарушению, а не просто "поставь тут пробел!" 5. По возможности написано Microsoft. |
| Автор: diadiavova 20.8.2009, 22:28 | ||||||||||||||
Ну почему "не несущих"? Я ведь написал, что смысл в том, чтобы выделить группу в интеллисенс. Тут вся фишка в том, что этот символ уникален в своём роде. Стандартные идентификаторы как правило начинаются с алфавитных символов, поэтому его удобно использовать для создания групп, которые не будут мельтишить в других классах. Я не всё помечаю этим символом, но когда начал пользоваться этим приёмомпросто заметил, что это удобно и без дополнительных средств помогает вводить меньше кода руками.
Если я правильно понял назначение кнопки, то Edit.FormatDocument. Форматирует в соответствии с настройками студии. Я обычно эту команду вызываю из макросов после вставки, сгенерированного кода. Ну вот пример. Создаю поле
Сгенерированный код свойства получается такой
При этом студия настроена на другой формат. Если после вставки кода вызывается команда форматирования то получается так
Вообще в студии очень много всего и ради одной фичи решарпер держать - это слишком. Проще макрос написать.
Ну про сниппеты я уже сказал. Меня ими пользоваться можешь даже не агитировать
Тут есть нюанс - нарушению правил, определённых им же. Если бы правила можно было определять самому, то это совсем другая песня, а ставить какую-то хандыбу, чтобы она мне указывала "то - не так, да это - не эдак" как-то не хочется. Я понимаю, что хорошо, когда есть подсказка, что ты сделал что-то не так, но в данном случае это просто ничем не оправданное ограничение, причём ограничение на фичу, которая при разумном использованиии оказывается довольно удобной и без дополнительных средств. |
| Автор: mihryak 21.8.2009, 00:00 | ||
есть рекомендуемый code style от собственно создателей, полагаю, что в подавляющем большинстве случаев стоит его придерживаться - это даст по меньшей мере надежду, что код проекта будет понят и не вызовет отторжения у большинства разработчиков тот же StyleCop - детище Microsoft по-моему, весомей аргументации и не надо, а басиковые, плюсовые и другие привычки стоит оставить в басике, плюсах и других языках соответственно http://blogs.msdn.com/brada/articles/361363.aspx код стайл, который практически в том же варианте (различия не касаются конвенций) был использован на прошлом проекте, устраивает полностью |
| Автор: diadiavova 21.8.2009, 00:26 | ||||||||
mihryak, это всё было бы уместным замечанием будь это общепринятыми правилами. И кстати: из самого начала документа
Дотнет - тоже его детище(обсуждалось уже).
Не уверен, что большинство думает так же. Часть разработчиков пользуется одним стилем, часть - другим, большинству "по барабану" как делают другие. Что в этой чёрточке может вызвать отторжение? Стайлкоп что ли ругаться будет? Так я им не пользуюсь.
Использование нескольких языков и так имеет свои неудобства. Усугублять их ещё и разными стилями мне ни к чему. Тот же Брэд Абрамс(кстати кто это   ) из твоей ссылки для васика те же рекомендации даёт.Рекомендации по поводу формата хороши(даже не спорю), но вот только в студии почему-то можно настроить разный формат и по-умолчанию он вроде даже другой(не помню точно перенастраивал или нет), по крайней мере для JScript'а точно другой. Шарповский кодпровайдер тоже почему-то генерит код с другой расстановкой скобок. Пример, который я приводил как автореализацию свойства сгенерирован стандартным дотнетовским провайдером. Поэтому считать это официальным гайдлайном через чур смело. Я уже не говорю о том, что даже официальный гайдлайн - не догма. А то, что это тебя устраивает, так я об этом сразу сказал:"дело вкуса". |
| Автор: Любитель 21.8.2009, 00:37 |
Ну вы и развели тут спор..  Да ещё и в разделе "для новичков". Всех новичков распугаете  |
| Автор: diadiavova 21.8.2009, 00:47 | ||
|
| Автор: Exai1e 22.8.2009, 13:52 | ||
я использую _ в переменных которые объявляются внутри функции, к примеру, как нить так:
как то так =) |
| Автор: diadiavova 22.8.2009, 13:59 | ||
А смысл? Внутри метода можно короткие имена использовать. Я, например, вместо returnValue использую просто rv, и ничего...не путаюсь |
| Автор: PashaPash 23.8.2009, 12:09 | ||||
Смысл и аргументы такие же, как и для твоего _ - допечатка сразу показывает список локальных переменных, и т.д.
Вообще-то можно определять свои правила, и наверняка в нете есть куча готовых FieldNameShouldStartWithUnderscore. Просто меня вполне устраивает стандартный набор. |
| Автор: diadiavova 23.8.2009, 12:34 | ||||
Ну если писать методы на несколько экранов, то возможно да и то...область действия локальной переменной ограничивается блоком и только после того как она объявлена. Здесь запутаться трудно. Хотя до абсурда при желании можно довести всё что угодно.  Я сам стал использовать подчёркивание относительно недавно и мне просто понравился результат. Я не все поля так обзываю, а только те, которые мне нужно видеть в одной куче и нахожу этот способ очень удобным.
Ну то есть это как раз то о чём я и говорил: твои правила хороши если использовать стайлкоп, а не в общем случае. А с этим как бы никто и не спорил И кстати: если взять например те же автоматически реализуемые свойства, то не знаю как это компилится в шарпе, но в бейсике следующей версии для хранения значения таких свойств создаётся переменная именно по таким правилам, о которых я написал. Это что касается гайдлайнов. Я, конечно понимаю, что это бейсик, но в http://blogs.msdn.com/brada/articles/361363.aspx для бейсика те же правила(как это не смешно) http://msdn.microsoft.com/en-us/library/dd293589%28VS.100%29.aspx |
| Автор: Exai1e 24.8.2009, 01:38 | ||
Смысл в том, что сразу заметны "внутренние переменные", мне так удобнее Ну я например не люблю которые, бессмысленные имена переменных. |
| Автор: Любитель 24.8.2009, 03:35 | ||||
Как-то так:
|
| Автор: diadiavova 24.8.2009, 03:47 | ||
Ну рефлектор так и показывает, только что это значит на самом деле - фиг знает. |
| Автор: Любитель 24.8.2009, 10:24 |
| Всмысле? В сборке такие имена и есть. Ты спросил во что преобразуются в шарпе автопроперти - я ответил. Или тебя смущают знаки меньше/больше? Так можно имя и пустой строкой сделать, и цифрой, и пробелом (подобными извращениями обфускаторы очень любят заниматься) - на уровне метаданных сборки (простейший способ поиграться - Mono.Cecil). Для шарп-кода это было бы невалидно, конечно. |
| Автор: diadiavova 24.8.2009, 11:22 |
| Любитель, ну просто в васике можно было так же сделать, а они вместо этого намутили хрень. |
| Автор: PashaPash 25.8.2009, 17:57 | ||||||
diadiavova, оживим тему:
Аналог для C#: http://msdn.microsoft.com/en-us/library/w86s7x04(VS.100).aspx - без подчеркиваний.
Если использовать поля (а не свойства по всему классу, на нескольно экранов ;), то возможно что _ и нужно. А вообще область применения поля ограничивается get/set соотв. свойства. Цепочка "я не использую свойства <- они длинее на 10 символов <- я не пользуюсь сниппетами <- просто не пользуюсь и все". "Просто захотелось", и теперь везеде в коде надо вписывать на один символ больше.
Автореализуемые свойства - это проблема компилятора, он не заморачивается на читабельности. Стиль нужен для кода который пишут люди и сопровождают люди. Мегаклассы для анонимных делегатов и типов - не повод писать вообще как попало и называть методы c1____aaa__111. |
| Автор: diadiavova 25.8.2009, 19:01 | ||||||||||||
Зачем? 
Это были просто иллюстрации того, что приём используется.
Это ты о чём? Там речь вроде как шла о применении приёма внутри методов. Метод на несколько экранов - ни есть хорошо. Или ты не согласен?
Да это как сказать. Иногда в сеттере выполняются действия, которых надо избежать при внутреннем обращении.
Сниппетами не пользуюсь потому, что не нахожу их удобными. В целом мой подход позволяет меньше вводить руками. Если бы предлагаемый тобой способ был короче, то я - не догматик, но поскольку пробовал разные приёмы и в данный момент остановился на этом, как на более удобном. И ещё: стараюсь минимизировать использование одноимённых идентификаторов в одной области видимости, это может запутать не только человека, но и машину. Поэтому в принципе считаю регистрозависимость плохой идеей. Возможно мои предпочтения отчасти обусловлены и этим обстоятельством. |
| Автор: PashaPash 25.8.2009, 19:41 | ||||||||||
да скучно...
что прием используется в VB и с сгенеренном компилятором коде. Ни то ни другое отношения к стилю человеческого когда на C# не имеют.
Я пытался по аналогии для полей описать ситуацию.
Тогда иногда можно называть поля с _ .
"Меньше вводить" увеличивается на 1 при каждом использовании, а их будет минимум 2. Ведь ты не экономишь символы, используюя public-поля вместо свойств. Почему тогда экономишь на private, потенциально добавляя проблем следующему разработчику? Проперти удобнее полей по ряду причин. Хотя бы просто из-за возможности поставить breakpoint. Ситуация "где-то в классе на 9000 строк меняется значение поля на X, и надо как-то найти где и в какой момент" не слишком редкая. Если подход короче в написании, но сложнее в поддержке - это плохой подход |
| Автор: diadiavova 25.8.2009, 20:03 | ||||||||||||||||||
А почему ты никогда во флейме не появляешься? Там весело.
О человеческих стилях я сказал уже.
Не понял...ну да ладно.
А я так и делаю. Когда удобно - называю. У меня не все поля такие.
При использовании я практически только его и ввожу, потом появляется интеллисенс. Сопсно ради этого всё и делается.
Ну я ведь уже упоминал о волшебном макросе
О каких проблемах речь?
Внешние не только удобнее но и безопаснее, на счёт внутренних я бы поспорил.
Внутри класса при необходимости это легко изменить...и не обязательно руками. |
| Автор: PashaPash 25.8.2009, 20:21 | ||||||||||
Я делаю флейм вокруг себя ;)
А интеллисенс нужен чтобы обратиться именно к полю, а не свойству. Не слишком частая ситуация, чтобы вводить ради нее стиль с _. Особенно с учетом сниппетов волшебного макроса.
О проблемах "он не получит все плюшки свойств".
Легко, если ты дебагаешь локальное приложение на локальной машине, и вообще можешь менять исходники. И даже в этом случае надо пересобрать/перезапустить/повторить (а пока компилируется/стартует - полазить по нету и по форумам). Впрочем, у каждого свои критерии удобности и соотношенеи свой код в редакторе/чужой код в дебаге. У меня что-то в последнее время 2-е перевешивает :( |
| Автор: diadiavova 25.8.2009, 20:54 | ||||||||||
К прайвит члену, к которому нужно обращаться неоднократно.
Да вообще-то частая
Ещё раз повторю, что я избегаю ситуаций с именами, отличающимися только регистром. Не смотря на то, что в шарпе это можно - иногда боком вылазит. Ошибку связанную с регистром легко не заметить. Поэтому именовать поля, хранящие значения свойств я всё-таки предпочитаю в любом случае по-разному.
Давай всё-таки определимся о чём мы говорим, об именовании или о об использовании свойств вместо полей во всех областях видимости. Это разные темы. Я уже несколько раз пытался выяснить какие проблемы у других разработчиков могут вызвать эти "хвостики", но ответа так и не получил. Видимо это всё-таки просто вопрос привычки и не более.
Ну я здесь опять-таки не настаиваю на определённой модели, когда это надо, то можно и свойства использовать, но иногда это просто лишнее. Если это вспомогательные поля, для промежуточных данных, то какой если это будут свойства? А объявить их можно кучу за раз, со свойствами же такое не прокатит. |
