Coding standards - Go

Go, also known as Golang, is a statically typed, compiled programming language designed at Google. It emphasises simplicity, performance, and ease of use. Known for its fast compilation, lightweight concurrency, and opinionated standard library, Go has become the go-to language for building scalable web services, cloud tools, and backend systems.

The single best property of Go is that it is basically non-magical.

— Peter Bourgon

Naming conventions

  • A name should begin with a letter and cannot contain spaces. Let's keep numerics to a minimum in names.
  • If a function name starts with an uppercase letter (e.g. CalculateVAT) it will be exported. Lowercase names (e.g. calculateVAT) won't.
  • If a name has multiple words, capitalise each word after the first (e.g. firstName, shippingAddress). When unsure, Google it (e.g. it's username not userName).
  • JSON variables should be lowercase with underscores (e.g. shipping_address).
  • In Go methods (struct that implements methods), use short identifiers (e.g. s).
  • Avoid naming variables the same as imported packages where possible (e.g. don't use orders as both a variable and package).
  • Constants should begin with uppercase and be grouped using const blocks e.g.
    const ( RedisKeyAccountCodeIDKey = "account-code-id-" RedisKeyAccountID = "account-id-" )

Error handling

Go handles errors differently from languages like Java or Python. There's no try/catch; instead, functions return error values explicitly. This encourages clean, explicit error handling with minimal magic.

All returned errors should be handled appropriately—even if only logged. There are helper functions for logging and managing errors.

ORM

ORM (Object-Relational Mapping) lets you interact with your database through objects instead of raw SQL. While convenient, it comes with pros and cons.

Pros:
  • Automatic parameter sanitisation
  • Easier to read/write for simple queries
  • Faster to implement basic DB operations
Cons:
  • Complex queries can get messy and error-prone
  • May introduce performance overhead
  • Learning curve and abstraction limitations

Currently we're using bun (https://bun.uptrace.dev/).

Our philosophy: Use the ORM for simple reads, inserts, and updates. For complex, performance-critical queries, write raw PostgreSQL.