Google Style Guides

https://google.github.io/styleguide/
Admin
Google Style Guides is a collection of conventions and guidelines for writing consistent code across...
Tokens:357,623
Snippets:2,842
Trust Score:8.3
Update:1 week ago
Show doc for...
Tokens:
Raw
### Good names example

Source: https://google.github.io/styleguide/objcguide.html

Shows descriptive variable names and object initialization as recommended by the style guide.

```objectivec
// Good names.
int numberOfErrors = 0;
int completedConnectionsCount = 0;
tickets = [[NSMutableArray alloc] init];
userInfo = [someObject object];
port = [network port];
NSDate *gAppLaunchDate;

```

--------------------------------

### Module import example

Source: https://google.github.io/styleguide/javaguide.html

Shows the syntax for a module import, which is not used according to the style guide.

```java
import module java.base;
```

--------------------------------

### Example header and implementation files for Foo class

Source: https://google.github.io/styleguide/objcguide.html

These two files form the canonical example of the style guide: a header declaring the Foo interface and a source file implementing it. The header shows required comments for all non-trivial declarations, property attributes, and designated initializer annotation. The implementation shows the matching method definitions, including overriding the superclass designated initializer and using a class extension for private state.

```objectivec
#import <Foundation/Foundation.h>

#import "path/to/Bar.h"

/**
 * A sample class demonstrating good Objective-C style. All interfaces,
 * categories, and protocols (read: all non-trivial top-level declarations
 * in a header) MUST be commented. Comments must also be adjacent to the
 * object they're documenting.
 */
@interface Foo : NSObject

/** The retained Bar. */
@property(nonatomic) Bar *bar;

/** The current drawing attributes. */
@property(nonatomic, copy) NSDictionary<NSString *, NSNumber *> *attributes;

/**
 * Convenience creation method.
 * See -initWithBar: for details about @c bar.
 *
 * @param bar The string for fooing.
 * @return An instance of Foo.
 */
+ (instancetype)fooWithBar:(Bar *)bar;

/**
 * Initializes and returns a Foo object using the provided Bar instance.
 *
 * @param bar A string that represents a thing that does a thing.
 */
- (instancetype)initWithBar:(Bar *)bar NS_DESIGNATED_INITIALIZER;

/**
 * Does some work with @c blah.
 *
 * @param blah
 * @return YES if the work was completed; NO otherwise.
 */
- (BOOL)doWorkWithBlah:(NSString *)blah;

@end

```

```objectivec
#import "Shared/Util/Foo.h"

@implementation Foo {
  /** The string used for displaying "hi". */
  NSString *_string;
}

+ (instancetype)fooWithBar:(Bar *)bar {
  return [[self alloc] initWithBar:bar];
}

- (instancetype)init {
  // Classes with a custom designated initializer should always override
  // the superclass's designated initializer.
  return [self initWithBar:nil];
}

- (instancetype)initWithBar:(Bar *)bar {
  self = [super init];
  if (self) {
    _bar = [bar copy];
    _string = [[NSString alloc] initWithFormat:@"hi %d", 3];
    _attributes = @{
      @"color" : UIColor.blueColor,
      @"hidden" : @NO
    };
  }
  return self;
}

- (BOOL)doWorkWithBlah:(NSString *)blah {
  // Work should be done here.
  return NO;
}

@end

```

--------------------------------

### Create runnable example in Go test file

Source: https://google.github.io/styleguide/go/best-practices.html

Test files can contain runnable examples that appear attached to the corresponding documentation in godoc. This example shows a runnable example with an Output comment that godoc uses to verify the output.

```go
// Good:
func ExampleConfig_WriteTo() {
  cfg := &Config{
    Name: "example",
  }
  if err := cfg.WriteTo(os.Stdout); err != nil {
    log.Exitf("Failed to write config: %s", err)
  }
  // Output:
  // {
  //   "name": "example"
  // }
}


```

--------------------------------

### Explain cleanup with example for http.Get

Source: https://google.github.io/styleguide/go/best-practices.html

Example of explaining how to clean up resources when it is potentially unclear. Shows closing resp.Body and reading the body.

```go
// Good:
// Get issues a GET to the specified URL.
//
// When err is nil, resp always contains a non-nil resp.Body.
// Caller should close resp.Body when done reading from it.
//
//    resp, err := http.Get("http://example.com/")
//    if err != nil {
//        // handle error
//    }
//    defer resp.Body.Close()
//    body, err := io.ReadAll(resp.Body)
func (c *Client) Get(url string) (resp *Response, err error)

```

