Должен ли я использовать (в противном случае оптимальные) имена классов, которые конфликтуют с именами .NET BCL?

Я не вижу никаких проблем с сохранением имен Черчение, Диагностика и т.д. Это одна из целей пространств имен, чтобы разрешить конфликты имен.

Прелесть пространств имен в том, что они позволяют создавать классы с одинаковыми именами. Вы можете назначить псевдоним пространству имен, когда импортируете его в свой файл с помощью оператора using.

using MyAlias = My.Custom.Namespace;

это позволит отделить ваши классы от классов Microsoft.

вы можете ссылаться на свои классы как

MyAlias.Diagnostics

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

Что ж, если вы хотите избежать столкновения пространств имен, вы можете сделать несколько вещей:

• Не сталкиваться, вместо этого выберите уникальное имя.

Пример:

Если вы создаете математический класс, вы можете назвать свой CamiloMartin.MathHelper

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

Пример:

public class MyClass
{
    public int SomeCalculation(int a, int b)
    {
        return MyNamespace.Math.SomeFunc(a, b);
    }
}

• Использование псевдонима для различения.

Пример:

using System.Math;
using SuperMath = MyNamespace.Math;

namespace MyNamespace
{
    public class MyClass
    {
        public int SomeCalc(int a, int b)
        {
             int result = Math.abs(a);
             result = SuperMath::SomeFunc(a, b);

             return result;
        }
    }
}

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

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

РЕДАКТИРОВАТЬ : Я также не верю, что «маленький» является компонентом «идеального» идентификатора. Лаконично и ясно, конечно, но если требуется более длинное имя, чтобы передать цель конкретной конструкции, пусть будет так. В конце концов, у нас есть intellisense.

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

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

В общем:

1. Вот что мы делаем (эй, мы можем рефакторить это позже)

2. Использовал это один или два раза, но только для важных классов. Особенно полезно, если вы еще не знаете "идеального" имени.

3. Даже не думайте об этом...

Использование псевдонимов пространств имен - это не весело. Поэтому я избегаю этого, если могу.

Для справки: .NET framework не имеет ни Utils , ни Diagnostics класса. (Но имеет пространство имен System.Diagnostics .)

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

В остальном - я согласен с другими в том, что пространства имен удобны. (Хотя я дважды подумал бы назвать класс, если в System уже есть класс с таким же именем, не из-за конфликтов имен, а скорее потому, что я не могу использовать «исходный» класс может означать, что класс, который я собираюсь создать, семантически отличается.)