DISCLAIMER: Esses posts não tem nada a ver com um certo livro que fala sobre Código Limpo. Nada. Aqui eu tomo a liberdade de definir o que código limpo, especialmente em Go, baseado na minha própria experiência em escrever muito código uhm, não limpo ao longo dos anos, várias pesquisas que faço pra tornar meu código melhor enquanto estou escrevendo em Go. Esses exemplos **provavelmente não se aplicarão diretamente a nenhuma outra linguagem de programação.*.

Esse é o segundo post de uma série de posts que começou aqui baseado numa palestra dada sobre Go e Clean Code(slides aqui)

I’d like to explore a bit more on the unpopular art of naming functions and interfaces. I am gonna introduce these things very quickly, then I’m gonna talk about a couple of naming conventions for then, and provide a couple of examples alongside with a brief explanation of these examples. As usual, I will provide links to my references.

We’ll always use mixedCaps or MixedCaps, depending on whether we want to export a name or not.

The basic rules of naming things should be applied here: be concise, be descriptive. Pick short and meaningful names.

Functions

Functions in Go are like functions in pretty much every programming language. They do something given a specific numbers of arguments and may or may not return values. They can be simple functions, have multiple return values, they can be variadic function, recursive functions or even anonymous functions also known as closures.

Getters and Setters

It is very common, in several languages, to write getters and setters for properties that are not exported or that require a special treatment.

In Go, if we want to get the owner property of an object, this is how we want to do it:

199
obj.Owner()

But if we want to set the owner property, we want to do:

199
obj.SetOwner(owner)

The most shockingly news about this approach is the lack of the word get on the getter. Its use is discouraged by Effective Go

Interfaces

An Interface type holds a set of method signatures. Go has thing very cool thing that for a thing to be of the same type of an Interface, it doesn’t have to explicitly reference it - following the same set of method signatures is enough!

We often want to keep our interfaces tiny and with a very clear purpose. Right? I’m judging you if you make your interfaces do more than one thing, but don’t be mistaken, I do it more often than I’d like to admit.

When we have interfaces that have only one method, we adopt, by convention, the name of the method + the suffix -er. The following interface names are pretty dope:

  • Reader
  • Writer
  • Formatter
  • Notifier

They normally look like that:

199
200
201
202
203
204
205
type Caller interface {
	Call()
}

type Notifier interface {
	Notify()
}

“Sometimes the result isn’t correct English, but we do it anyway. Sometimes we use English to make it nicer.” - Andrew Gerrand, What’s in a name?

Cool reference links

Past Posts