--------------------------------

### Good Looping and Branching Style

Source: https://google.github.io/styleguide/cppguide.html

Examples of correctly formatted if, else if, while, do-while, and for statements following the style guide.

```cpp
if (condition) {                   // Good - no spaces inside parentheses, space before brace.
  DoOneThing();                    // Good - two-space indent.
  DoAnotherThing();
} else if (int a = f(); a != 3) {  // Good - closing brace on new line, else on same line.
  DoAThirdThing(a);
} else {
  DoNothing();
}

// Good - the same rules apply to loops.
while (condition) {
  RepeatAThing();
}

// Good - the same rules apply to loops.
do {
  RepeatAThing();
} while (condition);

// Good - the same rules apply to loops.
for (int i = 0; i < 10; ++i) {
  RepeatAThing();
}
```

--------------------------------

### Module docstring example

Source: https://google.github.io/styleguide/pyguide.html

Example of a module-level docstring with a one-line summary, blank line, and detailed description including usage example.

```python
"""A one-line summary of the module or program, terminated by a period.

Leave one blank line.  The rest of this docstring should contain an
overall description of the module or program.  Optionally, it may also
contain a brief description of exported classes and functions and/or usage
examples.

Typical usage example:

  foo = ClassFoo()
  bar = foo.function_bar()
"""

```

--------------------------------

### C# Coding Conventions Example

Source: https://google.github.io/styleguide/csharp-style.html

A comprehensive example demonstrating standard C# naming conventions, indentation, and structural formatting for namespaces, classes, interfaces, and methods.

```csharp
using System;                                       // `using` goes at the top, outside the
                                                    // namespace.

namespace MyNamespace {                             // Namespaces are PascalCase.
                                                    // Indent after namespace.
  public interface IMyInterface {                   // Interfaces start with 'I'
    public int Calculate(float value, float exp);   // Methods are PascalCase
                                                    // ...and space after comma.
  }

  public enum MyEnum {                              // Enumerations are PascalCase.
    Yes,                                            // Enumerators are PascalCase.
    No,
  }

  public class MyClass {                            // Classes are PascalCase.
    public int Foo = 0;                             // Public member variables are
                                                    // PascalCase.
    public bool NoCounting = false;                 // Field initializers are encouraged.
    private class Results {
      public int NumNegativeResults = 0;
      public int NumPositiveResults = 0;
    }
    private Results _results;                       // Private member variables are
                                                    // _camelCase.
    public static int NumTimesCalled = 0;
    private const int _bar = 100;                   // const does not affect naming
                                                    // convention.
    private int[] _someTable = {                    // Container initializers use a 2
      2, 3, 4,                                      // space indent.
    }

    public MyClass() {
      _results = new Results {
        NumNegativeResults = 1,                     // Object initializers use a 2 space
        NumPositiveResults = 1,                     // indent.
      };
    }

    public int CalculateValue(int mulNumber) {      // No line break before opening brace.
      var resultValue = Foo * mulNumber;            // Local variables are camelCase.
      NumTimesCalled++;
      Foo += _bar;

      if (!NoCounting) {                            // No space after unary operator and
                                                    // space after 'if'.
        if (resultValue < 0) {                      // Braces used even when optional and
                                                    // spaces around comparison operator.
          _results.NumNegativeResults++;
        } else if (resultValue > 0) {               // No newline between brace and else.
          _results.NumPositiveResults++;
        }
      }

      return resultValue;
    }

    public void ExpressionBodies() {
      // For simple lambdas, fit on one line if possible, no brackets or braces required.
      Func<int, int> increment = x => x + 1;

      // Closing brace aligns with first character on line that includes the opening brace.
      Func<int, int, long> difference1 = (x, y) => {
        long diff = (long)x - y;
        return diff >= 0 ? diff : -diff;
      };

      // If defining after a continuation line break, indent the whole body.
      Func<int, int, long> difference2 =
          (x, y) => {
            long diff = (long)x - y;
            return diff >= 0 ? diff : -diff;
          };

      // Inline lambda arguments also follow these rules. Prefer a leading newline before
      // groups of arguments if they include lambdas.
      CallWithDelegate(
          (x, y) => {
            long diff = (long)x - y;
            return diff >= 0 ? diff : -diff;
          });
    }

    void DoNothing() {}                             // Empty blocks may be concise.

    // If possible, wrap arguments by aligning newlines with the first argument.
    void AVeryLongFunctionNameThatCausesLineWrappingProblems(int longArgumentName,
                                                             int p1, int p2) {}

    // If aligning argument lines with the first argument doesn't fit, or is difficult to
    // read, wrap all arguments on new lines with a 4 space indent.
    void AnotherLongFunctionNameThatCausesLineWrappingProblems(
        int longArgumentName, int longArgumentName2, int longArgumentName3) {}

    void CallingLongFunctionName() {
      int veryLongArgumentName = 1234;
      int shortArg = 1;
      // If possible, wrap arguments by aligning newlines with the first argument.
      AnotherLongFunctionNameThatCausesLineWrappingProblems(shortArg, shortArg,
                                                            veryLongArgumentName);
      // If aligning argument lines with the first argument doesn't fit, or is difficult to
      // read, wrap all arguments on new lines with a 4 space indent.
      AnotherLongFunctionNameThatCausesLineWrappingProblems(
          veryLongArgumentName, veryLongArgumentName, veryLongArgumentName);
    }
  }
}
```

