GoLang: When to use string pointers
A string in Go is a value. Thus, a string cannot be nil
.
However, a pointer to a string (or *string
) can be nil
.
A good rule of thumb is to use normal strings unless you need nil
. Normal strings are easier and safer to use in Go. Pointers require you to write more code because you need to check that a *string
has a value before dereferencing.
An empty string value ""
and nil
are not the same thing. When programming, if you can’t think of reason you would need nil
, then you probably don’t need it or want it.
So when should I use a pointer to a string?
There may be times when you should use *string
. For instance, you should probably use a *string
for struct properties when deserializing json or yaml (or anything) into a structure.
Consider code where a json document is deserialized into a struct consisting of normal string properties.
You’ll notice that both Version
and HostName
are stored as empty strings. This is correct behavior for Version
, but should HostName
really be an empty string?
The answer to that question depends on your program. If it is acceptable for a missing property to be unmarshalled into an empty string, then there is no problem. In other words, if you will handle missing json properties and empty json properties the same, then use a normal string.
But what if ""
is a valid configuration value for HostName
, but a missing property is not valid?
Answer: use a *string
.
Notice that with *string
, you can now differentiate between a missing property or null
value from an empty string value in the json document.
tl;dr; Only use a string pointer *string
if you need nil
. Otherwise, use a normal string
If you benefited from this post, please consider subscribing to my newsletter!