← Back to Home

In This Article:

🤔 Notice something is missing or not working? → Please contact Zoel (zoelbastianbach@agate.id) on Ms. Teams!

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?
• 🎯 The goal of this article
• 🤷🏻 If I have further question about this article, who can I reach out to?

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

See Also

Coding Standard

Naming Standard

Foldering Standard

Git Usage Standard

Back to Top ⬆️