--------------------------------

### Omit library prefixes: good example

Source: https://google.github.io/styleguide/lispguide.html

This example shows the recommended practice of omitting the package name prefix, resulting in cleaner client code.

```common-lisp
(in-package #:varint)
(defun length64 () ... )

(in-package #:client-code)
(defconst +padding+ (varint:length64 +end-token+))  ; reads nicely with package

```

--------------------------------

### External context vs. local names: bad example

Source: https://google.github.io/styleguide/go/decisions.html

Avoid repeating package context in type and method names; this example shows the repetitive style.

```go
// Bad:
// In package "ads/targeting/revenue/reporting"
type AdsTargetingRevenueReport struct{}

func (p *Project) ProjectName() string

```

--------------------------------

### Static member qualification example

Source: https://google.github.io/styleguide/javaguide.html

Demonstrates the correct way to qualify static members using the class name, with good and bad examples.

```java
Foo aFoo = ...;
Foo.aStaticMethod(); // good
aFoo.aStaticMethod(); // bad
somethingThatYieldsAFoo().aStaticMethod(); // very bad
```

--------------------------------

### External context vs. local names: good example

Source: https://google.github.io/styleguide/go/decisions.html

Omit redundant package context from type and method names; this is the improved version of the previous example.

```go
// Good:
// In package "ads/targeting/revenue/reporting"
type Report struct{}

func (p *Project) Name() string

```

--------------------------------

### Naming conventions: noun-like names

Source: https://google.github.io/styleguide/go/best-practices.html

Functions that return something should have noun-like names and avoid the prefix 'Get'. The good example uses JobName, while the bad example uses GetJobName.

```go
// Good:
func (c *Config) JobName(key string) (value string, ok bool)

```

```go
// Bad:
func (c *Config) GetJobName(key string) (value string, ok bool)

```

--------------------------------

### Prefixes example

Source: https://google.github.io/styleguide/objcguide.html

Shows how to use prefixes for global functions, constants, protocols, and classes to avoid naming collisions.

```objectivec
/** An example error domain. */
GTM_EXTERN NSString *GTMExampleErrorDomain;

/** Gets the default time zone. */
GTM_EXTERN NSTimeZone *GTMGetDefaultTimeZone(void);

/** An example delegate. */
@protocol GTMExampleDelegate <NSObject>
@end

/** An example class. */
@interface GTMExample : NSObject
@end

```

--------------------------------

### Custom TestMain with runMain for database setup

Source: https://google.github.io/styleguide/go/best-practices.html

Shows a custom TestMain entrypoint that sets up a database once for all tests and cleans it up via defer. It uses a separate runMain function to allow defers to execute before os.Exit, and logs fatal errors to STDERR.

