Отступы — табуляция. Рекомендуется так же включать visible whitespaces и не оставлять в коде пробельный мусор.
Имена типов и публичных членов — PascalCasing
Имена приватных членов — camelCasing с префиксом '_'
Имена параметров и локальных переменных — camelCasing
Максимальная длина строк — 120 символов.
Дополнительные требования к коду
Обязательно наличие doc comments к публичному API
Для любого нетривиального кода должны быть тесты хотя бы по основным use cases
Желательно использование решарпера и разметка кода Jetbrains.Annotations. Прежде всего это касается NotNull/CanBeNull.
Cтарайтесь максимально использовать конструкции языка, улучшающие читаемость кода: var, expression bodied members, string interpolation
Обязательно никаких warnings компилятора, и очень желательно никаких warnings решарпера. Если у вас нет лицензии на решарпер — используйте хотя бы бесплатные Resharper Command Line Tools.
В Main проект помещайте только тот код, в полезности которого вы абсолютно уверены.
Здравствуйте, xy012111, Вы писали:
X>Как на счёт предложения отказаться от использования публичных (статических) полей и предпочитать им свойства? X>Поля это всё ж некоторые инструменты (детали) реализации, а в интерфейсе самое место свойствам.
Честно говоря не вижу никакой существенной разницы между readonly полем и свойством.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Тогда имя надо другое. As вводит в заблуждение. R>>Можно, а какое? AVK>ХЗ. ToArray занято. MakeArray, CastToArray?
Чего вы мучаетесь? AsArray, AsList используется уже в куче проектов, которые я видел. Никаких проблем. Вообще.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
X>>Как на счёт предложения отказаться от использования публичных (статических) полей и предпочитать им свойства? X>>Поля это всё ж некоторые инструменты (детали) реализации, а в интерфейсе самое место свойствам.
AVK>Честно говоря не вижу никакой существенной разницы между readonly полем и свойством.
Здравствуйте, xy012111, Вы писали:
X>>>Как на счёт предложения отказаться от использования публичных (статических) полей и предпочитать им свойства? X>Как минимум тут, Field Design, первый же пункт:
FDG надо читать, а не просто цитировать.
DO NOT provide instance fields that are public or protected.
Причём читать медленно и методично, ибо воды в ней нет совсем и плотность информации на страницу откровенно зашкаливает. И, главное, читать до конца:
DO use public static readonly fields for predefined object instances.
If there are predefined instances of the type, declare them as public readonly static fields of the type itself.
... DO NOT assign instances of mutable types to readonly fields.
Здравствуйте, Sinix, Вы писали:
X>>>>Как на счёт предложения отказаться от использования публичных (статических) полей и предпочитать им свойства? X>>Как минимум тут, Field Design, первый же пункт:
S>FDG надо читать, а не просто цитировать.
Избавьте. Не читать нужно, а понимать. И не только смысл, но и причины.
Вы, видимо, даже смысл не совсем поняли и на вопрос "почему скобочки вокруг статических" ответить не смогли бы. А, наприммер, вот почему.
Вообще, и статические поля совсем не нужны, тем более когда есть возможность инициализации свойста при объявлении. Не верите? Какой-нибудь EqualityComparer<>.Default выглядит со всех сторон намного лучше, чем что-то вроде Decimal.Zero Field.
Требование же о неизменячемости типа readonly полей совершенно бредово: его выполнение приводит к запрету
Здравствуйте, xy012111, Вы писали: X>Вы, видимо, даже смысл не совсем поняли и на вопрос "почему скобочки вокруг статических" ответить не смогли бы. А, наприммер, вот почему.
Вот тут всё правильно — публичных readonly полей у инстансов быть не должно. Причина бага — код в experimental, там за рекомендациями никто особо не следит. Автору напишите
X>Вообще, и статические поля совсем не нужны, тем более когда есть возможность инициализации свойста при объявлении. Не верите? Какой-нибудь EqualityComparer<>.Default выглядит со всех сторон намного лучше, чем что-то вроде Decimal.Zero Field.
Неправильно. Потому что public static readonly field даёт кучу гарантий, которое от свойств не получить никак. Чтоб не углубляться: достаточно гарантированно рабочего ReferenceEquals + оптимизаций jit
Здравствуйте, xy012111, Вы писали:
X>Вообще, и статические поля совсем не нужны
Чего то я не пойму. Только что ты FDG выставлял как истину в последней инстанции, а как почитали повнимательнее — предлагаешь прямо противоречить его рекомендациям. Ты уж как нибудь определись.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
X>>Вообще, и статические поля совсем не нужны
AVK>Чего то я не пойму. Только что ты FDG выставлял как истину в последней инстанции, а как почитали повнимательнее — предлагаешь прямо противоречить его рекомендациям. Ты уж как нибудь определись.
С чего вы взяли, что я выставлял её как истину в последней инстанции?
Я лишь привёл пример точки зрения, которая делает различие между одним и другим. Вы же не категорически высказались против, не привели никакой причины, а лишь сказали, что не видите существенной разницы. Ну если вы не видите, то я показал, что видят, как минимум, другие. Чего тут не понятного? Дело хозхяйское, куда смотреть и смотреть ли вообще и что считать существенным.
/* Вот NRE из CodeJam пользователь может огрести из ста тыщ пятиста мест, если для вас это не существенно, если такая забота об аргументах, по вашему мнению, должна делаться клиентом, ваше право ;о) Но и тут многие с вами не согласятся */
Вот если не сочтёте за труд посмотреть на BCL, то сможете заметить, что мест, где наружу торчат экземплярные поля раз-два и обчёлся. Я вот даже и не припомню ни одного.
Относительно статических полей немного другая картина: кой-где, даже много где, они торчат. Но или со времён ещё первого дотнета, когда ни о каких гайдлайнах не слышали и, быть может, вовсе не задумывались о каком-то дизайне, или по другим причинам. Скорее всего, просто из-за невозможноси проинициализировать свойство при объявлении. Разносить инициализацию и объявление, при необходимости объявлять, к примеру, десятки DependencyProperty и ключей к ним действительно проблема.
Но некоторые хорошие люди (в BCL) и тут не ленятся делать более правильные во всех отношениях свойства, пример я привёл и их ещё не мало, а уж в шестом шарпе вообще ничто не должно останавливать.
Я для себя это объясняю просто — поле это нечто "физическое", "способ реализации" который не здорово выставлять наружу. А вот свойство — это некий контракт. Извне, пользователям типа, не важен способ реализации, необходим только контракт. Так и не нужно им пихать поле когда достаточно дать свойство.
Здравствуйте, xy012111, Вы писали:
AVK>>Чего то я не пойму. Только что ты FDG выставлял как истину в последней инстанции, а как почитали повнимательнее — предлагаешь прямо противоречить его рекомендациям. Ты уж как нибудь определись. X>С чего вы взяли, что я выставлял её как истину в последней инстанции?
Ну ты же, вместо того чтобы самому ответить на простой вопрос — зачем делать поля свойствами — привел ссылку на FDG. Мол, раз там написано, то надо не рефлексировать, а исполнять.
X>Я лишь привёл пример точки зрения, которая делает различие между одним и другим.
Понимаешь какое дело, чем с точки зрения дизайна отличаются поля и своййства экземпляра я понимаю — поля не являются частью формального контракта типа и их нельзя вынести в базовый класс или интерфейс. А вот чем не угодили статические поля — я пока ответа не видел, одни эмоции: бредово, ересь, для дураков.
X> Вы же не категорически высказались против, не привели никакой причины, а лишь сказали, что не видите существенной разницы. Ну если вы не видите, то я показал, что видят, как минимум, другие.
Ну мало ли кто что видит. Некоторые рептилоидов с Нибиру видят. Мне интересны не видения, а логическое обоснование. Мой опыт пока не выявил каких то недостатков static readonly полей.
X>Вот если не сочтёте за труд посмотреть на BCL, то сможете заметить, что мест, где наружу торчат экземплярные поля раз-два и обчёлся.
Да и в CodeJam из совсем немного. И ровно 100% их укладываются в:
DO use public static readonly fields for predefined object instances.
X> Я вот даже и не припомню ни одного.
Ну ты не припомнишь, я припомню. Мы сейчас что обсуждаем — память?
X>Относительно статических полей немного другая картина:
А ты сейчас про какие? В CodeJam есть публичные нестатические поля? Таких полей там ровно в одном месте в экспериментальной части.
X>Но или со времён ещё первого дотнета, когда ни о каких гайдлайнах не слышали и, быть может, вовсе не задумывались о каком-то дизайне, или по другим причинам.
Какой прекрасный аргумент. Подходит практически к любой ситуации.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Чего то я не пойму. Только что ты FDG выставлял как истину в последней инстанции, а как почитали повнимательнее — предлагаешь прямо противоречить его рекомендациям. Ты уж как нибудь определись. X>>С чего вы взяли, что я выставлял её как истину в последней инстанции? AVK>Ну ты же, вместо того чтобы самому ответить на простой вопрос — зачем делать поля свойствами — привел ссылку на FDG. Мол, раз там написано, то надо не рефлексировать, а исполнять.
Ну то есть сами придумали, чего не было написано, а виноват я?
X>>Я лишь привёл пример точки зрения, которая делает различие между одним и другим. AVK>Понимаешь какое дело, чем с точки зрения дизайна отличаются поля и своййства экземпляра я понимаю — поля не являются частью формального контракта типа и их нельзя вынести в базовый класс или интерфейс. А вот чем не угодили статические поля — я пока ответа не видел, одни эмоции: бредово, ересь, для дураков.
Я написал же. Есть такое понятие "статический интерфейс" в смысле "интерфейс" — это то, с помощью чего клиент работает с типом, а не interface. И мне гораздо проще считать, что наружу торчат свойства, чем в случае экземпляра наружу в основном свойства или в эксперементал может быть и поля, а в случае статики — только поля ну или свойства если так захотелось. "Всегда наружу свойства" проще и понятнее, тем более, если технически разницы нет :о) Это основной поинт.
X>> Вы же не категорически высказались против, не привели никакой причины, а лишь сказали, что не видите существенной разницы. Ну если вы не видите, то я показал, что видят, как минимум, другие. AVK>Ну мало ли кто что видит. Некоторые рептилоидов с Нибиру видят. Мне интересны не видения, а логическое обоснование. Мой опыт пока не выявил каких то недостатков static readonly полей.
Спасибо, это была очень важная реплика в таком техническом вопросе. Причем я пытиался с помощью отвлечения описать предмет спора, а вы — мой комментерий. Продолжайте дальше в таком виде вести дискуссию и люди к вам, несомненно, понятянуся.
X>>Вот если не сочтёте за труд посмотреть на BCL, то сможете заметить, что мест, где наружу торчат экземплярные поля раз-два и обчёлся. AVK>Да и в CodeJam из совсем немного. И ровно 100% их укладываются в:
AVK>DO use public static readonly fields for predefined object instances.
Ну я не знал, что в эксперементальной части у вас другие гайдлайны. Мне такой подход ещё более не понятен. Мне понятен подход бармена из анекдота про нежеление сбивать руку. А ваш — нет.
X>> Я вот даже и не припомню ни одного. AVK>Ну ты не припомнишь, я припомню. Мы сейчас что обсуждаем — память?
Ну и могли бы хоть один привести А обсуждаем мы другое, общеупотребильность этого подхода. Если в BCL так (в основном) не делают, только в некоторых местах, разработчики которых почему-то специально так решили или просто не подумали, то может и тут не стоит? И на всякий случай я там имел в виду именно публичные экземплярные поля.
X>>Относительно статических полей немного другая картина: AVK>А ты сейчас про какие? В CodeJam есть публичные нестатические поля? Таких полей там ровно в одном месте в экспериментальной части.
Мне, когда смотрел код, достаочно было увидеть в одном месте, что бы озадачиться. Надо было всё перечитать прежде чем написать?
X>>Но или со времён ещё первого дотнета, когда ни о каких гайдлайнах не слышали и, быть может, вовсе не задумывались о каком-то дизайне, или по другим причинам. AVK>Какой прекрасный аргумент. Подходит практически к любой ситуации.
Вам поспорить, или разобраться?
Если второе, то лучший способ — сравнить самому код Comparer(of T) и Comparer.
Если не очевидно,
2all: сорри за спойлер
Создание Comparer<T> включает в себя эмит кода для генерик-класса и должно выполняться лениво, не блокируя другие потоки.
В случае с полем инициализация выполнялась бы при первом обращении к самому типу (точнее, не позже чем, там beforefieldinit емнип) и завешивала бы все потоки, пытающиеся обратиться к этому типу, включая наследников Comparer<T>.
Если вам интересно — вы во-первых спрашивайте вопросы нормально, не изображая владельца тайного знания, а во-вторых — в профильном разделе. Всегда вэлкам
Здравствуйте, Sinix, Вы писали:
X>>Если нужна пища для размышления, сравните Comparer.Default Field и Comparer<T>.Default Property. Почему в старой ламповой версии так, а в более современной сяк?
S>Вам поспорить, или разобраться?
Спилите мушку.
S>Если второе, то лучший способ — сравнить самому код Comparer(of T) и Comparer.
Ну наконец-то! Теперь представьте ситуёвину: у вас торчит наружу открытое статическое поле, а в новой версии библиотеки вы вдруг понимаете, что сделав ленивое вычисление значения, присваевоемого этому полю, вы можете что-то улучшить в возвращаемом значении. И приходится либо терять совместимость либо пристраивать костыли. А свойство рррраз! И всё. В любой момент внутренности можно как угодно допилить.
А вот обратного примера, когда потребовалась бы замена свойства на поле я не знаю. Поэтому наружу только свойства. Это проще запоминать, всегда можно до-пере-пилить. Ни одного преимущества у полей нет. У свойств они, пускай, не очевидны и не всегда нужны, но всё же есть.
S>Если вам интересно — вы во-первых спрашивайте вопросы нормально, не изображая владельца тайного знания, а во-вторых — в профильном разделе. Всегда вэлкам
Здравствуйте, xy012111, Вы писали:
X>Ну наконец-то! Теперь представьте ситуёвину: у вас торчит наружу открытое статическое поле, а в новой версии библиотеки вы вдруг понимаете, что сделав ленивое вычисление значения, присваевоемого этому полю, вы можете что-то улучшить в возвращаемом значении.
Просто прочтите наконец 5.5 Field design, главка на страницу. Там даже пример, что такое "predefined object instance" есть. И сразу ниже этого абзаца — рекомендация на случай, если значение будет меняться.
А то ваши возражения пока выглядят вот так вот: матчасть не читал, но мнение имею.
Без обид
X>А вот обратного примера, когда потребовалась бы замена свойства на поле я не знаю.
Огосспидя, вы когда начинаете спорить — забрало не опускайте
Ответы вам пишут не для переспорить, а подкинуть информацию для размышлений. Сценарии, когда свойство не заменит поле, я приводил выше.
Здравствуйте, xy012111, Вы писали:
X>Ну то есть сами придумали, чего не было написано, а виноват я?
Что значит придумали? Поясни тогда, почему ты в ответ на просьбу обосновать привел ссылку на FDG? Зачем ты это сделал?
X>Я написал же.
Ты написал только свои ощущения. Ну я понял, что тебе не нравится. А что нибудь объективное есть?
X> Есть такое понятие "статический интерфейс" в смысле "интерфейс" — это то, с помощью чего клиент работает с типом, а не interface.
Понятие то есть, но какой в нем, в контексте дотнета, смысл? И почему в него не входят публичные поля?
X> И мне гораздо проще считать, что наружу торчат свойства, чем в случае экземпляра
Давай все таки обсуждение экземплярных полей вынесем за рамки.
X>а в случае статики — только поля ну или свойства если так захотелось. "Всегда наружу свойства" проще и понятнее
Ну вот лично мне — нет, не проще. Никакой практически заметной разницы между статическими полями и статическими свойствами я пока не обнаружил. Если эта разница есть, причем не на уровне нравится/не нравится, а объективно — с удовольствием послушаю.
X>, тем более, если технически разницы нет :о)
Я бы не был на 100% уверен. Работа дотнетного оптимизатора — дело темное. Тут вон совсем недавно в CodeJam AgressiveInlining добавляли, хотя, казалось бы, разницы быть не должно.
AVK>>Да и в CodeJam из совсем немного. И ровно 100% их укладываются в: X>
AVK>>DO use public static readonly fields for predefined object instances.
X>Ну я не знал, что в эксперементальной части у вас другие гайдлайны.
Экспериментальная часть потому и экспериментальная, что код там не доведен до production состояния. А гайдлайны там те же.
X>Ну и могли бы хоть один привести А обсуждаем мы другое, общеупотребильность этого подхода. Если в BCL так (в основном) не делают,
В BCL именно так и делают. К примеру:
public static readonly DateTime MinValue
X> только в некоторых местах, разработчики которых почему-то специально так решили или просто не подумали, то может и тут не стоит?
Я вот тебе просто рекомендую — не стоит "не подумали" считать объяснением тех или иных решений в фреймворке. Не, там есть конечно и косяки, но их очень очень мало. И уж точно то что написано в FDG прямым текстом "не подумали" считать не следует.
X> И на всякий случай я там имел в виду именно публичные экземплярные поля.
Мне еще сколько раз надо написать про экземплярные поля чтобы ты уже про них не поминал?
AVK>>А ты сейчас про какие? В CodeJam есть публичные нестатические поля? Таких полей там ровно в одном месте в экспериментальной части. X>Мне, когда смотрел код, достаочно было увидеть в одном месте, что бы озадачиться. Надо было всё перечитать прежде чем написать?
Если нам не помогут, то мы тоже никого не пощадим.
