Repository: Kristories/awesome-guidelines Branch: main Commit: 7f1be745c621 Files: 14 Total size: 35.4 KB Directory structure: gitextract_bomeq6zf/ ├── .editorconfig ├── .gitattributes ├── .github/ │ ├── dependabot.yml │ ├── pull_request_template.md │ └── workflows/ │ ├── lint.yml │ └── stale.yml ├── .gitignore ├── LICENSE ├── README.md ├── code-of-conduct.md ├── contributing.md ├── package.json ├── test.js └── travis.yml ================================================ FILE CONTENTS ================================================ ================================================ FILE: .editorconfig ================================================ root = true [*] charset = utf-8 indent_style = space indent_size = 2 end_of_line = lf trim_trailing_whitespace = true insert_final_newline = true ================================================ FILE: .gitattributes ================================================ * text=auto readme.md merge=union ================================================ FILE: .github/dependabot.yml ================================================ version: 2 updates: - package-ecosystem: "npm" directory: "/" schedule: interval: "daily" reviewers: - "kristories" assignees: - "kristories" ================================================ FILE: .github/pull_request_template.md ================================================ **By submitting this pull request, I promise I have read the [contribution guidelines](https://github.com/Kristories/awesome-guidelines/blob/master/contributing.md) twice and ensured my submission follows it. I realize not doing so wastes the maintainers' time that they could have spent making the world better. 🖖** ⬆⬆⬆⬆⬆⬆⬆⬆⬆⬆ ================================================ FILE: .github/workflows/lint.yml ================================================ name: Lint on: pull_request: branches: [ master ] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 with: fetch-depth: 0 - run: npx awesome-lint ================================================ FILE: .github/workflows/stale.yml ================================================ name: Mark stale issues and pull requests on: schedule: - cron: "59 23 * * *" jobs: stale: runs-on: ubuntu-latest steps: - uses: actions/stale@v1 with: days-before-stale: 20 days-before-close: 1 repo-token: ${{ secrets.GITHUB_TOKEN }} stale-issue-message: 'This issue has been hanging around a bit too long, if needed please update or comment.' stale-pr-message: 'This PR has been hanging around a bit too long, please update/rebase or comment as needed.' stale-issue-label: 'no-issue-activity' stale-pr-label: 'no-pr-activity' ================================================ FILE: .gitignore ================================================ node_modules/ ================================================ FILE: LICENSE ================================================ CC0 1.0 Universal Statement of Purpose The laws of most jurisdictions throughout the world automatically confer exclusive Copyright and Related Rights (defined below) upon the creator and subsequent owner(s) (each and all, an "owner") of an original work of authorship and/or a database (each, a "Work"). Certain owners wish to permanently relinquish those rights to a Work for the purpose of contributing to a commons of creative, cultural and scientific works ("Commons") that the public can reliably and without fear of later claims of infringement build upon, modify, incorporate in other works, reuse and redistribute as freely as possible in any form whatsoever and for any purposes, including without limitation commercial purposes. These owners may contribute to the Commons to promote the ideal of a free culture and the further production of creative, cultural and scientific works, or to gain reputation or greater distribution for their Work in part through the use and efforts of others. For these and/or other purposes and motivations, and without any expectation of additional consideration or compensation, the person associating CC0 with a Work (the "Affirmer"), to the extent that he or she is an owner of Copyright and Related Rights in the Work, voluntarily elects to apply CC0 to the Work and publicly distribute the Work under its terms, with knowledge of his or her Copyright and Related Rights in the Work and the meaning and intended legal effect of CC0 on those rights. 1. Copyright and Related Rights. A Work made available under CC0 may be protected by copyright and related or neighboring rights ("Copyright and Related Rights"). Copyright and Related Rights include, but are not limited to, the following: i. the right to reproduce, adapt, distribute, perform, display, communicate, and translate a Work; ii. moral rights retained by the original author(s) and/or performer(s); iii. publicity and privacy rights pertaining to a person's image or likeness depicted in a Work; iv. rights protecting against unfair competition in regards to a Work, subject to the limitations in paragraph 4(a), below; v. rights protecting the extraction, dissemination, use and reuse of data in a Work; vi. database rights (such as those arising under Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, and under any national implementation thereof, including any amended or successor version of such directive); and vii. other similar, equivalent or corresponding rights throughout the world based on applicable law or treaty, and any national implementations thereof. 2. Waiver. To the greatest extent permitted by, but not in contravention of, applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and unconditionally waives, abandons, and surrenders all of Affirmer's Copyright and Related Rights and associated claims and causes of action, whether now known or unknown (including existing as well as future claims and causes of action), in the Work (i) in all territories worldwide, (ii) for the maximum duration provided by applicable law or treaty (including future time extensions), (iii) in any current or future medium and for any number of copies, and (iv) for any purpose whatsoever, including without limitation commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each member of the public at large and to the detriment of Affirmer's heirs and successors, fully intending that such Waiver shall not be subject to revocation, rescission, cancellation, termination, or any other legal or equitable action to disrupt the quiet enjoyment of the Work by the public as contemplated by Affirmer's express Statement of Purpose. 3. Public License Fallback. Should any part of the Waiver for any reason be judged legally invalid or ineffective under applicable law, then the Waiver shall be preserved to the maximum extent permitted taking into account Affirmer's express Statement of Purpose. In addition, to the extent the Waiver is so judged Affirmer hereby grants to each affected person a royalty-free, non transferable, non sublicensable, non exclusive, irrevocable and unconditional license to exercise Affirmer's Copyright and Related Rights in the Work (i) in all territories worldwide, (ii) for the maximum duration provided by applicable law or treaty (including future time extensions), (iii) in any current or future medium and for any number of copies, and (iv) for any purpose whatsoever, including without limitation commercial, advertising or promotional purposes (the "License"). The License shall be deemed effective as of the date CC0 was applied by Affirmer to the Work. Should any part of the License for any reason be judged legally invalid or ineffective under applicable law, such partial invalidity or ineffectiveness shall not invalidate the remainder of the License, and in such case Affirmer hereby affirms that he or she will not (i) exercise any of his or her remaining Copyright and Related Rights in the Work or (ii) assert any associated claims and causes of action with respect to the Work, in either case contrary to Affirmer's express Statement of Purpose. 4. Limitations and Disclaimers. a. No trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document. b. Affirmer offers the Work as-is and makes no representations or warranties of any kind concerning the Work, express, implied, statutory or otherwise, including without limitation warranties of title, merchantability, fitness for a particular purpose, non infringement, or the absence of latent or other defects, accuracy, or the present or absence of errors, whether or not discoverable, all to the greatest extent permissible under applicable law. c. Affirmer disclaims responsibility for clearing rights of other persons that may apply to the Work or any use thereof, including without limitation any person's Copyright and Related Rights in the Work. Further, Affirmer disclaims responsibility for obtaining any necessary consents, permissions or other rights required for any use of the Work. d. Affirmer understands and acknowledges that Creative Commons is not a party to this document and has no duty or obligation with respect to this CC0 or use of the Work. For more information, please see ================================================ FILE: README.md ================================================ # Awesome Guidelines [![Awesome](https://awesome.re/badge-flat2.svg)](https://awesome.re)

Awesome Guidelines

A set of guidelines for a specific programming language that provides recommendations on programming style, best practices, and methods for various aspects of writing programs in that language. ## Contents - [Programming Languages](#programming-languages) - [Development Environment](#development-environment) - [Platforms](#platforms) - [Frameworks](#frameworks) - [Content Management System](#content-management-system) - [Tools](#tools) ## Programming Languages ### Brainfuck - [BF Style Guide](https://codepen.io/renmans/full/JjdJPpW) - Guidelines for writing and formatting Brainfuck code. ### C - [C Coding Standard](https://users.ece.cmu.edu/~eno/coding/CCodingStandard.html) - Conventions and best practices for C code. - [C Programming/Structure and style](https://en.wikibooks.org/wiki/C_Programming/Structure_and_style) - Structural and style recommendations for C programs. - [Making The Best Use of C](https://www.gnu.org/prep/standards/html_node/Writing-C.html) - This chapter provides advice on how best to use the C language when writing GNU software. ### C# - [C# Coding Conventions](https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions) - Official C# coding style conventions. - [C# Style Guide](https://github.com/kodecocodes/c-sharp-style-guide) - Community C# style guide. - [C# Coding Standards and Naming Conventions](http://www.dofactory.com/reference/csharp-coding-standards) - Standards and naming conventions for C# code. ### C++ - [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html) - C++ coding standards and best practices. - [C++ Core Guidelines](http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines) - A set of tried-and-true guidelines, rules, and best practices about coding in C++. - [LLVM C++ Coding Standards](https://llvm.org/docs/CodingStandards.html) - Coding standards for the LLVM project. - [Mozilla C++ Coding style](https://firefox-source-docs.mozilla.org/code-quality/coding-style/coding_style_cpp.html) - C++ coding style guidelines for Mozilla codebases. - [Chromium C++ style guide](https://chromium.googlesource.com/chromium/src/+/HEAD/styleguide/c++/c++.md) - C++ style guide for the Chromium project. - [Webkit C++ Code Style Guidelines](https://webkit.org/code-style-guidelines/) - C++ code style guidelines for WebKit. - [NASA C++ Coding Standards and Style Guide](https://ntrs.nasa.gov/api/citations/20080039927/downloads/20080039927.pdf) - C++ coding standards for safety-critical systems. - [OceanBase C++ Coding Standards](https://oceanbase.github.io/oceanbase/coding_standard.html) - C++ coding standards for OceanBase. ### Clojure - [The Clojure Style Guide](https://github.com/bbatsov/clojure-style-guide) - A community coding style guide for the Clojure programming language. ### Common Lisp - [Style Guide](http://lisp-lang.org/style-guide/) - Style guidance for Common Lisp code. - [Google Common Lisp Style Guide](https://google.github.io/styleguide/lispguide.xml) - Style guide for writing Common Lisp programs. - [Common Lisp Style Guide](http://labs.ariel-networks.com/cl-style-guide.html) - Community recommendations for Common Lisp style. ### D - [The D Style](https://dlang.org/dstyle.html) - A set of style conventions for writing D programs. ### Dart - [Effective Dart](https://dart.dev/effective-dart) - Recommendations for consistent, idiomatic Dart code. ### Delphi - [Delphi's Object Pascal Style Guide](https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Delphi%E2%80%99s_Object_Pascal_Style_Guide) - Object Pascal coding style guidelines. ### Elixir - [Elixir Styleguide](https://github.com/christopheradams/elixir_style_guide) - Community Elixir coding style guide. ### Elm - [Elm style guide](http://elm-lang.org/docs/style-guide) - Style suggestions and conventions for Elm. ### Emacs Lisp - [Elisp Guide](https://github.com/chrisdone/elisp-guide) - Guide to writing Emacs Lisp. - [Emacs Lisp Style Guide](https://github.com/bbatsov/emacs-lisp-style-guide) - Community style guide for Emacs Lisp. ### Erlang - [Programming Rules and Conventions](http://www.erlang.se/doc/programming_rules.shtml) - Guidelines and conventions for Erlang programming. - [Erlang Coding Guidelines](https://github.com/inaka/erlang_guidelines) - Community Erlang coding guidelines. ### F# - [The F# Component Design Guidelines](https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/component-design-guidelines) - Official design and style guidelines for F#. ### Fortran - [Fortran 90 Standards](http://research.metoffice.gov.uk/research/nwp/numerical/fortran90/f90_standards.html) - European Standards For Writing and Documenting Exchangeable Fortran 90 Code. - [Fortran Best Practices](https://fortran-lang.org/en/learn/best_practices/) - Style guide and best practices for modern Fortran programs. ### Go - [Effective Go](https://go.dev/doc/effective_go) - Idioms and best practices for Go. - [Go Standard Project Layout](https://github.com/golang-standards/project-layout) - Basic layout for Go applications. - [Google Go Style Guide](https://google.github.io/styleguide/go) - Google's coding standards for source code in Go. - [Uber Go Style Guide](https://github.com/uber-go/guide/blob/master/style.md) - Patterns and conventions used in Go code at Uber. ### Groovy - [Apache Groovy style guide](http://groovy-lang.org/style-guide.html) - Style guide for writing idiomatic Groovy code. ### Haskell - [Haskell Programming guidelines](https://wiki.haskell.org/Programming_guidelines) - Best practices for Haskell programming. ### Java - [Code Conventions for the Java™ Programming Language](http://www.oracle.com/technetwork/java/codeconvtoc-136057.html) - Historical Java coding conventions. - [Google Java Style Guide](https://google.github.io/styleguide/javaguide.html) - Google's coding standards for source code in the Java™ Programming Language. - [Java Programming Style Guide](http://javaranch.com/style.jsp) - Style recommendations for Java programming. - [Alibaba-Java-Coding-Guidelines](https://alibaba.github.io/Alibaba-Java-Coding-Guidelines/) - A guide for Java developers. ### JavaScript - [AngularJS Style Guide](https://github.com/mgechev/angularjs-style-guide) - Community-driven set of best practices for AngularJS application development. - [JavaScript The Right Way](http://jstherightway.org) - An easy-to-read, quick reference for JS best practices, accepted coding standards, and links around the Web. - [Google JavaScript Style Guide](https://google.github.io/styleguide/jsguide.html) - This document serves as the complete definition of Google's coding standards for source code in the JavaScript programming language. - [Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript) - A mostly reasonable approach to JavaScript. - [jQuery Core Style Guide](http://contribute.jquery.org/style-guide/js/) - [JavaScript Style Guides And Beautifiers](https://addyosmani.com/blog/javascript-style-guides-and-beautifiers/) - [JavaScript Style Guide and Coding Conventions](https://www.w3schools.com/js/js_conventions.asp) - [Code Conventions for the JavaScript](http://crockford.com/javascript/code.html) - [JavaScript Clean Code](https://github.com/ryanmcdermott/clean-code-javascript) - Software engineering principles, from Robert C. Martin's book [Clean Code](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882), adapted for JavaScript. - [Mozilla Coding Style Guide for JavaScript](https://developer.mozilla.org/en-US/docs/MDN/Writing_guidelines/Writing_style_guide/Code_style_guide/JavaScript) ### JSON - [Google JSON Style Guide](https://google.github.io/styleguide/jsoncstyleguide.xml) - Recommendations for JSON formatting and usage. ### Julia - [Blue Style](https://github.com/JuliaDiff/BlueStyle) - Community style guide for Julia packages. ### Kotlin - [Coding Conventions](https://kotlinlang.org/docs/coding-conventions.html) - Official Kotlin coding conventions. ### Lua - [Lua Style Guide](http://lua-users.org/wiki/LuaStyleGuide) - Community Lua coding style guide. ### Markdown - [Google Markdown Style Guide](https://github.com/google/styleguide/blob/gh-pages/docguide/style.md) - Style guide for Google-originated projects using Markdown. - [Markdown Style Guide](http://www.cirosantilli.com/markdown-style-guide/) - Practical guidelines for writing readable Markdown. - [GitLab Markdown Style Guide](https://about.gitlab.com/handbook/markdown-guide/) - Markdown Style Guide for about.GitLab.com. ### .NET - [.NET Standard](https://github.com/dotnet/standard) - Formal specification of .NET APIs that are available across .NET implementations. - [.NET Secure Coding Guidelines](https://learn.microsoft.com/en-us/dotnet/standard/security/secure-coding-guidelines) - Guidance for writing secure .NET code. - [.NET Naming Guidelines](https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/naming-guidelines) - Naming conventions for .NET libraries. ### Nim - [Nim Style Guide](https://nim-lang.org/docs/nep1.html) - Style conventions and RFC for Nim code. ### Objective-C - [Objective-C Style guide](https://github.com/github/objective-c-style-guide) - Style guide & coding conventions for Objective-C projects. - [Google Objective-C Style Guide](https://github.com/google/styleguide/blob/gh-pages/objcguide.md) - Objective-C coding standards and conventions. - [NYTimes Objective-C Style Guide](https://github.com/NYTimes/objective-c-style-guide) - The Objective-C Style Guide used by The New York Times. ### Pascal - [Coding style](http://wiki.freepascal.org/Coding_style) - Style recommendations for Free Pascal. - [GNU Pascal Coding Standards](https://edoras.sdsu.edu/doc/gpcs-en.html) - GNU Pascal standards used by GNU Pascal project. ### Perl - [Perl best practices v4](https://www.slideshare.net/RandalSchwartz/perl-best-practices-v4) - Slides by Randal Schwartz, based on the book by Damian Conway. - [Perl Elements to Avoid](http://perl-begin.org/tutorials/bad-elements/) - A list of unrecommended practices, and what to do instead. - [perlstyle](https://perldoc.perl.org/perlstyle) - Perl style guidelines. ### PHP - [PHP FIG](http://www.php-fig.org/psr/) - PHP Standards Recommendations. - [PHP The Right Way](http://www.phptherightway.com) - An easy-to-read, quick reference for PHP best practices, accepted coding standards, and links to authoritative tutorials around the Web. - [Clean Code PHP](https://github.com/piotrplenik/clean-code-php) - Clean Code concepts adapted for PHP. ### Python - [Style Guide for Python Code](https://peps.python.org/pep-0008/) - Official Python style guide (PEP 8). - [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html) - Python coding standards. - [The Hitchhiker's Guide to Python](https://docs.python-guide.org/) - Highly regarded Python best practices guide. ### R - [Google's R Style Guide](https://google.github.io/styleguide/Rguide.html) - R style conventions. - [The tidyverse style guide](http://style.tidyverse.org) - Style guide for R code in the tidyverse. ### Racket - [How to Program Racket: a Style Guide](http://docs.racket-lang.org/style/index.html) - Style guidance for Racket programs. ### Ruby - [The Ruby Style Guide](https://rubystyle.guide) - A community-driven Ruby coding style guide. - [Ruby Style Guide](https://github.com/airbnb/ruby) - Airbnb's Ruby Style Guide. - [Ruby Style Guide](https://github.com/rubocop/ruby-style-guide) - A community-driven Ruby coding style guide. ### Rust - [Rust Style Guide](https://github.com/rust-lang/rust/tree/HEAD/src/doc/style-guide/src) - Style guidelines for the Rust language. - [Rust Guidelines](http://aturon.github.io) - Practices and guidance for writing Rust code. - [Rust API Guidelines](https://rust-lang.github.io/api-guidelines/) ### Scala - [Effective Scala](https://twitter.github.io/effectivescala/) - Best practices and patterns for Scala. - [Scala Style Guide](http://docs.scala-lang.org/style/) - Official style guide for Scala code. - [Databricks Scala Guide](https://github.com/databricks/scala-style-guide) - Databricks Scala Coding Style Guide. - [Scala Best Practices](https://github.com/alexandru/scala-best-practices) - Recommendations and patterns for Scala development. ### Solidity - [Solidity Style Guide](https://docs.soliditylang.org/en/latest/style-guide.html) - Style guidelines for Solidity smart contracts. - [Solcurity Standard](https://github.com/transmissions11/solcurity) - Security checklist and guidelines for Solidity smart contracts. ### Swift - [API Design Guidelines](https://www.swift.org/documentation/api-design-guidelines/) - API design principles for Swift. - [Swift](https://github.com/github/swift-style-guide) - GitHub Official Swift style and conventions. - [Swift style guide](https://github.com/kodecocodes/swift-style-guide) - Community Swift style guide. - [Swift Style Guide](https://github.com/linkedin/swift-style-guide) - LinkedIn Official Swift Style Guide. - [Metova's Swift style guide](https://github.com/metova/swift-style-guide) - [Xmartlabs Swift Style Guide](https://github.com/xmartlabs/Swift-Style-Guide) - Swift language style guide & coding conventions followed by Xmartlabs. ### TypeScript - [Google TypeScript Style Guide](https://google.github.io/styleguide/tsguide.html) - TypeScript Style Guide used at Google's. - [TypeScript deep dive - Style Guide](https://basarat.gitbook.io/typescript/styleguide) - An unofficial TypeScript Style Guide. - [TypeScript Lang - Do's and Don'ts](https://www.typescriptlang.org/docs/handbook/declaration-files/do-s-and-don-ts.html) - Suggestions from TypeScript Lang organization. ### Visual Basic - [Visual Basic Concepts]() - Concepts and coding practices for classic Visual Basic. - [Visual Basic/Coding Standards](https://en.wikibooks.org/wiki/Visual_Basic/Coding_Standards) - Coding standards for Visual Basic projects. ### XML - [Google XML Document Format Style Guide](https://google.github.io/styleguide/xmlstyle.html) - XML formatting and style guidance. ## Development Environment ### Shell - [Shell Style Guide](https://google.github.io/styleguide/shellguide.html) - Shell script style guide. ### Git - [Git Style Guide](https://github.com/agis/git-style-guide) - Git usage and style recommendations. - [Few Rules from Git Documentation](https://github.com/git/git/blob/master/Documentation/CodingGuidelines) - Coding guidelines used in the Git project. ### PowerShell - [The PowerShell Best Practices and Style Guide](https://github.com/PoshCode/PowerShellPracticeAndStyle) - The Unofficial PowerShell Best Practices and Style Guide. ## Platforms ### Android - [Android Guidelines](https://github.com/ribot/android-guidelines) - Architecture and code guidelines we use at ribot when developing for Android. - [Xmartlabs Android Style Guide](https://github.com/xmartlabs/Android-Style-Guide) - Style guide for Android by Xmartlabs. ### Apache - [Apache Developers' C Language Style Guide](http://httpd.apache.org/dev/styleguide.html) - C language style guidelines for the Apache HTTP Server project. ### API - [HAL](http://stateless.co/hal_specification.html) - A simple format that gives a consistent and easy way to hyperlink between resources in your API. - [Microsoft REST API Guidelines](https://github.com/Microsoft/api-guidelines) - The Microsoft REST API Guidelines. - [JSON API - Recommendations](http://jsonapi.org/recommendations) - This section contains recommendations for JSON API implementations. - [API Security Checklist](https://github.com/shieldfy/API-Security-Checklist) - Checklist of the most important security countermeasures when designing, testing, and releasing your API. - [Google Cloud API Design Guide](https://cloud.google.com/apis/design) - A general design guide for networked APIs provided by Google. ### Arduino - [Arduino style guide](https://www.arduino.cc/) - General coding style guidance for Arduino. - [API Style Guide for Arduino](https://docs.arduino.cc/learn/contributions/arduino-library-style-guide/) ### Frontend Development - [CSS Guidelines](https://cssguidelin.es) - High-level advice and guidelines for writing sane, manageable, scalable CSS. - [Frontend Guidelines](https://github.com/bendc/frontend-guidelines) - Some HTML, CSS and JS best practices. - [Sass Guidelines](https://sass-guidelin.es) - An opinionated styleguide for writing sane, maintainable and scalable Sass. - [Airbnb CSS / Sass Styleguide](https://github.com/airbnb/css) - A mostly reasonable approach to CSS and Sass. - [HTML Style Guide](https://github.com/marcobiedermann/html-style-guide) - A style guide which helps you write better, performant, structured, scalable and maintainable HTML. - [HTML + CSS Code Guide](http://codeguide.co) - Standards for flexible, durable, and sustainable HTML and CSS. - [U.S. Web Design Standards](https://designsystem.digital.gov/) - Open source UI components and visual style guide for U.S. government websites. - [CoffeeScript Style Guide](https://github.com/polarmobile/coffeescript-style-guide) - A collection of best-practices and coding conventions for the CoffeeScript programming language. - [LESS Coding Guidelines](https://gist.github.com/fat/a47b882eb5f84293c4ed) - Style guidelines for writing LESS. - [Google HTML/CSS Style Guide](https://google.github.io/styleguide/htmlcssguide.html) - HTML and CSS conventions and best practices. - [Guidelines for Responsive Web Design](https://www.smashingmagazine.com/2011/01/guidelines-for-responsive-web-design/) - [Yelp Styleguide](https://www.yelp.com/styleguide) - [Front-End Checklist](https://github.com/thedaviddias/Front-End-Checklist) - [BEM - Block Element Modifier](https://getbem.com/) - A methodology that helps you to create reusable components and code sharing in front‑end development. - [Web Content Accessibility Guidelines (WCAG) 2.1](https://www.w3.org/TR/WCAG21/) - Recommendations for making web content more accessible. ### GNU - [GNU coding standards](https://www.gnu.org/prep/standards/) - Coding and documentation standards for GNU software. ### Java - [JavaEE Specification](https://github.com/javaee/javaee-spec) - Official specification for Java EE. ### Linux - [Linux kernel coding style](https://www.kernel.org/doc/html/latest/process/coding-style.html) - Coding style for the Linux kernel. ### Mailchimp - [Mailchimp Content Style Guide](https://styleguide.mailchimp.com) - Content style guidelines for Mailchimp. ### Mozilla - [Mozilla Coding Style Guide](https://developer.mozilla.org/en-US/docs/MDN/Writing_guidelines/Writing_style_guide/Code_style_guide) - Coding style guidance for Mozilla projects. ### Google - [Google-related developer documentation](https://developers.google.com/style) - This style guide provides editorial guidelines for writing clear and consistent Google-related developer documentation. ### Node.js - [Microsoft + Node.js Guidelines](https://github.com/Microsoft/nodejs-guidelines) - Engineering guidelines for building Node.js apps. - [Node.js Style Guide](https://github.com/felixge/node-style-guide) - A guide for styling your Node.js / JavaScript code. ### MongoDB - [Mongo Style Guide](https://github.com/jsoendermann/MongoStyleGuide) - Style guidelines for MongoDB usage. ### SQL - [SQL Style Guide](https://www.sqlstyle.guide) - SQL style and formatting guidelines. ### Other - [Keep a CHANGELOG](http://keepachangelog.com/en/0.3.0/) - Don't let your friends dump Git logs into CHANGELOGs™. - [Project Guidelines](https://github.com/elsewhencode/project-guidelines) - A set of best practices for JavaScript projects. - [Semantic Versioning](http://semver.org) - Versioning scheme for managing releases. - [Indent style](https://en.wikipedia.org/wiki/Indentation_style) - Overview of indentation styles in programming. - [WebAppSec/Secure Coding Guidelines](https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines) - [Robot Framework User Guide](https://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html) - [CodeQL Coding Standards](https://github.com/github/codeql-coding-standards) ## Frameworks - [Symfony Coding Standards](https://symfony.com/doc/current/contributing/code/standards.html) - [Django Coding Style](https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style) - [Vue Style Guide](https://vuejs.org/style-guide) - [Angular Style Guide](https://angular.dev/style-guide) ## Content Management System - [WordPress Coding Standards](https://developer.wordpress.org/coding-standards/wordpress-coding-standards/) - [Drupal Coding Standards](https://www.drupal.org/docs/develop/standards) - [Magento Coding Standards](https://developer.adobe.com/commerce/php/coding-standards/) - [Octobercms Developer Guide](https://octobercms.com/help/guidelines/developer) ## Tools - [Checkstyle](https://github.com/checkstyle/checkstyle) - Tool for checking Java source code for adherence to a Code Standard or set of validation rules. - [Conventional Changelog](https://github.com/conventional-changelog/conventional-changelog) - [EasyCodingStandard](https://github.com/easy-coding-standard/easy-coding-standard) - The Easiest Way to Use Any Coding Standard. - [ESLint](https://eslint.org/) - The pluggable linting utility for JavaScript and JSX. - [JavaScript Standard Style](https://standardjs.com) - One JavaScript Style to Rule Them All. - [Laravel Pint](https://laravel.com/docs/11.x/pint) - An opinionated PHP code style fixer for minimalists. - [North](http://pointnorth.io) - Design and development standards to align and guide your project. - [PHP_CodeSniffer](https://github.com/squizlabs/PHP_CodeSniffer) - The tool for detecting and fixing the violations of the specified standards in PHP code. - [PHP Coding Standards Fixer](https://cs.symfony.com) - The PHP Coding Standards Fixer (PHP CS Fixer) tool fixes your code to follow standards. - [RuboCop](https://rubocop.org) - A Ruby static code analyzer and formatter, based on the community Ruby style guide. - [semantic-release](https://github.com/semantic-release/semantic-release) - [ShellCheck](https://github.com/koalaman/shellcheck) - A shell script static analysis tool. - [Agents.md](https://agents.md) - A simple, open format for guiding coding agents ================================================ FILE: code-of-conduct.md ================================================ # Contributor Covenant Code of Conduct ## Our Pledge In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. ## Our Standards Examples of behavior that contributes to creating a positive environment include: * Using welcoming and inclusive language * Being respectful of differing viewpoints and experiences * Gracefully accepting constructive criticism * Focusing on what is best for the community * Showing empathy towards other community members Examples of unacceptable behavior by participants include: * The use of sexualized language or imagery and unwelcome sexual attention or advances * Trolling, insulting/derogatory comments, and personal or political attacks * Public or private harassment * Publishing others' private information, such as a physical or electronic address, without explicit permission * Other conduct which could reasonably be considered inappropriate in a professional setting ## Our Responsibilities Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. ## Scope This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. ## Enforcement Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at w.kristories@gmail.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. ## Attribution This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version] [homepage]: http://contributor-covenant.org [version]: http://contributor-covenant.org/version/1/4/ ================================================ FILE: contributing.md ================================================ # Contributing to Awesome Guidelines Thank you for taking the time to contribute! :+1: ## How Can I Contribute? ### Creating Issues Know of an awesome guideline that’s missing from the list? If it’s not already mentioned in the [open issues](https://github.com/Kristories/awesome-guidelines/issues) or [pull requests](https://github.com/Kristories/awesome-guidelines/pulls), please feel free to create a new issue or submit a pull request. We’d love to hear from you! ### Submitting Pull Requests You’re welcome to work on any open issue. Just ensure you follow the contribution guidelines while submitting your PR. ### Voting and Commenting Join the conversation on GitHub Discussions ([Resource suggestions](https://github.com/Kristories/awesome-guidelines/discussions/categories/resource-suggestions)) to vote and provide feedback. ## Contribution Guidelines * Please search previous suggestions before making a new one, as yours may be a duplicate. * Use the following format: `[Title](url) - Description.` * Include a short description for each entry unless the title is already sufficiently descriptive (this is rare). * Write descriptions in sentence case (not Title Case). * The link should be the name of the package or project. * Links and categories should be sorted alphabetically. * Add one link per pull-request. * Keep descriptions concise, clear and simple, and end them with a period/stop. * Check your spelling and grammar. * New categories, or improvements to the existing ones are also welcome. * Make sure your text editor is set to remove trailing whitespace. ## Quality Standards Projects listed should meet these criteria to maintain quality: * Widely used and beneficial to the community. Thank you to all our [contributors](https://github.com/Kristories/awesome-guidelines/graphs/contributors)! This project wouldn’t be possible without your support. ================================================ FILE: package.json ================================================ { "scripts": { "test": "awesome-lint" }, "devDependencies": { "awesome-lint": "v2.2.3" } } ================================================ FILE: test.js ================================================ const awesomeLint = require('awesome-lint'); awesomeLint.report(); ================================================ FILE: travis.yml ================================================ language: node_js node_js: - 'node' # git: # depth: false