```go
// Good:
var db *sql.DB

func TestInsert(t *testing.T) { /* omitted */ }

func TestSelect(t *testing.T) { /* omitted */ }

func TestUpdate(t *testing.T) { /* omitted */ }

func TestDelete(t *testing.T) { /* omitted */ }

// runMain sets up the test dependencies and eventually executes the tests.
// It is defined as a separate function to enable the setup stages to clearly
// defer their teardown steps.
func runMain(ctx context.Context, m *testing.M) (code int, err error) {
    ctx, cancel := context.WithCancel(ctx)
    defer cancel()

    d, err := setupDatabase(ctx)
    if err != nil {
        return 0, err
    }
    defer d.Close() // Expressly clean up database.
    db = d          // db is defined as a package-level variable.

    // m.Run() executes the regular, user-defined test functions.
    // Any defer statements that have been made will be run after m.Run()
    // completes.
    return m.Run(), nil
}

func TestMain(m *testing.M) {
    code, err := runMain(context.Background(), m)
    if err != nil {
        // Failure messages should be written to STDERR, which log.Fatal uses.
        log.Fatal(err)
    }
    // NOTE: defer statements do not run past here due to os.Exit
    //       terminating the process.
    os.Exit(code)
}

```

--------------------------------

### Size hints and preallocation

Source: https://google.github.io/styleguide/go/best-practices.html

Demonstrates size hints and preallocation for slices and maps, with comments explaining the chosen capacities. Preallocating more than needed can waste memory or harm performance.

```go
// Good:
var (
    // Preferred buffer size for target filesystem: st_blksize.
    buf = make([]byte, 131072)
    // Typically process up to 8-10 elements per run (16 is a safe assumption).
    q = make([]Node, 0, 16)
    // Each shard processes shardSize (typically 32000+) elements.
    seen = make(map[string]bool, shardSize)
)

```

--------------------------------

### Function Names in PascalCase

Source: https://google.github.io/styleguide/cppguide.html

Functions should start with a capital letter and have a capital letter for each new word, as shown in these examples.

```cpp
AddTableEntry()
DeleteUrl()
OpenFileOrDie()
```

--------------------------------

### Avoid t.Fatal in goroutines: use t.Errorf

Source: https://google.github.io/styleguide/go/best-practices.html

Use t.Errorf instead of t.Fatal in goroutines started by a test. The example shows a test that starts multiple goroutines and reports errors from them, while using t.Fatalf only in the test's own goroutine.

```go
// Good:
func TestRevEngine(t *testing.T) {
    engine, err := Start()
    if err != nil {
        t.Fatalf("Engine failed to start: %v", err)
    }

    num := 11
    var wg sync.WaitGroup
    wg.Add(num)
    for i := 0; i < num; i++ {
        go func() {
            defer wg.Done()
            if err := engine.Vroom(); err != nil {
                // This cannot be t.Fatalf.
                t.Errorf("No vroom left on engine: %v", err)
                return
            }
            if rpm := engine.Tachometer(); rpm > 1e6 {
                t.Errorf("Inconceivable engine rate: %d", rpm)
            }
        }()
    }
    wg.Wait()

    if seen := engine.NumVrooms(); seen != num {
        t.Errorf("engine.NumVrooms() = %d, want %d", seen, num)
    }
}

```

--------------------------------

### data.fields example: partial GET/PATCH fields

Source: https://google.github.io/styleguide/jsoncguide.html

Shows the 'fields' property used during a partial GET or PATCH request. It should only exist during such operations and should not be empty.

```json
{
  "data": {
    "kind": "user",
    "fields": "author,id",
    "id": "bart",
    "author": "Bart"
  }
}

```

--------------------------------

### JSDoc param tags on same line (incorrect)

Source: https://google.github.io/styleguide/tsguide.html

This example shows the incorrect way to combine multiple `@param` tags on a single line, which is not allowed by the style guide.

```typescript
/**
 * The "param" tag must occupy its own line and may not be combined.
 * @param left @param right
 */
function add(left: number, right: number) { ... }
```

--------------------------------

### File header example with in-package and declaim

Source: https://google.github.io/styleguide/lispguide.html

Shows the recommended file header: a brief description, an in-package form, and a file-specific declaim optimize declaration.

```common-lisp
;;;; Variable length encoding for integers and floating point numbers.

(in-package #:varint)
(declaim #.*optimize-default*)

```

--------------------------------

### Guards and pattern matches example for nth function

Source: https://google.github.io/styleguide/haskellguide.html

Shows the same nth function implemented with guards and pattern matches, which the guide recommends over nested if-then-else for clarity.

```haskell
nth :: Int -> [a] -> Maybe a
nth i _     | i < 0 = Nothing
nth _ []            = Nothing
nth 0 (x:xs)        = Just x
nth i (_:xs)        = nth (i-1) xs

```

--------------------------------

### Import proto and gRPC packages with pb and grpc suffixes

Source: https://google.github.io/styleguide/go/best-practices.html

