Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.fds-net.ru/showflat.php?Number=8311857&src=arc&showlite=l
Дата изменения: Unknown Дата индексирования: Tue Feb 26 22:21:22 2013 Кодировка: Windows-1251 |
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: это настраивается. Я пользуюсь тем, который показывает оба. | ||
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: и, вместо четырех строчек, будет одна: code:, с одним упоминанием _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: Тк это если вам не нужна _state, например, в случае lazy инициализации, да и то не всегда. Но менять naming convention специально для lazy инициализации глупо. Поскольку это увеличивает объем правил в naming convention, если идти по этому пути они просто распухнут и их никто не будет соблюдать. Каждый будет помнить свои правила, и читать друг друга будет сложнее. К тому же, какой аргумент более весомый 1. калечить имя переменной 2. увеличивается вероятность ошибки при выборе из списка auto-completion для меня не очевидно. Для меня читаемость кода стоит на первом месте, относительно сложности написания. | ||
Shurik
[re:penartur2] 31.01.2009 02:40 | Reply | Edit | | 0 | |
Quote: минусов от их использования больше, чем плюсов | ||
penartur2
[re:Shurik] 31.01.2009 02:44 | Reply | Edit | | -1 | |
В ответ на: Досконально, не задумываясь, следовать каким-то общим гайдлайном, придуманным кем-то довольно левым по отношению к команде разработчиков, даже тогда, когда от этого много вреда и никакой пользы - гораздо более глупо. В ответ на: Читаемость кода определяется не только "калеченьем" имени переменной (и это еще большой вопрос, является ли "_" калеченьем). Когда у тебя две переменные, названия которых отличаются регистром - читаемость гораздо хуже. Кроме того, читаемость очень тесно связана с модифицируемостью, а модифицируемость от твоего варианта очень сильно страдает. Причем допущенные таким образом ошибки не приведут к 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 | |
В ответ на: Ну и зачем городить велосипед? | ||
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: Почему здесь это оправдано. Разработчики языка не реализовали востребованный в реальных проектах принцип Dataflow. В собственной реализацией полноценного синтаксического сахара я ввести не могу, поэтому приходится эмулировать его через метод с именем "_" и такую же переменную. | ||
Shurik
[re:penartur2] 31.01.2009 20:33 | Reply | Edit | | 0 | |
Quote: вчера не внимательно посмотрел на твою обертку. Если уж заморачиваться оберткой, тогда пусть обертка полностью скрывает переменную, которая хранит данные code: P.S. я бы еще перенес Func<T> func из аргумента метода GetValue в аргумент конструктора класса LazyProxy. Тогда переменную stateProxy надо будет инициализировать в конструкторе класса, для меня это не вызывает никаких проблем, но вы же начнете считать строчки, и их окажется на две больше, поэтому я привел этот вариант в качестве демонстрации. Редактировал Shurik (31.01.2009 21:53) | ||
Top | след. страница |