<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Kaitian Xie</title>
    <description>The latest articles on DEV Community by Kaitian Xie (@caelaxie).</description>
    <link>https://dev.to/caelaxie</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F98161%2Fa95aaee8-1066-4f6a-a735-0e81555ff82c.jpeg</url>
      <title>DEV Community: Kaitian Xie</title>
      <link>https://dev.to/caelaxie</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/caelaxie"/>
    <language>en</language>
    <item>
      <title>Camellia: A Small Go Linter for Camel-Case Abbreviations</title>
      <dc:creator>Kaitian Xie</dc:creator>
      <pubDate>Sat, 16 May 2026 21:49:41 +0000</pubDate>
      <link>https://dev.to/caelaxie/camellia-a-small-go-linter-for-camel-case-abbreviations-3mc4</link>
      <guid>https://dev.to/caelaxie/camellia-a-small-go-linter-for-camel-case-abbreviations-3mc4</guid>
      <description>&lt;p&gt;Go code has a long-running naming habit around initialisms: &lt;code&gt;ID&lt;/code&gt;, &lt;code&gt;URL&lt;/code&gt;, &lt;code&gt;HTTP&lt;/code&gt;, &lt;code&gt;API&lt;/code&gt;, and friends often stay fully capitalized inside identifiers. That gives you names like &lt;code&gt;UserID&lt;/code&gt;, &lt;code&gt;ParseURL&lt;/code&gt;, &lt;code&gt;HTTPClient&lt;/code&gt;, and &lt;code&gt;APIError&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;I understand the convention, but I do not like how it reads.&lt;/p&gt;

&lt;p&gt;My preference is simpler: treat abbreviations like normal words when they are part of a mixed-case identifier.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight go"&gt;&lt;code&gt;&lt;span class="k"&gt;type&lt;/span&gt; &lt;span class="n"&gt;ApiError&lt;/span&gt; &lt;span class="k"&gt;struct&lt;/span&gt;&lt;span class="p"&gt;{}&lt;/span&gt;
&lt;span class="k"&gt;type&lt;/span&gt; &lt;span class="n"&gt;HttpClient&lt;/span&gt; &lt;span class="k"&gt;struct&lt;/span&gt;&lt;span class="p"&gt;{}&lt;/span&gt;

&lt;span class="k"&gt;func&lt;/span&gt; &lt;span class="n"&gt;ParseUrl&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;userId&lt;/span&gt; &lt;span class="kt"&gt;string&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt; &lt;span class="p"&gt;{}&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;The reason is not that &lt;code&gt;Api&lt;/code&gt; is more "correct" than &lt;code&gt;API&lt;/code&gt; 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.&lt;/p&gt;

&lt;p&gt;I would rather remove the exception.&lt;/p&gt;

&lt;p&gt;&lt;code&gt;UserId&lt;/code&gt; follows the same visual rhythm as &lt;code&gt;UserName&lt;/code&gt;. &lt;code&gt;HttpClient&lt;/code&gt; follows the same rhythm as &lt;code&gt;FileClient&lt;/code&gt;. &lt;code&gt;ParseUrl&lt;/code&gt; follows the same rhythm as &lt;code&gt;ParsePath&lt;/code&gt;. The names become less noisy because the rule is boring: use camel case everywhere.&lt;/p&gt;

&lt;p&gt;That is why I made &lt;a href="https://github.com/caelaxie/camellia" rel="noopener noreferrer"&gt;Camellia&lt;/a&gt;, a small &lt;code&gt;golangci-lint&lt;/code&gt; module plugin for this exact preference.&lt;/p&gt;

&lt;p&gt;Camellia flags project-declared Go identifiers with all-caps abbreviation runs and suggests the camel-case spelling instead:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight go"&gt;&lt;code&gt;&lt;span class="k"&gt;type&lt;/span&gt; &lt;span class="n"&gt;APIError&lt;/span&gt; &lt;span class="k"&gt;struct&lt;/span&gt;&lt;span class="p"&gt;{}&lt;/span&gt;    &lt;span class="c"&gt;// ApiError&lt;/span&gt;
&lt;span class="k"&gt;type&lt;/span&gt; &lt;span class="n"&gt;HTTPClient&lt;/span&gt; &lt;span class="k"&gt;struct&lt;/span&gt;&lt;span class="p"&gt;{}&lt;/span&gt;  &lt;span class="c"&gt;// HttpClient&lt;/span&gt;

&lt;span class="k"&gt;func&lt;/span&gt; &lt;span class="n"&gt;ParseURL&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;userID&lt;/span&gt; &lt;span class="kt"&gt;string&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt; &lt;span class="p"&gt;{}&lt;/span&gt; &lt;span class="c"&gt;// ParseUrl, userId&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;If you also prefer &lt;code&gt;ApiError&lt;/code&gt; over &lt;code&gt;APIError&lt;/code&gt;, try it here:&lt;/p&gt;

&lt;p&gt;&lt;a href="https://github.com/caelaxie/camellia" rel="noopener noreferrer"&gt;github.com/caelaxie/camellia&lt;/a&gt;&lt;/p&gt;

</description>
      <category>go</category>
      <category>linting</category>
    </item>
  </channel>
</rss>