Shows the recommended import naming convention for proto and gRPC generated packages, using the `pb` and `grpc` suffixes respectively.

```go
// Good:
import (
    foopb "path/to/package/foo_service_go_proto"
    foogrpc "path/to/package/foo_service_go_grpc"
)

```

--------------------------------

### Example of initial JSON object for naming conflict

Source: https://google.github.io/styleguide/jsoncguide.html

Shows a JSON object with 'apiVersion' and 'data' properties, used as a starting point for discussing naming conflicts.

```json
{
  "apiVersion": "1.0",
  "data": {
    "recipeName": "pizza",
    "ingredients": ["tomatoes", "cheese", "sausage"]
  }
}
```

--------------------------------

### if-then-else example for nth function

Source: https://google.github.io/styleguide/haskellguide.html

Shows a nested if-then-else implementation of nth. The guide suggests considering guards and pattern matches instead, as they are clearer at the outer level.

```haskell
nth :: Int -> [a] -> Maybe a
nth i xs = if null xs || i < 0
    then Nothing
    else if i == 0
        then Just (head xs)
        else nth (i-1) (tail xs)

```

--------------------------------

### Type Names Examples

Source: https://google.github.io/styleguide/cppguide.html

Shows the naming convention for classes, structs, typedefs, using aliases, and enums: start with a capital letter and use a capital letter for each new word, no underscores.

```cpp
// classes and structs
class UrlTable { ...
class UrlTableTester { ...
struct UrlTableProperties { ...

// typedefs
typedef hash_map<UrlTableProperties*, std::string> PropertiesMap;

// using aliases
using PropertiesMap = hash_map<UrlTableProperties*, std::string>;

// enums
enum class UrlTableError { ...

```

--------------------------------

### MustXYZ helper for package-level initialization

Source: https://google.github.io/styleguide/go/decisions.html

Shows the recommended pattern for a MustXYZ helper that panics on error, used to initialize package-level variables at startup. The helper is called in a value context to set a package-level constant.

```go
// Good:
func MustParse(version string) *Version {
    v, err := Parse(version)
    if err != nil {
        panic(fmt.Sprintf("MustParse(%q) = _, %v", version, err))
    }
    return v
}

// Package level "constant". If we wanted to use `Parse`, we would have had to
// set the value in `init`.
var DefaultVersion = MustParse("1.2.3")

```

--------------------------------

### Package nickname definition (defpackage with :nicknames)

Source: https://google.github.io/styleguide/lispguide.html

Shows a package definition using :nicknames, which is prohibited by the style guide. The example uses a conditional reader to include the nickname only when the 'foo' feature is absent.

```lisp
(defpackage :regression-test
  (:nicknames :rtest #-foo :rt))

```

--------------------------------

### Good: explicit and commented Go alternatives

Source: https://google.github.io/styleguide/go/guide.html

Two Go examples that show more explicit and commented alternatives to the bad examples above. They make the logic clearer and call attention to important behavior.

```go
// Good:
u, err := db.UserByID(userID)
if err != nil {
    return fmt.Errorf("invalid origin user: %s", err)
}
user = u

```

```go
// Good:
// Gregorian leap years aren't just year%4 == 0.
// See https://en.wikipedia.org/wiki/Leap_year#Algorithm.
var (
    leap4   = year%4 == 0
    leap100 = year%100 == 0
    leap400 = year%400 == 0
)
leap := leap4 && (!leap100 || leap400)

```

--------------------------------

### Shell quoting examples: variables, command substitutions, arrays, and special parameters

Source: https://google.github.io/styleguide/shellguide.html

Demonstrates correct quoting practices for variables, command substitutions, arrays, and special parameters like $@ and $*. Includes examples of quoting meta characters and handling optional arguments. The final two lines compare the behavior of "$*" and "$@" when passing arguments.

