Страницы

суббота, 21 января 2017 г.

Why I prefer longer class names even when namespace guarantees no name conflict

Suppose:

namespace Tutorial {
class CarnavalEventTutorial {...}
}


I keep Tutorial at end of class because 2 reasons:
a. you may keep some field with the same name, e.g.

public CarnavalEvent CarnavalEvent { get; private set; }

And you don't get name collision here. And no collision with class name too.

b. Suppose, that you can set that Tutorial as field of Unity component in editor. Unity editor wount show you namespaces, so you'll get 2 CarnavalEvent and can't diferentiate which one is Tutorial and which is not. More ugly example:

namespace Windows
{
    namespace Shop
    {
        public class Window : MonoBehaviour {}
    }
}

So, in Unity you'll see Window component and may decide that it's basic component. While it's not.

And one more bad thing, suppose you want to include that "Window" in code:


public class EventTracker {
private List<Window> windows;
private Windows.Shop.Window shopWindow; // you need that, again, to tell reader that it is ShopWindow. And to fix compiler error.
}

So, trying to make names short you make them longer instead :)

Minuses:
The price for that is longer names. But, again, that rule don't ask to include all the names from namespace. E.g.:

namespace Game {
namespace QuestParts {
namespace Tutorial {
class CarnavalEventGameQuestPartsTutorial {...} // not needed
}
}
}

Because, usually, you wount get CarnavalEventTutorial at different levels of namespaces.

So, the rule is: CONSIDER DUBLICATING NAME FROM ENCLOSING NAMESPACE IN CLASS NAME

вторник, 10 января 2017 г.