Вопросы по стандарту кодирования С# Juval Lowy

Ответ 1

Нет. 26: Сила двух средств, которые вы хотите использовать перечисление как битовая маска (флаги). Это единственная причина для указания значений перечисления. Для добавления новых участников позже вы все равно можете добавить их к определению перечисления без изменения существующих значений. Нет причин помещать их между существующими членами.

Нет. 34: Я думаю, он хочет избежать ситуации, когда у вас есть массив, содержащий (частично) неинициализированные указатели (нулевые ссылки). Как потребитель массива его заманчиво  не проверять нулевые записи в допустимой переменной массива.

Ответ 2

Хорошо, поэтому я в основном покрою небольшую репутацию у меня на stackoverflow: вы можете убить меня для открытия религиозных дебатов.

Подсказка по работе с стандартом Juval code действительно находится в этом предисловии:

"Я считаю, что при полном понимании каждого понимания, которое входит в конкретное решение по программированию, может потребоваться чтение книг и даже многолетний опыт, применение стандарта не должно".

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

Что вас не удовлетворило?

Ключевым моментом здесь является осознание того, что это не религиозный рассказ, он действительно прагматичный.

Мой личный опыт с его стандартом в значительной степени: Если вы будете следовать советам, как можете, вы получите продуктивный результат. Ваши потребности в рефакторинге будут меньше, производительность в более поздних циклах проекта будет выше.

Это оценка, основанная на опыте.

В основном то, что вы ищете, - это ответы на "почему" некоторые части стандарта кодирования находятся там, в частности: 26, 34, 50, 52, 73, 74

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

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

О том, как следовать стандарту

Действительно читайте правила в качестве советов, они уже очень строго сформулированы: "Избегайте, не делайте и так далее", действительно означает, что они говорят. Избегайте средств "думать очень тяжело, прежде чем нарушать принцип". "Не нужно" на самом деле означает "не надо".

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

Иногда это сложно сделать с командой, которая работает в менее абстрактных терминах или в более ориентированных на объекты средах, поэтому иногда вам может потребоваться разорвать правила, "чтобы заставить команду двигаться", но вам действительно нужно реорганизовать это соответствует стандарту, когда вы можете это сделать.

Через несколько лет, еще несколько проектов, вы, возможно, придете к пониманию обоснования для каждого правила в простом руководстве. Если вы классный ученик. Я, я не такой яркий, поэтому я основываю его на опыте: материал, который находится в нестандартизированных частях кода, часто терпит неудачу во время тестирования интеграции. С ним часто бывает сложно вернуться. Он часто плохо связан с окружающей средой и т.д.

Это действительно вопрос доверия. Если вы не можете найти это в себе, чтобы доверять этому (не принимайте его - доверяйте ему), стандартный, я предложу вам, что вам будет трудно писать действительно понятный код С#, который обычно имеет приемлемое качество. Это, конечно, не считая немногих действительно умных и действительно опытных, которые сумели создать свой собственный набор внутренних наборов правил о том, как писать код, который: Стабильный, читаемый, поддерживаемый, расширяемый и, как правило, мега-интерфейс.

Это не говорит, что это единственный стандарт, просто он действительно работает. Также со временем.

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

Итак, рассмотрите свой стандарт, он действительно устанавливает планку качества, которое вы предоставляете за $, который вы заработаете.

Не пересматривайте его, если у вас нет "реальных веских причин".

Но учитесь на этом.

Вы пришли сюда, и вы все еще не удовлетворены. Вы хотите получить ответы!

Дерьмо. Хорошо, позвольте мне дать вам облачный и суб-парный опыт, основанный на правилах, которые ваша команда не может опрокинуть.

Нет. 26: Избегайте предоставления явных значений для перечислений, если они не являются целыми степенями 2

