Camellia: A Small Go Linter for Camel-Case Abbreviations

Camellia：一个用于驼峰命名缩写的轻量级 Go Linter

Go code has a long-running naming habit around initialisms: ID, URL, HTTP, API, and friends often stay fully capitalized inside identifiers. That gives you names like UserID, ParseURL, HTTPClient, and APIError. Go 语言在处理首字母缩略词（initialisms）方面有着悠久的命名习惯：ID、URL、HTTP、API 等词汇在标识符中通常保持全大写。这便产生了诸如 UserID、ParseURL、HTTPClient 和 APIError 这样的名称。

I understand the convention, but I do not like how it reads. My preference is simpler: treat abbreviations like normal words when they are part of a mixed-case identifier. 我理解这种惯例，但我不喜欢它的阅读体验。我的偏好更简单：当缩写词作为混合大小写标识符的一部分时，应将其视为普通单词处理。

type ApiError struct{} type HttpClient struct{} func ParseUrl(userId string) {}

The reason is not that Api is more “correct” than API in isolation. It is that code is scanned in context. Once a codebase has a mix of ordinary words and all-caps abbreviation runs, identifiers start to look jagged. The reader has to remember which words are special, where the special casing starts, and where it stops. I would rather remove the exception. 原因并非孤立地看 Api 比 API 更“正确”，而是因为代码是在上下文中被阅读的。一旦代码库中混杂了普通单词和全大写的缩写词，标识符看起来就会显得参差不齐。阅读者必须记住哪些词是特殊的，特殊大小写的起始和结束位置在哪里。我宁愿消除这种例外。

UserId follows the same visual rhythm as UserName. HttpClient follows the same rhythm as FileClient. ParseUrl follows the same rhythm as ParsePath. The names become less noisy because the rule is boring: use camel case everywhere. UserId 与 UserName 遵循相同的视觉节奏；HttpClient 与 FileClient 节奏一致；ParseUrl 与 ParsePath 节奏一致。由于规则变得简单枯燥——即到处都使用驼峰命名法——名称的干扰性也随之降低。

That is why I made Camellia, a small golangci-lint module plugin for this exact preference. Camellia flags project-declared Go identifiers with all-caps abbreviation runs and suggests the camel-case spelling instead: 这就是我开发 Camellia 的原因，这是一个专门针对这一偏好的小型 golangci-lint 模块插件。Camellia 会标记项目中声明的、包含全大写缩写词的 Go 标识符，并建议改用驼峰拼写：

type APIError struct{} // ApiError type HTTPClient struct{} // HttpClient func ParseURL(userID string) {} // ParseUrl, userId

It is intentionally narrow. It does not try to reformat your whole project or invent a broad style guide. It just enforces one naming choice consistently. Imported symbols are left alone, and if you need to roll the rule out gradually, Camellia supports its own exclude list for generated code, fixtures, or legacy paths. 它的功能定位非常明确。它不会试图重构你的整个项目，也不会发明一套宽泛的风格指南。它只是强制执行一种统一的命名选择。导入的符号不会受到影响；如果你需要逐步推广该规则，Camellia 还支持自定义排除列表，用于处理生成的代码、测试夹具（fixtures）或遗留路径。

If you also prefer ApiError over APIError, try it here: github.com/caelaxie/camellia 如果你也更倾向于使用 ApiError 而非 APIError，请在这里尝试：github.com/caelaxie/camellia