我用C#写了一个小型的、类似HTML的标记化器和解析器，打算用于富文本渲染。当前，一切都放在一个简单命名的命名空间中，名称为 Poeoquito.Text（Poeoquito是我当前项目的名称）。这个命名空间中的“主”类接收解析器的输出，并生成合适的字形列表，以及它们各自的属性，如字体、字号、颜色、文本效果等。

我的当前类层次结构如下：

Text
├── Parsing
│ ├── RichAttribute
│ ├── RichDocument (the output of the parser)
│ ├── RichDocument.Parse (the parser implementation as a static method)
│ ├── RichNode
│ ├── RichNodeType
│ ├── RichReader (the tokenizer)
│ ├── RichReader.StateImpl (the HTML state machine implementation)
│ └── RichTokenType
├── Formatting
│ └── (types used for generating the text runs and handling the text tags)
├── RichText (the class containing the final, drawable glyphs, icons, etc)
└── TextStyle (a set of formatting properties applied to Text objects)

然而，对于这个设计，我有两个问题：

1. 在解析库中使用smurf命名风格可以吗？理想情况下我希望类型名像 TokenType、Reader 或 Parser 那样，但我觉得它们太通用，显然 System.Text.Json 也是这么想的。我本可以把解析（以及可能还包括格式化）库设为internal，但我真的很想把它保持为公共API，这样我就能在其他项目中重用整套实现。

2. 这个层次结构真的有意义吗？我不认为 Parsing 和 Formatting 的命名空间应该成为位于 Text 命名空间之外的独立实体，因为它们的主要目标是生成用于渲染的最终字形。

我觉得自己其实把事情想得太复杂了，你怎么看？

解决方案

微软提供了 [命名指南]，摘自：

经Pearson Education, Inc.授权转载，原文来自Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition，作者Krzysztof Cwalina与 Brad Abrams，2008年 10月 22日由Addison-Wesley Professional出版，作为Microsoft Windows Development Series的一部分。

其中有关于 [命名空间的命名] 的章节在这里可能相关。例如：

以下模板规定了命名命名空间的一般规则： <Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>] 下面是一些示例： Fabrikam.Math``Litware.Security

命名空间与类型名称冲突

❌ 不要引入诸如 Element、Node、Log、和 Message 这样的泛型类型名称。

这样做在常见场景中很可能导致类型名称冲突。你应该限定泛型类型名称（FormElement、XmlNode、EventLog、SoapMessage）。

虽然文件夹结构并不总是需要与命名空间严格匹配，但这是一种常见做法，我建议在没有强烈理由不这样做的情况下遵循它。如果你决定遵循它，那么 Text（或 Parsing/Formatting）很可能也应该包含你自定义的格式名称。

另请参阅：

• 关于 [类、结构体和接口的命名规范] 的准则
• [C#标识符命名规则与约定]

请注意，上述内容都只是一般性建议。