golang Rules

Avoid getter methods in Go

Avoid using "getter" methods in Go code. Instead, expose fields directly when appropriate, following Go's idiomatic approach to visibility. Bad: `go type Person struct { name string age int } func (p *Person) GetName() string { return p.name } func (p *Person) GetAge() int { return p.age } // Usage name := person.GetName() ` Good: `go type Person struct { Name string Age int } // Usage name := person.Name `

Early returns in Go

Use early returns to reduce nesting levels. Prefer checking error conditions or guard clauses first and returning early, rather than wrapping the main logic in deep conditional blocks. Bad: `go func processData(data []string) (string, error) { if len(data) > 0 { if isValid(data) { result := "" for _, item := range data { if item != "" { // More nested code here result += transform(item) } } return result, nil } else { return "", errors.New("invalid data") } } else { return "", errors.New("empty data") } } ` Good: `go func processData(data []string) (string, error) { if len(data) == 0 { return "", errors.New("empty data") } if !isValid(data) { return "", errors.New("invalid data") } result := "" for _, item := range data { if item == "" { continue } result += transform(item) } return result, nil } `

Inline error assignment in Go

Use inline error assignment with the := operator when checking for errors. Bad: `go var err error result, err = someFunction() if err != nil { return err } ` Good: `go if result, err := someFunction(); err != nil { return err } `

Structured logging in Go

Always use structured logging with field-based approaches instead of string formatting when logging in Go. Bad: `go logger.Info(fmt.Sprintf("User %s logged in from IP %s with status %d", username, ipAddress, statusCode)) ` Good: `go logger.Info("User authentication", "username", username, "ip", ipAddress, "status", statusCode, ) `

Avoid unnecessary else blocks in Go

Avoid unnecessary else blocks when the if block ends with a return statement, break, continue, or similar control flow statements. Bad: `go func processValue(value int) string { if value > 10 { return "high" } else { return "low" } } ` `go func checkItems(items []string) { for _, item := range items { if len(item) > 5 { fmt.Println("Long item:", item) continue } else { fmt.Println("Short item:", item) } } } ` Good: `go func processValue(value int) string { if value > 10 { return "high" } return "low" } ` `go func checkItems(items []string) { for _, item := range items { if len(item) > 5 { fmt.Println("Long item:", item) continue } fmt.Println("Short item:", item) } } `

Use structured logger in Go

Use the structured logger for all logging operations instead of fmt.Print or log package functions. Bad: `go import ( "fmt" "log" ) func processOrder(order Order) error { fmt.Println("Processing order:", order.ID) if err := validateOrder(order); err != nil { log.Printf("Error validating order %s: %v", order.ID, err) return err } return nil } ` Good: `go import ( "github.com/yourproject/logger" ) func processOrder(order Order) error { logger.Info("Processing order", "orderID", order.ID) if err := validateOrder(order); err != nil { logger.Error("Failed to validate order", "orderID", order.ID, "error", err) return err } return nil } `

Use Zap logger in Go

Use Zap for all logging in Go code. Bad: `go func processOrder(order Order) error { fmt.Printf("Processing order %s\n", order.ID) if err := validateOrder(order); err != nil { log.Printf("Error validating order: %v", err) return err } fmt.Println("Order processed successfully") return nil } ` Good: `go func processOrder(order Order) error { logger := zap.L().With(zap.String("orderID", order.ID)) logger.Info("Processing order") if err := validateOrder(order); err != nil { logger.Error("Failed to validate order", zap.Error(err)) return err } logger.Info("Order processed successfully") return nil } `