Super quick style question, what kind of name fits with the style more,`CompareBase64HashAndPassword` or `CmpB64HashPass`?

<p>There&#39;s so much written about style guidelines and the official documentation, and the general consensus is common sense, really.</p> <p>But sometimes things like this come up: <code>CompareBase64HashAndPassword</code> contains all of the information you need to know what the method does, but it, at least to me, is a very long name. We could shorten it to <code>CmpB64HashPass</code> but <code>CmpB64HashPass</code> could mean the same thing to one person, or it could mean &#34;compute the base64 hash from this password&#34;, until they see that the argument takes two strings. But then they could think &#34;what if that&#39;s the password and salt?&#34;</p> <p>Then they have to go read the documentation or the actual function to know that it&#39;s decoding the base64URL-encoded hash, and then comparing that to that to a recomputed hash from the given password.</p> <p>But the first method name just seems too long.</p> <hr/>**评论：**<br/><br/>relvae: <pre><p>Keep it simple, first option is easily more preferable imo. </p> <p>Another consideration is the context for which the function resides. For example if the package was called <code>password</code> then you could shorten the name to simply <code>password.CompareBase64Hash()</code>. Another case could be where you use the function parameters to provide additional context so that <code>CompareBase64(hash, plaintext string)</code>.</p> <p>Go with whatever feels most intuitive</p></pre>glacials: <pre><p>A function is more than a name, it&#39;s the whole signature.</p> <pre><code>type hash string type password string func (h hash) Matches(p password) bool { ... } </code></pre> <p>This is an extreme example, but don&#39;t feel afraid to lean on your arguments for descriptive power.</p> <p>By the way, I hope your passwords are not just converted into base 64. That&#39;s not a hash, or even encryption, just another way of storing plain text.</p></pre>epiris: <pre><p>In most Go code I see the context describes the object as well, such as the package name and type. Such a name would be redundant in a well formed and designed package. This is why package names like “utils” are discouraged and using the Type system properly is important to prevent programmer error.</p> <p>Here for example you are having to describe input invariants by naming due to ambiguity between string and a base64 encoded hash string and a Password string. So a type safe interface may instead look like:</p> <pre><code>package authorize // enforce type safety type Equaler interface { Equal(Equaler) bool } type Password string // impl Equaler type Hash string; // impl Equaler </code></pre> <p>Then anything that returned a Base64Hash would return a Hash, I.e. maybe you would have a Hash() function on your Password type to derive a Hash type. Then comparing looks like Hash(hashFromDB).Equal(Password(requestPassword).Hash())</p> <p>Obviously this abstraction is going wayyyy to far. Strings are comparable so you should just have a Hash type and compare them. But point was to illustrate how naming, using the type system and sharing interfaces qualifies objects to prevent obnoxious naming.</p></pre>nyxxxie: <pre><p>Out of curiosity, what is this method being used for?</p></pre>xiegeo: <pre><p><code>Verify(hash, password string) bool</code></p> <p>That&#39;s what I would prefer. </p> <p>You should also add salt and algorithm arguments too.</p></pre>NatoBoram: <pre><p>Basically, you want <a href="https://php.net/manual/en/function.password-verify.php" rel="nofollow"><code>password_verify</code></a>.</p> <p>I wish this and <a href="https://php.net/manual/en/function.password-hash.php" rel="nofollow"><code>password_hash</code></a> were implemented by default in every single languages. :/</p></pre>evmar: <pre><p><a href="https://github.com/golang/go/wiki/CodeReviewComments#variable-names" rel="nofollow">https://github.com/golang/go/wiki/CodeReviewComments#variable-names</a> </p> <p>discusses this a bit:</p> <blockquote> <p>The basic rule: the further from its declaration that a name is used, the more descriptive the name must be. For a method receiver, one or two letters is sufficient. Common variables such as loop indices and readers can be a single letter (i, r). More unusual things and global variables need more descriptive names.</p> </blockquote></pre>