Convert Figma logo to code with AI

google logostyleguide

Style guides for Google-originated open-source projects

37,353
13,302
37,353
278

Top Related Projects

144,559

JavaScript Style Guide

29,086

🌟 JavaScript Style Guide, with linter & automatic code fixer

100,679

TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

5,905

:vertical_traffic_light: An extensible linter for the TypeScript language

49,268

Prettier is an opinionated code formatter.

12,626

A Ruby static code analyzer and formatter, based on the community Ruby style guide.

Quick Overview

The google/styleguide repository is a collection of style guides for various programming languages and tools used at Google. It provides comprehensive guidelines for writing clean, consistent, and maintainable code across different projects and teams. These style guides cover languages such as C++, Python, Java, R, Shell, and more.

Pros

  • Promotes consistency and readability across large codebases
  • Based on Google's extensive experience in software development
  • Regularly updated and maintained
  • Includes linter configurations for easy enforcement of style rules

Cons

  • Some guidelines may be opinionated and not universally accepted
  • Can be overwhelming for beginners due to the level of detail
  • May conflict with established practices in other organizations or open-source projects
  • Requires effort to implement and enforce across teams

Getting Started

To use the Google Style Guides:

  1. Visit the google/styleguide repository on GitHub.
  2. Choose the style guide for your programming language or tool.
  3. Read the guide thoroughly and familiarize yourself with the conventions.
  4. Implement the guidelines in your project:
    • For Python: Use the pylint configuration file provided.
    • For C++: Use the cpplint tool for checking adherence to the style guide.
    • For Java: Configure your IDE to use the provided XML file for code formatting.
  5. Consider setting up pre-commit hooks or CI/CD checks to enforce the style guide automatically.

Remember that these guides are meant to be adapted to your project's needs. It's often beneficial to discuss and agree on any modifications with your team before implementation.

Competitor Comparisons

144,559

JavaScript Style Guide

Pros of javascript

  • More comprehensive JavaScript-specific guidelines
  • Regularly updated with modern JavaScript practices
  • Includes explanations and examples for each rule

Cons of javascript

  • Focused solely on JavaScript, less versatile for multi-language projects
  • May be too opinionated for some developers or organizations

Code Comparison

javascript:

// bad
const items = new Array();

// good
const items = [];

styleguide:

// Prefer
const items = [];

// Don't use
const items = new Array();

Summary

The javascript repository provides in-depth JavaScript style guidelines with explanations and examples. It's frequently updated to reflect modern practices but is limited to JavaScript. The styleguide repository offers guidelines for multiple languages, making it more versatile for diverse projects. However, it may not provide as detailed JavaScript-specific guidance.

Both repositories aim to improve code consistency and readability, but they differ in scope and depth. The choice between them depends on project requirements, team preferences, and the languages used in development.

29,086

🌟 JavaScript Style Guide, with linter & automatic code fixer

Pros of Standard

  • Automatic code formatting with minimal configuration
  • Supports multiple languages (JavaScript, TypeScript, JSX)
  • Large community and ecosystem of plugins

Cons of Standard

  • Less flexibility in customizing rules
  • May not be suitable for projects with specific style requirements
  • Limited support for non-JavaScript languages

Code Comparison

Standard:

function example (foo) {
  if (foo) {
    return foo
  }
  return bar
}

Google Style Guide:

function example(foo) {
  if (foo) {
    return foo;
  }
  return bar;
}

Summary

Standard focuses on simplicity and ease of use, with automatic formatting and a "zero-configuration" approach. It's ideal for JavaScript-centric projects and teams that want to avoid style debates.

Google Style Guide provides comprehensive guidelines for multiple languages, offering more flexibility but requiring manual implementation. It's better suited for large, multi-language projects or organizations with specific style preferences.

The choice between the two depends on project requirements, team preferences, and the desire for customization versus simplicity.

100,679

TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

Pros of TypeScript

  • Provides a full-fledged programming language with static typing, enhancing code quality and developer productivity
  • Offers extensive documentation, including a comprehensive handbook and API reference
  • Actively maintained with frequent updates and a large community

Cons of TypeScript

  • More complex setup and learning curve compared to simple style guides
  • Requires compilation step, which can add overhead to development process
  • May introduce additional dependencies and tooling requirements

Code Comparison

TypeScript example:

interface Person {
  name: string;
  age: number;
}

function greet(person: Person): string {
  return `Hello, ${person.name}!`;
}

Styleguide example (JavaScript):

/**
 * @param {Object} person
 * @param {string} person.name
 * @param {number} person.age
 * @return {string}
 */
function greet(person) {
  return 'Hello, ' + person.name + '!';
}

The TypeScript example demonstrates static typing and interface definitions, while the Styleguide example relies on JSDoc comments for type information. TypeScript provides more robust type checking at compile-time, whereas the Styleguide approach offers guidance without enforcing types during development.

