为何 go-lint 在处理首字母缩写时表现不一致？

知识点掌握了，还需要不断练习才能熟练运用。下面golang学习网给大家带来一个Golang开发实战，手把手教大家学习《为何 go-lint 在处理首字母缩写时表现不一致？》，在实现功能的过程中也带大家重新温习相关知识点，温故而知新，回头看看说不定又有不一样的感悟！

go-lint 建议如下：

method createstaticcsspath should be createstaticcsspath

linter 正确吗？如果正确，为什么？

它允许以前的方法：

CreateStaticJsPath

解决方案

Go 命名约定规定 initialisms 应该全部大写（实际上：在大小写一致的情况下，取决于第一个字符是否应该大写）。这就是 linter 所抱怨的。

名称中的首字母缩写词或首字母缩略词（例如“URL”或“NATO”）具有一致的大小写。例如，“URL”应显示为“URL”或“url”（如“urlPony”或“URLPony”），而不是“Url”。举个例子：ServeHTTP 不是 ServeHttp。对于具有多个初始化“单词”的标识符，请使用“xmlHTTPRequest”或“XMLHTTPRequest”等。

当“ID”是“identifier”的缩写时，此规则也适用于“ID”（这几乎是所有情况，当它不是“ego”、“superego”中的“id”时），因此请写“appID” “appId”。

因此，假设 CSS 和 JS 是首字母缩写，则 CreateStaticCSSPath 和 CreateStaticJSPath 将是写入每个符号名称的“Go way”。

虽然 linter 对这些失败的捕获自然是有限的。这里不可能 100% 准确，因为上下文（和人类直觉）是必要的。

CreateJs 可能意味着“创建 JavaScript”，也可能意味着“创建多个 J”（无论上下文中的“J”是什么）。

我希望 linter 有一个硬编码的常见缩写列表（CSS、URL、HTML、ID 等），预计误报率非常低，并且只查找这些缩写。当尝试将简洁的符号名称解析为人类可理解的文本时，其他任何事情都会很快陷入疯狂的境界。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。