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, и надо как-то найти где и в какой момент" не слишком редкая. Если подход короче в написании, но сложнее в поддержке - это плохой подход