```shell
# 'Single' quotes indicate that no substitution is desired.
# "Double" quotes indicate that substitution is required/tolerated.

# Simple examples

# "quote command substitutions"
# Note that quotes nested inside "$()" don't need escaping.
flag="$(some_command and its args "$@" 'quoted separately')"

# "quote variables"
echo "${flag}"

# Use arrays with quoted expansion for lists.
declare -a FLAGS
FLAGS=( --foo --bar='baz' )
readonly FLAGS
mybinary "${FLAGS[@]}"

# It's ok to not quote internal integer variables.
if (( $# > 3 )); then
  echo "ppid=${PPID}"
fi

# "never quote literal integers"
value=32
# "quote command substitutions", even when you expect integers
number="$(generate_number)"

# "prefer quoting words", not compulsory
readonly USE_INTEGER='true'

# "quote shell meta characters"
echo 'Hello stranger, and well met. Earn lots of $$$'
echo "Process $$: Done making \$\$\$."

# "command options or path names"
# ($1 is assumed to contain a value here)
grep -li Hugo /dev/null "$1"

# Less simple examples
# "quote variables, unless proven false": ccs might be empty
git send-email --to "${reviewers}" ${ccs:+"--cc" "${ccs}"}

# Positional parameter precautions: $1 might be unset
# Single quotes leave regex as-is.
grep -cP '([Ss]pecial|\|?characters*)$' ${1:+"$1"}

# For passing on arguments,
# "$@" is right almost every time, and
# $* is wrong almost every time:
#
# * $* and $@ will split on spaces, clobbering up arguments
#   that contain spaces and dropping empty strings;
# * "$@" will retain arguments as-is, so no args
#   provided will result in no args being passed on;
#   This is in most cases what you want to use for passing
#   on arguments.
# * "$*" expands to one argument, with all args joined
#   by (usually) spaces,
#   so no args provided will result in one empty string
#   being passed on.
#
# Consult
# https://www.gnu.org/software/bash/manual/html_node/Special-Parameters.html and
# https://mywiki.wooledge.org/BashGuide/Arrays for more

(set -- 1 "2 two" "3 three tres"; echo $#; set -- "$*"; echo "$#, $@")
(set -- 1 "2 two" "3 three tres"; echo $#; set -- "$@"; echo "$#, $@")
```

--------------------------------

### Java block comment style example

Source: https://google.github.io/styleguide/javaguide.html

Block comments can use /* ... */ or // ... style. For multi-line /* ... */ comments, subsequent lines must start with * aligned with the previous line.

```java
/*
 * This is          // And so           /* Or you can
 * okay.            // is this.          * even do this. */
 */
```

--------------------------------

### Import proto package with descriptive pb suffix

Source: https://google.github.io/styleguide/go/best-practices.html

Shows the recommended import naming convention for a proto package when the package name is not obvious, using the proto package name up to `_go` with a `pb` suffix.

```go
// Good:
import (
    pushqueueservicepb "path/to/package/push_queue_service_go_proto"
)

```

--------------------------------

### Bad: Multi-line function signature

Source: https://google.github.io/styleguide/go/decisions.html

Avoid breaking a function signature across lines because it can confuse indentation and make the body appear to start earlier. This example shows a multi-line signature that is discouraged.

```go
// Bad:
func (r *SomeType) SomeLongFunctionName(foo1, foo2, foo3 string,
    foo4, foo5, foo6 int) {
    foo7 := bar(foo1)
    // ...
}

```

--------------------------------

### Use cmp and fmt for equality checks

Source: https://google.github.io/styleguide/go/decisions.html

Prefer using standard libraries like cmp and fmt for equality comparisons. This example compares a got value with a want value and reports a clear error message on mismatch.

```go
// Good:
var got BlogPost

want := BlogPost{
    Comments: 2,
    Body:     "Hello, world!",
}

if !cmp.Equal(got, want) {
    t.Errorf("Blog post = %v, want = %v", got, want)
}

```

--------------------------------

### General Formatting: New Lines and Indentation

Source: https://google.github.io/styleguide/htmlcssguide.html

Examples of general formatting: each block, list, or table element starts on a new line and child elements are indented. Note that list items may be placed on one line if whitespace issues arise.

```html
<blockquote>
  <p><em>Space</em>, the final frontier.</p>
</blockquote>
```

```html
<ul>
  <li>Moe
  <li>Larry
  <li>Curly
</ul>
```

```html
<table>
  <thead>
    <tr>
      <th scope="col">Income
      <th scope="col">Taxes
  <tbody>
    <tr>
      <td>$ 5.00
      <td>$ 4.50
</table>
```

--------------------------------

### Verbose logging with log.V: good and bad patterns

Source: https://google.github.io/styleguide/go/best-practices.html

Shows the recommended pattern for verbose logging with log.V to avoid expensive calls when verbosity is off, and the anti-pattern that calls sql.Explain unconditionally.

```go
// Good:
for _, sql := range queries {
  log.V(1).Infof("Handling %v", sql)
  if log.V(2) {
    log.Infof("Handling %v", sql.Explain())
  }
  sql.Run(...)
}

```

