Google’s Go Style Guide

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
  • Developer-Style-Guides

    Style guides from Google, Facebook, Airbnb, Khan Academy and other tech organizations. Covers JavaScript, Swift, Java, Kotlin, and other popular languages. Made for developers by https://hotpot.ai.

  • has anyone compiled a comprehensive list of style guides from leading companies?

    google has published a style guide, but it doesn't seem like facebook and netflix do.

    it would be awesome to have one central list of best practices from leading tech companies.

    we started one here, but it's woefully limited: https://github.com/HotpotDesign/Developer-Style-Guides

  • guide

    The Uber Go Style Guide.

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

    WorkOS logo
  • is-promise

    Test whether an object looks like a promises-a+ promise

  • There's definitely a balance to strike.

    On the one hand, you don't want to be constantly re-inventing the wheel. If someone has made a great package for doing a specific thing you need (printing data in tables, making ergonomic http requests that cover edge cases, reading an epub file, etc), then IMO you're better off using theirs. They care about it, they've tested it, and the implementation of it is one less thing you have to think about it. If you consider that every line of code that you write/maintain is a liability, then offloading that to others is very convenient.

    On the other hand, external packages typically come without guarantees. Their owner/maintainer could lose interest, get hit by a bus, get hacked, anything. You're running their code in your projects and suddenly, all this uncontrolled code becomes the liability. You'd do best to do _everything_ in house in order to limit your external risk.

    Ultimately, I think there's no single right answer here. Sure, you probably shouldn't add dependencies for things like "left-pad", but the line is a little blurrier for things like npm's "is-promise". It sounds simple enough (and the implementation [0] is only a 3-line function), but I'm unlikely to have written it correctly if I did it from scratch. Plus, it's tested! And lastly, I think your risk is lower the larger an external dependency is. Large projects, like React or Django, are much more upside than liability; it's everything in the medium range that you really need to consider.

    [0]: https://github.com/then/is-promise/blob/ec9bd8a3f576324a1343...

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts