Skip to content
This repository has been archived by the owner on Apr 24, 2024. It is now read-only.
/ styleguide Public archive

Style guides for writing code at GoodHood GmbH

License

Notifications You must be signed in to change notification settings

goodhood-eu/styleguide

Repository files navigation

Coding Style Guide

Welcome to the internet

This repository serves as a reference for our coding standards. You can read the common section, or jump to language specific pages.

Common section

This answers generic questions regardless of language or technology.

Table of Contents

Tabs or Spaces?

Use spaces only, with 2 spaces per indentation level. Never mix tabs and spaces.

⬆ back to top

Maximum Line Length

Limit all lines to a maximum of 90 characters. Going over the limit is tolerated, but frown upon. Please try to avoid it.

⬆ back to top

Blank Lines

Separate top-level function and class definitions with a single blank line.

Separate method definitions inside of a class with a single blank line.

Use a single blank line within the bodies of methods or functions in cases where this improves readability (e.g., for the purpose of delineating logical sections).

⬆ back to top

Trailing Whitespace

Do not leave trailing whitespaces. Use plugins to highlight that for you.

Encoding

UTF-8 is the source file encoding.

⬆ back to top

Annotations

Use annotations when necessary to describe a specific action that must be taken against the indicated block of code.

Write the annotation on the line immediately above the code that the annotation is describing.

The annotation keyword should be followed by a colon and a space, and a descriptive note.

  // FIXME: The client's current state should *not* affect payload processing.
  resetClientState();
  processPayload();

If multiple lines are required by the description, indent subsequent lines with two spaces:

  // TODO: Ensure that the value returned by this call falls within a certain
  //   range, or throw an exception.
  analyze();

Annotation types:

  • TODO: describe missing functionality that should be added at a later date
  • FIXME: describe broken code that must be fixed
  • REVIEW: describe code that should be reviewed to confirm implementation

If a custom annotation is required, the annotation should be documented in the project's README.

⬆ back to top

About

Style guides for writing code at GoodHood GmbH

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published