Temporary Short Names
When writing code, I prefer to use the full name of something to retain context and design decisions established by that name. However, there are cases where using a name many times in rapid succession becomes tedious, bordering on line noise. In those situations, it may make sense to use a temporary alias or short name to keep code legible.
Here are a couple examples, one in Elixir and one in Rust, of how you can do that:
Rust - Enum Alias
If you have a long Enum name like thisCredit to Logan Smith for introducing me the following trick. Go watch his video to hear more about the reasoning to prefer an alias over a *
import, as well as other opinions on Rust. (This Enum suggestion is point 2 in the video).:
enum DecidedlyLongEnumNameHere {
VariantX,
VariantY,
VariantZ,
}
Doing an exhaustive pattern match on that Enum becomes tedious:
match enum {
DecidedlyLongEnumNameHere::VariantX => x(),
DecidedlyLongEnumNameHere::VariantY => y(),
DecidedlyLongEnumNameHere::VariantZ => z(),
}
Rust lets you do a use
declaration inside of a function, so you can create a short alias like this:
use DecidedlyLongEnumNameHere as D;
match enum {
D::VariantX => x(),
D::VariantY => y(),
D::VariantZ => z(),
}
The alias has the same scope as where you’ve used it, and is declared right next to its use, so context from the name is retained.
Elixir - Scoped Aliases
In Elixir, you may have a similar problem with long Module or Struct namesOr both, since structs are named after their creating module, and that module often defines functions useful to that struct.:
def my_fun do
[1, 2, 3]
|> OverlyLongModuleName.fun1()
|> OverlyLongModuleName.fun2()
|> OverlyLongModuleName.fun3()
...
end
I prefer not to use a module wide short name, since that obscures the calling code by disconnecting that code from information important to understand its purpose.
Elixir supports lexical scope on alias
and import
Check out hexdocs for more information., so you can do this:
def my_fun do
alias OverlyLongModuleName, as: O
[1, 2, 3]
|> O.fun1()
|> O.fun2()
|> O.fun3()
...
end
This allows for code to be shortened while retaining proximal knowledge about module context.
I haven’t tried either of these in collaborative codebases, but it’s nice to know that both are possible.