Должен ли я прекратить борьбу с соглашением об именах пространства имен Visual Studio по умолчанию?
(StartA & lt; = EndB) и (EndA> = StartB)
Доказательство: Пусть ConditionA означает, что DateRange A полностью после DateRange B _ |---- DateRange A ------|
|---Date Range B -----| _ (True, если StartA > EndB)
Пусть ConditionB означает, что DateRange A полностью до DateRange B |---- DateRange A -----| _
_ |---Date Range B ----| (True, если EndA < StartB)
Затем Overlap существует, если ни A Nor B не является истинным - ( Если один диапазон не является полностью ни за другим, ни полностью перед другим, то они должны перекрываться.)
Теперь один из законов Де Моргана говорит, что:
Not (A Or B) & lt; => Not A And Not B
Что означает: (StartA <= EndB) and (EndA >= StartB)
ПРИМЕЧАНИЕ. Сюда входят условия, при которых края накладываются точно. Если вы хотите исключить это, измените операторы >= на > и <= на <
NOTE2. Благодаря @Baodad, см. этот блог , фактическое перекрытие меньше всего: {endA-startA, endA - startB, endB-startA, endB - startB}
(StartA <= EndB) and (EndA >= StartB) (StartA <= EndB) and (StartB <= EndA)
ПРИМЕЧАНИЕ 3. Благодаря @tomosius более короткая версия читает: DateRangesOverlap = max(start1, start2) < min(end1, end2) Это на самом деле синтаксический ярлык для более длинной реализации, который включает дополнительные проверки, чтобы проверить, что даты начала включены или до конца. Вывод этого сверху:
Если даты начала и окончания могут быть не в порядке, то есть, если возможно, что startA > endA или startB > endB, тогда вы также должны проверить, что они в порядке, так что вы должны добавить два дополнительных правила достоверности: (StartA <= EndB) and (StartB <= EndA) and (StartA <= EndA) and (StartB <= EndB) или: (StartA <= EndB) and (StartA <= EndA) and (StartB <= EndA) and (StartB <= EndB) или (StartA <= Min(EndA, EndB) and (StartB <= Min(EndA, EndB)) или: (Max(StartA, StartB) <= Min(EndA, EndB)
Но для реализации Min() и Max() у вас есть для кода, (используя C тройной для скручивания) ,: (StartA > StartB? Start A: StartB) <= (EndA < EndB? EndA: EndB)
7 ответов
То же, что и ты - я боролся с этим очень долго. Затем я начал размышлять, зачем я создал папки. Я обнаружил, что начинаю создавать папки для представления пространств имен и пакетов вместо произвольных сегментов.
Например, в проекте MVVM может быть полезно поместить представления и модели представлений в отдельное пространство имен. MVC будет иметь отдельное пространство имен для моделей, контроллеров и представлений. Также полезно группировать занятия по их особенностям.
Внезапно проект становится более организованным. Другим разработчикам легче найти, где реализованы функции.
Если вы стандартизируете свои методы работы с пространствами имен, все ваши проекты будут иметь одинаковую предсказуемую структуру, что станет большим преимуществом для обслуживания.
Меня это тоже раздражало, но работа и рефакторинг проектов с большими базами кода быстро научили меня другому. Приняв эту концепцию, я думаю, что это очень хороший способ структурировать код как физически, так и логически. Когда у вас большой проект и пространства имен не соответствуют папкам, становится трудно быстро найти файлы. Также намного сложнее запомнить, где что находится ...
Кроме того, если ReSharper рекомендует это, то это, вероятно, хорошая идея. Например, R # будет жаловаться, если пространство имен вашего класса не соответствует имени его папки.
Если вам нужен серьезный совет, я бы порекомендовал приобрести Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries , который дает вам все, что вам нужно знать от реальной группы разработчиков инфраструктуры.
... цель при именовании пространств имен состоит в том, чтобы создать достаточную ясность для программиста, использующего фреймворк, чтобы немедленно узнать, каким, вероятно, будет содержимое пространства имен ...
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
И, что важно,
Не используйте одно и то же имя для пространства имен и типа в этом пространстве имен
. Фрагментация каждых 1/2 типов в пространства имен не будет соответствовать первому требованию, так как у вас будет болото пространств имен, которые необходимо квалифицировать или использовать, если вы последуете способ Visual Studio. Например
Core - Домен - Пользователи - Разрешения - Учетные записи
Вы бы создали
- MyCompany.Core.Domain.Users
- MyCompany.Core.Domain.Permissions
- MyCompany.Core.Domain.Accounts
или просто
- MyCompany.Core. Домен
Для Visual Studio это было бы первое. Кроме того, если вы используете строчные имена файлов / папок, вы каждый раз смотрите на переименование класса, а также на создание одной большой путаницы в пространстве имен.
По большей части это здравый смысл и действительно зависит от того, как вы ожидаете увидеть пространства имен. организована, если вы были потребителем собственного API или фреймворка.
Один из способов не следовать соглашению - создать файл в корневой папке проекта, а затем переместить его в последнюю подпапку.
Во всяком случае, это соглашение, которое мне действительно нравится . Если я разделяю типы на папки, то, вероятно, эти типы имеют некую концептуальную группировку, связанную с папкой. Следовательно, в этом есть некоторый смысл, их пространства имен также похожи. Java использует этот подход и применяет его в своей системе пакетов. Самая большая разница в том, что VS только «предлагает» это вам, поскольку ни язык, ни среда CLR не навязывают этого.
Папки и пространства имен файловой системы представляют собой иерархию. Мне кажется совершенно естественным совпадать с ними. Я иду еще на один шаг вперед и использую соотношение 1: 1 между файлами и классами. Я даже делаю это, когда программирую на других языках, таких как C ++.
Теперь, когда вы сомневаетесь в связи между этими двумя иерархиями, я серьезно задаюсь вопросом, что вы хотели бы представить иерархией файловой системы.
Хотя я согласен со всеми, что физическая структура, соответствующая логической, полезна, я должен сказать, что я также борюсь с автоматическим именованием Visual Studio. Есть полдюжины причин, по которым мне приходится переименовывать классы:
- Я использую корневую папку «src», чтобы визуально отделить свой код от встроенных ресурсов
- Мне нужны разные заглавные буквы
- Я организую свой код по подпапкам для организации в пространстве имен
- мне нравится отделять интерфейсы от реализаций и базовых классов
- Мне кажется, что это
По этим причинам я смирился с необходимостью настраивать их для каждого создаваемого мной класса. Моя стратегия, позволяющая избежать этой проблемы, заключается в копировании файла с нужным мне объявлением пространства имен и немедленном удалении его содержимого.
Я также чувствую боль из-за этого поведения «по умолчанию» в Visual Studio.
Visual Studio также пытается установить соответствие пространства имен / каталога, когда вы помещаете файлы LinqToSql .dbml в их собственный каталог. Каждый раз, когда я редактирую .dbml , я должен помнить:
- открыть файл
.dbml.designer.cs; - удалить имя каталога / папки из
] namespaceобъявление
Однако есть способ остановить это поведение . Он включает в себя создание настраиваемого шаблона класса.