```go
// Bad:
// sql.Explain called even when this log is not printed.
log.V(2).Infof("Handling %v", sql.Explain())

```

--------------------------------

### Variable and array initialization with =, (), and {}

Source: https://google.github.io/styleguide/cppguide.html

Shows the three allowed initialization syntaxes: =, (), and {}. All are correct for variables and arrays.

```cpp
int x = 3;
int x(3);
int x{3};
std::string name = "Some Name";
std::string name("Some Name");
std::string name{"Some Name"};
```

--------------------------------

### Wildcard Expansion: Use Explicit Path ./* Instead of *

Source: https://google.github.io/styleguide/shellguide.html

Use `./*` instead of `*` to avoid accidentally matching files that start with `-`. The first example shows the incorrect `rm -v *` deleting files and directories; the second shows the correct `rm -v ./*` behavior.

```bash
# Here's the contents of the directory:
# -f  -r  somedir  somefile

# Incorrectly deletes almost everything in the directory by force
psa@bilby$ rm -v *
removed directory: `somedir'
removed `somefile'
```

```bash
# As opposed to:
psa@bilby$ rm -v ./*
removed `./-f'
removed `./-r'
rm: cannot remove `./somedir': Is a directory
removed `./somefile'
```

--------------------------------

### Example of correctly ordered includes in fooserver.cc

Source: https://google.github.io/styleguide/cppguide.html

Illustrates the preferred include order: related header, C system headers, C++ standard library headers, and project headers, each group separated by a blank line and alphabetized.

```cpp
#include "foo/server/fooserver.h"

#include <sys/types.h>
#include <unistd.h>

#include <string>
#include <vector>

#include "base/basictypes.h"
#include "foo/server/bar.h"
#include "third_party/absl/flags/flag.h"
```

--------------------------------

### Function declaration comment example for GetIterator

Source: https://google.github.io/styleguide/cppguide.html

Shows a comment block for a function declaration that describes inputs, outputs, null handling, and usage constraints. The comment uses an implied subject 'This function' and starts with a verb phrase. It also includes an equivalent code snippet in the comment.

```cpp
// Returns an iterator for this table, positioned at the first entry
// lexically greater than or equal to `start_word`. If there is no
// such entry, returns a null pointer. The client must not use the
// iterator after the underlying GargantuanTable has been destroyed.
//
// This method is equivalent to:
//    std::unique_ptr<Iterator> iter = table->NewIterator();
//    iter->Seek(start_word);
//    return iter;
std::unique_ptr<Iterator> GetIterator(absl::string_view start_word) const;
```

--------------------------------

### External context vs. local names: good Connection

Source: https://google.github.io/styleguide/go/decisions.html

Use a concise type name that omits the package name; this is the improved version of the previous example.

```go
// Good:
// In package "sqldb"
type Connection struct{}

```

--------------------------------

### method and params example

Source: https://google.github.io/styleguide/jsoncguide.html

Shows the method and params properties together in a JSON-RPC request. The method indicates the operation, and params provides the input parameters.

```json
{
  "method": "people.get",
  "params": {
    "userId": "@me",
    "groupId": "@self"
  }
}
```

--------------------------------

### Undocumented public aliases in C++ (bad example)

Source: https://google.github.io/styleguide/cppguide.html

Example of aliases that do not document intended use and are not meant for client use. This is a negative example to avoid.

```C++
namespace mynamespace {
// Bad: none of these say how they should be used.
using DataPoint = ::foo::Bar*;
using ::std::unordered_set;  // Bad: just for local convenience
using ::std::hash;           // Bad: just for local convenience
typedef unordered_set<DataPoint, hash<DataPoint>, DataPointComparator> TimeSeries;
}  // namespace mynamespace
```

--------------------------------

### Package prefix usage example

Source: https://google.github.io/styleguide/lispguide.html

Shows how package names are used as prefixes for symbols, with functions like `fifo-add-to` and `fifo-clear-all` called as `(fifo:add-to ...)`.

```lisp
(fifo:add-to ...)
(fifo:clear-all ...)

```

--------------------------------

### Amortize common test setup with sync.Once

Source: https://google.github.io/styleguide/go/best-practices.html

Shows how to amortize expensive common test setup using a package-level struct with sync.Once. The first block defines the dataset holder and mustLoadDataset helper; the second shows multiple test functions calling it so the load cost is paid once. Note that common teardown is not handled, and sync.Once may be problematic if the setup relies on a context because racing calls cannot respect cancellation while waiting.

