Skip to content

dgryski/awesome-go-style

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

14 Commits
 
 

Repository files navigation

This is a collection of style guides for Go.

Be sure to read about writing engineering guidelines before trying to adopt one of these wholesale.

(For more commentary on these, see my blog post Idiomatic Go Resources)

The Classics

Googler Talks

Go Wiki Pages

Non-Googlers

Further Reading

Corporate/Project-specific Style Guildes

General tips for Code Reviews:

My own attempt at best practices for TODO comments (extracted from existing Go practices, but otherwise mostly undocumented):

// For TODOs, BUGs, and NOTEs please use the standard form:
//
//    // TODO(username): ...
//
// The username (generally yours) means "for more information see", not
// "I claim responsibility for fixing this." Please use TODO rather than FIXME,
// XXX, HACK, etc.  This limits the number of things to grep for.
//
//    * TODO denotes missing features or functionality
//    * BUG denotes known broken code; these are displayed in godoc
//    * NOTE is used to highlight a particularly important or subtle section of code
//    * SECURITY and SECBUG are used for security related notes and issues

If you have a bug tracker, TODO(bug#) is probalby more useful as they're likely to stay static while maintainers move over time. Similarly, including dates or release versions in the comment can ensure TODOs are revisisted at appropriate times.

Find this useful? Buy me a coffee!

About

A collection of Go style guides

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published