Namespace Standard

Overview

---

A namespace is simply a collection of classes that are referred to using a chosen prefix on the class name. They are commonly structured as hierarchies to allow reuse of names in different contexts and to enforce modularity.

• ❓ Why should I care about this article?

  Namespace convention rule is necessary to ensure that developers are following best practices, while also ensuring maintainability and modularity of the project.

• 🎯 The goal of this article

  This article will provide a consistent set of namespace rules in Agate. The goal from the namespace rules is to enforce modularity.

• 🤷🏻 If I have further question about this article, who can I reach out to?

  Please contact: Fachri Akbar (fachri@agate.id)

Namespace Best Practice

---

• All code MUST use namespace, NO EXCEPTION. Even a small snippet of code should use namespace
• ❌ NEVER declare more than 1 namespace per file
• Namespace should be able to communicate the structure of the project, to make it more predictable and easier to access the files when needed. See Foldering Standard for more information.
  • ✅ TRY to be always mindful about creating a scalable namespace structure
• It is better to use a code name for the project from the beginning, as the actual name may change as it matures over time
  • It's important that the code name is not more than 1 word unless necessary
  • ❌ AVOID changing/migrating namespaces just because of name change
• ❌ DO NOT use and connect unnecessary modules
  • ❓ Why? → To enforce modularity principle and avoid unnecessary connection
  • For example, an IAP (in-app purchase) module does not need to be connected with Tutorial module

Agate Namespace Convention

---

• ✅ ALWAYS start with "Agate" at the beginning of the namespace, followed by the product name. For example, Agate.Match3

• ✅ ALWAYS use PascalCase for namespaces

• The typical pattern of a namespace is as follow: Agate.[ProductName].[RootModule].[SubModule].[ComponentType]

  • For example, the controller for Tutorial in Gameplay module will have the following namespace: Agate.Match3.Gameplay.Tutorial.Controller

• ✅ DO separate namespaces based on the module purpose. Treat each feature and functionality as a plugin that's ready to be reused

  • ❓ Why? → To increase the modularity of the project components

  • ❌ INCORRECT example

    Agate.Match3.Controller.*** (contain all game controllers in one place)

    Agate.Match3.View.*** (contain all game views in one place)

    ❓ Why is this incorrect? → All of the game files are separated by components, causing the namespace being too vast and not as modular

  • ✅ CORRECT example, separated by modules

    Agate.Match3.LevelObjective.Controller

    Agate.Match3.LevelObjective.View

    Agate.Match3.Tutorial.Controller

    Agate.Match3.Tutorial.View

    When you want to reuse the Tutorial module, everything is already in one folder and namespace

• ❌ DO NOT end the namespace just on the module name.

• ❌ DO NOT use excessive namespaces. Know when to use cluster vs. namespace separation

  • ❌ EXCESSIVE example

    Agate.Match3.Scene.Transition.Process.Controller

    ❓ Why is this excessive? → The namespace become too fine grained thus creating a more complex project structure than it needed to be

  • ✅ CORRECT example

    Agate.Match3.SceneTransition.Controller

    This namespace still maintain to be modular and clear while not being overly complex