```go
// Good:
var dataset struct {
    once sync.Once
    data []byte
    err  error
}

func mustLoadDataset(t *testing.T) []byte {
    t.Helper()
    dataset.once.Do(func() {
        data, err := os.ReadFile("path/to/your/project/testdata/dataset")
        // dataset is defined as a package-level variable.
        dataset.data = data
        dataset.err = err
    })
    if err := dataset.err; err != nil {
        t.Fatalf("Could not load dataset: %v", err)
    }
    return dataset.data
}

```

```go
// Good:
func TestParseData(t *testing.T) {
    data := mustLoadDataset(t)

    // As documented above.
}

func TestListContents(t *testing.T) {
    data := mustLoadDataset(t)

    // As documented above.
}

func TestRegression682831(t *testing.T) {
    if got, want := guessOS("zpc79.example.com"), "grhat"; got != want {
        t.Errorf(`guessOS("zpc79.example.com") = %q, want %q`, got, want)
    }
}

```

--------------------------------

### Use unique, complete names for headings: Bad example

Source: https://google.github.io/styleguide/docguide/style.html

Avoid using generic heading names like 'Summary' and 'Example' that repeat across sections. This example shows the incorrect style.

```markdown
## Foo
### Summary
### Example
## Bar
### Summary
### Example


```

--------------------------------

### Good: sidecar.Registry with explicit instance state

Source: https://google.github.io/styleguide/go/best-practices.html

Shows the recommended approach: expose a Registry type with a constructor and a Register method, letting clients create and pass instances instead of relying on package-level state.

```go
// Good:
// Package sidecar manages subprocesses that provide features for applications.
package sidecar

type Registry struct { plugins map[string]*Plugin }

func New() *Registry { return &Registry{plugins: make(map[string]*Plugin)} }

func (r *Registry) Register(name string, p *Plugin) error { ... }

```

--------------------------------

### Bad Argument Naming Example

Source: https://google.github.io/styleguide/csharp-style.html

An example of a function call with ambiguous arguments that are difficult to interpret.

```csharp
// Bad - what are these arguments?
DecimalNumber product = CalculateProduct(values, 7, false, null);
```

--------------------------------

### Use unique, complete names for headings: Good example

Source: https://google.github.io/styleguide/docguide/style.html

Use unique and fully descriptive heading names, such as 'Foo summary' and 'Foo example', to ensure clear link anchors. This example shows the preferred style.

```markdown
## Foo
### Foo summary
### Foo example
## Bar
### Bar summary
### Bar example


```

--------------------------------

### Using REDUCE to avoid copying a list

Source: https://google.github.io/styleguide/lispprogrammingguide.html

Shows the use of REDUCE with :key and :initial-value to achieve the same result as the APPLY example while avoiding the copy and potential CALL-ARGUMENTS-LIMIT issues.

```lisp
;; This does the same thing while avoiding the copy
(reduce #'+ frobs :key #'acc :initial-value 0)

```

--------------------------------

### Common Variable Names Example

Source: https://google.github.io/styleguide/cppguide.html

Shows the correct snake_case naming for variables and an incorrect mixed-case example.

```cpp
std::string table_name;  // OK - snake_case.

```

```cpp
std::string tableName;   // Bad - mixed case.

```

--------------------------------

### Java enum example

Source: https://google.github.io/styleguide/jsoncguide.html

Shows a Java enum representing colors, used as an example for enum values.

```java
public enum Color {
  WHITE,
  BLACK,
  RED,
  YELLOW,
  BLUE
}
```

--------------------------------

### Good: Calling EnableReplication with variadic options

Source: https://google.github.io/styleguide/go/best-practices.html

Shows how to call the refactored EnableReplication from another package, both with many options and with no options. Demonstrates the flexibility and simplicity of the variadic options pattern.

```go
// Good:
func foo(ctx context.Context) {
    // Complex call:
    storage.EnableReplication(ctx, config, []string{"po", "is", "ea"},
        storage.ReadonlyCells("ix", "gg"),
        storage.OverwritePolicies(true),
        storage.ReplicationInterval(1*time.Hour),
        storage.CopyWorkers(100),
        storage.HealthWatcher(watcher),
    )

    // Simple call:
    storage.EnableReplication(ctx, config, []string{"po", "is", "ea"})
}

```
Tokens:
Raw