Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.fds-net.ru/showflat.php?Number=8311857&src=arc&showlite=l
Дата изменения: Unknown
Дата индексирования: Tue Feb 26 22:21:22 2013
Кодировка: Windows-1251
C# code style: подчеркивания в именах переменных - Public forum of MSU united student networks
Technical >> Development (Archive)

Страницы: 0 | 20 | 40 | (41) | 60 | показать все | след. страница
Kai : Re: Пара мыслей по поводу C# code style  [re:Shurik]   31.01.2009 02:14    | Reply | Edit |
8
Напротив, auto-completion не будет находить _state, если специально не искать, и это хорошо.

Shurik   [re:penartur2]   31.01.2009 02:17    | Reply | Edit |
0
Quote:

В чем, по-твоему, суть рекомендации не использовать подчеркивания в именах переменных? Какие причины этой рекомендации?



отвечаешь вопросом на вопрос?

penartur2   [re:Shurik]   31.01.2009 02:18    | Reply | Edit |
-1
Мне нужно уточнить кое-что, прежде чем отвечать на твой вопрос. Тебе в этом что-то не нравится?

Shurik   [re:penartur2]   31.01.2009 02:18    | Reply | Edit |
0
Quote:

Кстати, твой auto-completion при нажатии на большую S покажет и state, и State? Или только State?



это настраивается. Я пользуюсь тем, который показывает оба.

Shurik   [re:penartur2]   31.01.2009 02:19    | Reply | Edit |
0
Quote:

Тебе в этом что-то не нравится?



да, потому что твой вопрос слишком общего характера, и мне долго формулировать на него полный ответ.

penartur2   [re:Shurik]   31.01.2009 02:25    | Reply | Edit |
1
Тогда твой вариант не катит.
Потому что гораздо легче допустить ошибку в твоем варианте, выбрав не то поле там, где надо использовать State - чем с подчеркиванием в тех трех расположенных рядом строчках, где оно используется.
ЗЫ: А еще можно все заврапить как-то вроде:
code:
static class Util { public static T LazyGet<T>(Func<T> calculator, ref T field) { if(field == null) field = calculator(); return field; } }

и, вместо четырех строчек, будет одна:
code:
return Util.LazyGet<string>(() => LoadState(), this._state);
, с одним упоминанием _state. Если учесть, что она еще и должна быть расположена не далее, чем в двух-трех строчках от определения _state, то вероятность ошибиться сводится практически к нулю.
Если же называть их state и State, а intellisense будет показывать оба варианта - ты сможешь ошибиться везде, где используешь State внутри этого класса, а таких мест может быть неограниченно много.

penartur2   [re:Shurik]   31.01.2009 02:26    | Reply | Edit |
-1
Попробуй ответить хоть как-то. Потому что ответ на этот вопрос - ключевой для дальнейшего обсуждения, без него непонятна твоя точка зрения.

Shurik   [re:Kai]   31.01.2009 02:36    | Reply | Edit |
0
Quote:

Напротив, auto-completion не будет находить _state, если специально не искать, и это хорошо.



Тк это если вам не нужна _state, например, в случае lazy инициализации, да и то не всегда. Но менять naming convention специально для lazy инициализации глупо. Поскольку это увеличивает объем правил в naming convention, если идти по этому пути они просто распухнут и их никто не будет соблюдать. Каждый будет помнить свои правила, и читать друг друга будет сложнее.

К тому же, какой аргумент более весомый
1. калечить имя переменной
2. увеличивается вероятность ошибки при выборе из списка auto-completion
для меня не очевидно.

Для меня читаемость кода стоит на первом месте, относительно сложности написания.

Shurik   [re:penartur2]   31.01.2009 02:40    | Reply | Edit |
0
Quote:

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



минусов от их использования больше, чем плюсов :grin:

penartur2   [re:Shurik]   31.01.2009 02:44    | Reply | Edit |
-1
В ответ на:

Но менять naming convention специально для lazy инициализации глупо.



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

Для меня читаемость кода стоит на первом месте



Читаемость кода определяется не только "калеченьем" имени переменной (и это еще большой вопрос, является ли "_" калеченьем). Когда у тебя две переменные, названия которых отличаются регистром - читаемость гораздо хуже.
Кроме того, читаемость очень тесно связана с модифицируемостью, а модифицируемость от твоего варианта очень сильно страдает. Причем допущенные таким образом ошибки не приведут к 100% фатальному падению программы (не говоря уж о ругани редактора/компилятора), а будут приводить к фатальному падению только иногда, когда перед тем, как обратиться к state, не обратились к State - а это еще хуже. Ладно бы, у state и State были разные типы, а когда они отличаются только значением (да и то - иногда) и регистром - это использование нехороших неявных фич языка. То, что имена переменных чувствительны к регистру - далеко не очевидно с простой житейской точки зрения (как и обратное), так что не стоит этим пользоваться в сторону неочевидности (т.е. в языке с чувствительностью регистра заводить state и State, а в языке с нечувствительностью - обращаться к state как к State).