О простоте и работе в этой простоте. Enum в С# уже пронумерованы от "i = 0" и вводят "++ i" для каждого нового поля, которое вы определяете. Простейший способ [читать код с /] думать о перечислениях, следовательно, либо вы отмечаете их, либо перечисляете их. Когда вы этого не делаете, вы, вероятно, делаете что-то неправильно. Если вы используете перечисление для "сопоставления" какой-либо другой модели домена, это правило может быть нарушено, но перечисление должно быть визуально отделено от обычных перечислений через пространство размещения /namespace/etc - чтобы указать, что вы "делаете что-то неординарное".

Теперь посмотрите на перечисления, созданные вами нестандартно. На самом деле взгляните на них. Вероятно, они отображают то, что действительно не относится к жестко закодированному перечислению. Вы хотели повысить эффективность коммутатора, но теперь у вас на самом деле началось жесткое кодирование свойств вне домена. Иногда это нормально и может быть реорганизовано позже, иногда это не так.

Поэтому избегайте этого.

Аргумент "вставки в середину" в процессе разработки не является проблемой, которая должна нарушить стандарт. Зачем? Хорошо, если вы используете или каким-либо образом сохраняете значение "int value" перечисления, тогда вы уже расходитесь с шаблоном использования, где вам нужно оставаться очень сфокусированным. Не использовать 0, 1, 2 не является ответом на проблемы в этом конкретном домене, т.е. Вы, вероятно, "делаете это неправильно".

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

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

Если вы столкнулись с определенными проблемами, связанными с сопоставлением таблиц базы данных, тогда разрешите эти проблемы, сохранив стандарт. Для EF 4.3 я бы сказал, используйте get/set с int pattern и замените в 5.0.

Настоящий песчаный материал здесь - как поддерживать этот объект по мере развития базы данных. Обязательно укажите четкие пути миграции для своей производственной базы данных, когда объекты, связанные с перечислением, меняют дизайн. Будьте очень уверены, что сами сущности меняют значения. Это касается добавления/удаления/вставки новых определений. Не просто добавить.

Нет. 34: Всегда явно инициализировать массив ссылочных типов, используя цикл for

Мое предположение - это правило, основанное на опыте. Таким образом, он просмотрел много кода, и эта точка, похоже, часто не срабатывала для тех, кто этого не делал.

Нет. 50: Избегайте событий в качестве элементов интерфейса

В принципе вопрос разделения - ваши интерфейсы теперь соединяют "оба" пути в интерфейс и из него. Прочтите его книгу для разъяснения, почему это не "лучшая практика" в мире С#.

В моем ограниченном представлении это, вероятно, аргументация в соответствии с: "Обратные вызовы очень отличаются по своей природе от функций-вызовов. Они делают предположения о состоянии приемника в undefined" позже "выполнения Если вы хотите предоставить обратные вызовы, обязательно обеспечьте их, а сделайте их отдельными интерфейсами, а также определите интерфейс для согласования этих обратных вызовов, фактически создав все тяжелые вещи, которые вы хотели отвлечь, но на самом деле просто обошли. вероятно, просто используйте признанный образец. aka читайте книгу".

Нет. 52: Открыть интерфейсы в иерархиях классов

Разделение. Я не могу действительно объяснить это дальше: Альтернатива трудно учесть в более широком контексте/решении.

Нет. 73: Не определять ограничения, специфичные для метода в интерфейсах

Разделение. то же, что и # 52

Нет. 74: Не задавайте ограничений в делегатах

Разделение.

Заключение

......

Еще один вид на # 50 - это одно из тех правил, в которых: Если вы не получите его, это, вероятно, не важно для вас. Важность здесь - это оценка того, насколько критичен код, и насколько критически вы хотите, чтобы этот код всегда работал по назначению.

Это снова приводит к более широкому контексту о том, как проверить, действительно ли ваш код является качеством.

Некоторые сказали бы, что это можно сделать только с помощью тестов.

Однако они не понимают взаимосвязанности между защитным программным обеспечением качества и агрессивно пытаются доказать это неправильно.

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

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

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

и др.

Ответ 3

Нет. 26: Он совершенно не прав, по крайней мере, для публичных перечислений. Проблема возникает при удалении элемента, а не при его добавлении (для которого добавление в конец списка эквивалентно добавлению элемента со следующим доступным значением).

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