Подтвердить что ты не робот

Конвенция для имен файлов общих классов

Я хочу иметь возможность различать общую и регулярную (не общую) версию класса. Как и в .NET Framework, с ней существуют общие и не общие версии нескольких интерфейсов и классов коллекций. (Queue, Queue (T))

Мне обычно нравится следовать стандарту одного класса для каждого файла (как в Java). Существует ли общее соглашение для именования файлов, содержащих один общий класс? Меня больше всего интересует Windows (NTFS), но похоже, что хорошее соглашение будет (хотя бы немного) переносимым.

4b9b3361

Ответ 1

В Microsoft они используют ClassNameOfT.cs.

Ответ 2

Просто нашел этот вопрос после поиска того, какие соглашения используют другие люди для имен файлов общего класса.

В последнее время я использовал ClassName[T].cs. Мне очень нравится эта конвенция, и я думаю, что она превосходит остальных по следующим причинам:

  • Параметры типа выпрыгивают на вас немного больше, чем с Microsoft (например, ClassNameOfT.cs).
  • Это позволяет вам иметь несколько параметры типа без особого путаница: Dictionary[TKey, TValue].cs
  • Это не требует создания каких-либо специальных папок или создания ваших общих классов в специальном пространстве имен. Если у вас есть только несколько общих классов, наличие специального пространства имен, посвященного им, просто не практично.

Я взял это соглашение из Boo общий синтаксис, хотя и слегка измененный (Boo использует ClassName[of T]).

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

Ответ 3

Я вижу, что эта тема была оставлена ​​более года назад, но все же я хотел бы поделиться своим мнением относительно этого соглашения.

Прежде всего, наличие нескольких классов, имеющих одно и то же имя, но отличающихся только количеством параметров типа, не всегда является случаем обратной совместимости. Конечно, вы не видите это очень часто, но новые Action- и Func-классы .NET были спроектированы таким образом, и я в настоящее время реализую нечто подобное.

Для ясности и различимости я использую следующее соглашение, которое задает только число общих аргументов для данного типа:

  • MyClass.cs
  • MyClass.T1.cs
  • MyClass.T2.cs

Таким образом, мои имена файлов остаются короткими и простыми, но при этом все еще ясно сообщают имя класса и различные параметры типа за счет простой дополнительной точки (что, по моему опыту, является общепринятой вещью в имя файла и выглядит намного лучше, чем запятая и другие неалпаниевые символы, но это только вопрос вкуса, я думаю). Помещение имен (или сокращений) параметров типа просто удлиняет имена файлов, в то время как на этом уровне меня вообще не интересуют фактические имена параметров типа...

Ответ 5

Как насчет:

Type.cs

и

TypeGeneric.cs

Всякий раз, когда я это делал в прошлом, я всегда ставил оба типа в один файл с не-общим типом в качестве имени файла. Я думаю, что это делает вещи довольно ясными, поскольку .NET не имеет никаких условностей/ограничений для одного типа для файла, такого как Java.

Но если вы должны тогда предложить что-то вроде выше, и с помощью суффикса файлы будут отображаться вместе в любом алфавитном списке (Solution Explorer, Windows Explorer и т.д.).

Вот еще одна идея:

Type`1.cs

Это позволит вам разбить разные типовые типы по числу типичных параметров, которые они приняли. Его просто мысль, хотя, как я все еще думаю, было бы проще просто поместить все типы в один файл.

Ответ 6

Все новые классы Microsoft используют дженерики. Queue и ArrayList были там до появления дженериков. Дженерики - это путь вперед.

Соглашение для файла с одним классом для каждого имени - это имя имени файла после имени класса (независимо от его общего). Для MyClass у вас будет MyClas.cs. Для каждого нового пространства имен вам нужно создать новую папку. Так работает Visual Studio.

Ответ 7

Я бы, вероятно, поместил их в папки и вместо этого использовал механизм пространства имен. Вы можете сравнить с System.Collections против System.Collections.Generic. С другой стороны, если это более распространено, чем не то, что классы используют дженерики, возможно, лучше указать на те, которые этого не делают. То есть, если вы действительно хотите отделить родовые классы от других классов. Лично я обычно не делаю этого, потому что я действительно не вижу практической выгоды от этого.

Ответ 8

Из ответов до сих пор кажется, что не существует консенсуса.

Использование одного и того же имени файла в пространстве подзаголовков (и подпапках) является "опцией" "Generics" (например, System.Collecctions.Generics). Но не всегда желательно создать новое пространство имен.

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

Я думаю, что суффикс - разумный способ пойти. Я принял соглашение об использовании параметров типа в качестве суффикса (так: MyClassT для MyClass <T> или MyDictionaryKV для MyDictionary < K, V > .

Ответ 9

Лично я бы не использовал обозначение серьезного акцента:

Foo.cs
Foo'1.cs

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

NameOfT.cs кажется, используется в ASP.NET Core в соответствии с поиском в GitHub. 19 результатов. Ссылка

Также ограничено использование в CoreFX. 3. Результаты. Ссылка

Пример:

Foo.cs
FooOfT.cs

Ответ 10

У меня, вероятно, будет две папки в проекте, что-то вроде Gereric, NonGeneric или что-то в этом роде. Они все еще могут находиться в одном пространстве имен, а затем оба могут иметь одинаковое имя файла. Просто мысль...

Ответ 11

Иногда я также вижу ClassName{T}.cs но обычно называют его ClassNameOfT.cs (как упоминалось ранее, когда Microsoft его использует)

Проект EntityFrameworkCore (также Microsoft) использует ClassName'.cs