penartur2   [re:Shurik]   31.01.2009 02:44    | Reply | Edit |
-1
В ответ на:

минусов от их использования больше, чем плюсов



Это ты про гайдлайны? Ну и не используй, о чем разговор?

Shurik   [re:penartur2]   31.01.2009 02:48    | Reply | Edit |
0
про подчеркивания и т.п.

Shurik   [re:penartur2]   31.01.2009 02:48    | Reply | Edit |
1
Quote:

Кроме того, читаемость очень тесно связана с модифицируемостью, а модифицируемость от твоего варианта очень сильно страдает.



чего?

Shurik   [re:penartur2]   31.01.2009 02:58    | Reply | Edit |
0
Quote:

не говоря уж о ругани редактора/компилятора),



имхо, для ReSharper-а можно ввести атрибут анотации, и написать небольшой плагинчик, который будет следить за тем, чтобы обращение к state было только внутри одного свойства. Думаю, что это займет не более одного дня. Возмоюжно, такое уже есть.

penartur2   [re:Shurik]   31.01.2009 11:40    | Reply | Edit |
0
В ответ на:

имхо, для ReSharper-а можно ввести атрибут анотации, и написать небольшой плагинчик, который будет следить за тем, чтобы обращение к state было только внутри одного свойства. Думаю, что это займет не более одного дня. Возмоюжно, такое уже есть.



Ну и зачем городить велосипед?

penartur2   [re:Shurik]   31.01.2009 11:43    | Reply | Edit |
-1
В ответ на:

про подчеркивания и т.п.



Какие минусы от их использования кроме того, что они нарушают гайдлайны?
Потому что гайдлайны - это всего лишь рекомендации, и какие причины таких рекомендаций, ты не сказал.
В ответ на:

Заставь дурака Богу молиться, он и лоб расшибет




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

Shurik   [re:penartur2]   31.01.2009 13:27    | Reply | Edit |
0
Quote:

Ну и зачем городить велосипед?



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

Shurik   [re:penartur2]   31.01.2009 13:35    | Reply | Edit |
0
Quote:

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



Надеюсь ты понимаешь, что
1. исходники не должны быть привязаны к команде разработчиков.
2. разработчики перетекают из команды в команду, и осваение тонкостей naming convention, подобных этой, будет занимать много времени, к тому же разработчику это скушно, а проконтролировать все ли он усвоил сложно.

Твои аргументы против моих в этом треде сводятся к "на вкус и цвет товарищей нет". Для таких ситуаций и сделаны документы от создателей, у которых выделенная роль.

Shurik   [re:Shurik]   31.01.2009 13:56    | Reply | Edit |
0
и вообще, это все системные вещи уровня языка, соответственно, правила игры тут устанавливают разработчики языка. В Nemerle вроде есть механизм инкапсуляции поля внутрь свойства, а разработчики C# видимо посчитали это некритичным моментом. Так вот, идти против разработчиков языка достаточно опасное занятие, и надо иметь достаточно веские обоснования для этого. То, что можно перепутать state и State при автокомплите, это не катит как убедительный аргумент.

Когда это оправдано, я и сам меняю naming convention, например, в моем проекте Property Expression, название метода состоит из одного подчеркивания "_".
code:
it => it._(_ => _.A001).Add(it._(_ => _.A007))

Почему здесь это оправдано. Разработчики языка не реализовали востребованный в реальных проектах принцип Dataflow. В собственной реализацией полноценного синтаксического сахара я ввести не могу, поэтому приходится эмулировать его через метод с именем "_" и такую же переменную.

Shurik   [re:penartur2]   31.01.2009 20:33    | Reply | Edit |
0
Quote:

А еще можно все заврапить как-то вроде



вчера не внимательно посмотрел на твою обертку. Если уж заморачиваться оберткой, тогда пусть обертка полностью скрывает переменную, которая хранит данные
code:
private readonly LazyProxy<string> stateProxy = new LazyProxy<string>(); public string State { get { return stateProxy.GetValue(LoadState); } } ... public class LazyProxy<T> where T : class { private T value; public T GetValue(Func<T> func) { if (value == null) { value = func(); } return value; } }


P.S. я бы еще перенес Func<T> func из аргумента метода GetValue в аргумент конструктора класса LazyProxy. Тогда переменную stateProxy надо будет инициализировать в конструкторе класса, для меня это не вызывает никаких проблем, но вы же начнете считать строчки, и их окажется на две больше, поэтому я привел этот вариант в качестве демонстрации.



Редактировал Shurik (31.01.2009 21:53)
Top | след. страница