5,905

:vertical_traffic_light: An extensible linter for the TypeScript language

Pros of TSLint

  • Specifically designed for TypeScript, offering more tailored linting rules
  • Provides automated fixing capabilities for many linting issues
  • Integrates well with popular IDEs and build tools

Cons of TSLint

  • Limited to TypeScript, while Styleguide covers multiple languages
  • Requires additional setup and configuration compared to Styleguide
  • Less comprehensive documentation and examples than Styleguide

Code Comparison

TSLint configuration example:

{
  "rules": {
    "semicolon": [true, "always"],
    "quotemark": [true, "single"],
    "indent": [true, "spaces", 2]
  }
}

Styleguide example (JavaScript):

// Use spaces for indentation
// Use single quotes for strings
// Always use semicolons
function example() {
  const greeting = 'Hello, world!';
  console.log(greeting);
}

While TSLint provides a configuration file to enforce rules, Styleguide offers guidelines through documentation and examples. TSLint's approach allows for automated enforcement, while Styleguide relies more on manual adherence to the defined standards.

49,268

Prettier is an opinionated code formatter.

Pros of Prettier

  • Automated code formatting, reducing manual effort and team debates
  • Supports multiple languages and integrates with various editors/IDEs
  • Highly configurable with options for different coding styles

Cons of Prettier

  • Less flexibility in formatting choices compared to manual styling
  • May require initial setup and configuration for team adoption
  • Can sometimes produce unexpected or undesired formatting results

Code Comparison

Styleguide (manual formatting):

public class MyClass {
    private int myField;
    
    public void myMethod(int param1, String param2) {
        // Method implementation
    }
}

Prettier (automated formatting):

public class MyClass {
  private int myField;

  public void myMethod(int param1, String param2) {
    // Method implementation
  }
}

Summary

Styleguide provides comprehensive guidelines for manual code styling across various languages, while Prettier offers automated code formatting. Prettier excels in consistency and time-saving but may lack some flexibility. Styleguide allows more customization but requires more manual effort. The choice between them depends on team preferences, project requirements, and the desire for automated vs. manual formatting control.

12,626

A Ruby static code analyzer and formatter, based on the community Ruby style guide.

Pros of RuboCop

  • Specifically designed for Ruby, offering more language-specific style checks and auto-corrections
  • Highly configurable with extensive documentation and community-driven rules
  • Actively maintained with frequent updates and a large contributor base

Cons of RuboCop

  • Limited to Ruby language, whereas Styleguide covers multiple languages
  • Can be resource-intensive for large codebases, potentially slowing down CI/CD pipelines
  • Steeper learning curve due to its extensive configuration options

Code Comparison

RuboCop (Ruby):

def example_method(param1, param2)
  result = param1 + param2
  puts "The result is: #{result}"
  result
end

Styleguide (Python):

def example_method(param1, param2):
    result = param1 + param2
    print(f"The result is: {result}")
    return result

Both repositories aim to enforce coding standards, but RuboCop is specifically tailored for Ruby development, while Styleguide provides guidelines for multiple languages. RuboCop offers more automated checks and corrections, making it easier to maintain consistent code style in Ruby projects. However, Styleguide's broader language coverage makes it more versatile for organizations working with multiple programming languages.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Google Style Guides

Every major open-source project has its own style guide: a set of conventions (sometimes arbitrary) about how to write code for that project. It is much easier to understand a large codebase when all the code in it is in a consistent style.

“Style” covers a lot of ground, from “use camelCase for variable names” to “never use global variables” to “never use exceptions.” This project (google/styleguide) links to the style guidelines we use for Google code. If you are modifying a project that originated at Google, you may be pointed to this page to see the style guides that apply to that project.

This project also contains cpplint, a tool to assist with style guide compliance, and google-c-style.el, an Emacs settings file for Google style.

If your project requires that you create a new XML document format, the XML Document Format Style Guide may be helpful. In addition to actual style rules, it also contains advice on designing your own vs. adapting an existing format, on XML instance document formatting, and on elements vs. attributes.

The style guides in this project are licensed under the CC-By 3.0 License, which encourages you to share these documents. See https://creativecommons.org/licenses/by/3.0/ for more details.

The following Google style guide lives outside of this project:

Contributing

With few exceptions, these style guides are copies of Google's internal style guides to assist developers working on Google owned and originated open source projects. Changes to the style guides are made to the internal style guides first and eventually copied into the versions found here. External contributions are not accepted. Pull requests are regularly closed without comment.

People can file issues using the GitHub tracker. Issues that raise questions, justify changes on technical merits, or point out obvious mistakes may get some engagement and could in theory lead to changes, but we are primarily optimizing for Google's internal needs.

Creative Commons License