Add Guidelines

[Kristories]

[Insert URL to the list here]
https://github.com/Kristories/awesome-guidelines

[Explain what this list is about and why it should be included here]
A curated list of programming guidelines to enhance code quality and promote best practices.

My Reviews of Other PRs

• Add ATProto #3323 (review)
• Add AI in Cybersecurity #3129 (review)
• Add WebGPU #3210 (review)
• Add "FOSS Alternatives" #3256 (review)
• Add Cursor Rules #4168 (comment)
• Add ai-skill to CLI AI tools #4115 (comment)

By submitting this pull request I confirm I've read and complied with the below requirements 🖖

Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.

Requirements for your pull request

• Don't open a Draft / WIP pull request while you work on the guidelines. A pull request should be 100% ready and should adhere to all the guidelines when you open it. Instead use #2242 for incubation visibility.
• Don't waste my time. Do a good job, adhere to all the guidelines, and be responsive.
• You have to review at least 2 other open pull requests.
  Try to prioritize unreviewed PRs, but you can also add more comments to reviewed PRs. Go through the below list when reviewing. This requirement is meant to help make the Awesome project self-sustaining. Comment here which PRs you reviewed. You're expected to put a good effort into this and to be thorough. Look at previous PR reviews for inspiration. Just commenting “looks good” or simply marking the pull request as approved does not count! You have to actually point out mistakes or improvement suggestions. Comments pointing out lint violation are allowed, but does not count as a review.
• You have read and understood the instructions for creating a list.
• This pull request has a title in the format Add Name of List. It should not contain the word Awesome.
  • ✅ Add Swift
  • ✅ Add Software Architecture
  • ❌ Update readme.md
  • ❌ Add Awesome Swift
  • ❌ Add swift
  • ❌ add Swift
  • ❌ Adding Swift
  • ❌ Added Swift
• Your entry here should include a short description of the project/theme of the list. It should not describe the list itself. The first character should be uppercase and the description should end in a dot. It should be an objective description and not a tagline or marketing blurb. It should not contain the name of the list.
  • ✅ - [iOS](…) - Mobile operating system for Apple phones and tablets.
  • ✅ - [Framer](…) - Prototyping interactive UI designs.
  • ❌ - [iOS](…) - Resources and tools for iOS development.
  • ❌ - [Framer](…)
  • ❌ - [Framer](…) - prototyping interactive UI designs
• Your entry should be added at the bottom of the appropriate category.
• The title of your entry should be title-cased and the URL to your list should end in #readme.
  • Example: - [Software Architecture](https://github.com/simskij/awesome-software-architecture#readme) - The discipline of designing and building software.
• No blockchain-related lists.
• The suggested Awesome list complies with the below requirements.

Requirements for your Awesome list

• Has been around for at least 30 days.
  That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.
• Run awesome-lint on your list and fix the reported issues. If there are false-positives or things that cannot/shouldn't be fixed, please report it.
• The default branch should be named main, not master.
• Includes a succinct description of the project/theme at the top of the readme. (Example)
  • ✅ Mobile operating system for Apple phones and tablets.
  • ✅ Prototyping interactive UI designs.
  • ❌ Resources and tools for iOS development.
  • ❌ Awesome Framer packages and tools.
• It's the result of hard work and the best I could possibly produce.
  If you have not put in considerable effort into your list, your pull request will be immediately closed.
• The repo name of your list should be in lowercase slug format: awesome-name-of-list.
  • ✅ awesome-swift
  • ✅ awesome-web-typography
  • ❌ awesome-Swift
  • ❌ AwesomeWebTypography
• The heading title of your list should be in title case format: # Awesome Name of List.
  • ✅ # Awesome Swift
  • ✅ # Awesome Web Typography
  • ❌ # awesome-swift
  • ❌ # AwesomeSwift
• Non-generated Markdown file in a GitHub repo.
• The repo should have awesome-list & awesome as GitHub topics. I encourage you to add more relevant topics.
• Not a duplicate. Please search for existing submissions.
• Only has awesome items. Awesome lists are curations of the best, not everything.
• Does not contain items that are unmaintained, has archived repo, deprecated, or missing docs. If you really need to include such items, they should be in a separate Markdown file.
• Includes a project logo/illustration whenever possible.
  • Either centered, fullwidth, or placed at the top-right of the readme. (Example)
  • The image should link to the project website or any relevant website.
  • The image should be high-DPI. Set it to a maximum of half the width of the original image.
  • Don't include both a title saying Awesome X and a logo with Awesome X. You can put the header image in a # (Markdown header) or <h1>.
• Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
• Includes the Awesome badge.
  • Should be placed on the right side of the readme heading.
    • Can be placed centered if the list has a centered graphics header.
  • Should link back to this list.
• Has a Table of Contents section.
  • Should be named Contents, not Table of Contents.
  • Should be the first section in the list.
  • Should only have one level of nested lists, preferably none.
  • Must not feature Contributing or Footnotes sections.
• Has an appropriate license.
  • We strongly recommend the CC0 license, but any Creative Commons license will work.
    • Tip: You can quickly add it to your repo by going to this URL: https://github.com/<user>/<repo>/community/license/new?branch=main&template=cc0-1.0 (replace <user> and <repo> accordingly).
  • A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. Neither are WTFPL and Unlicense.
  • Place a file named license or LICENSE in the repo root with the license text.
  • Do not add the license name, text, or a Licence section to the readme. GitHub already shows the license name and link to the full text at the top of the repo.
  • To verify that you've read all the guidelines, please comment on your pull request with just the word unicorn.
• Has contribution guidelines.
  • The file should be named contributing.md. The casing is up to you.
  • It can optionally be linked from the readme in a dedicated section titled Contributing, positioned at the top or bottom of the main content.
  • The section should not appear in the Table of Contents.
• All non-important but necessary content (like extra copyright notices, hyperlinks to sources, pointers to expansive content, etc) should be grouped in a Footnotes section at the bottom of the readme. The section should not be present in the Table of Contents.
• Has consistent formatting and proper spelling/grammar.
  • The link and description are separated by a dash.
    Example: - [AVA](…) - JavaScript test runner.
  • The description starts with an uppercase character and ends with a period.
  • Consistent and correct naming. For example, Node.js, not NodeJS or node.js.
• Does not use hard-wrapping.
• Does not include a CI (e.g. GitHub Actions) badge.
  You can still use a CI for linting, but the badge has no value in the readme.
• Does not include an Inspired by awesome-foo or Inspired by the Awesome project kinda link at the top of the readme. The Awesome badge is enough.

Go to the top and read it again.

[yijun-lee]

That’s a great list! I starred it immediately! 😊

From a content perspective, it’s already excellent, but I noticed a couple of things regarding the format:

1. Must not feature Contributing or Footnotes sections. I thought this part might pose a formatting issue.
2. I recommend re-reading the guidelines! Once you do, you’ll understand why I suggested it.

[darccio]

@Kristories Nice list! Some things:

• The Contributors sections seems out of place. Consider removing it.
• nitpick as Go developer: Go Standard Project Layout is a bit controversial due to their naming. More than a standard is a compilation of usages.
• I wonder if the name could be more specific, like Awesome Programming Guidelines. Feel free to ignore this, it's not even a nitpick 😸

[sindresorhus]

Thanks for making an Awesome list! 🙌

It looks like you didn't read the guidelines closely enough. I noticed multiple things that are not followed. Try going through the list point for point to ensure you follow it. I spent a lot of time creating the guidelines so I wouldn't have to comment on common mistakes, and rather spend my time improving Awesome.

[Kristories]

unicorn

[Kristories]

It looks like you didn't read the guidelines closely enough. I noticed multiple things that are not followed. Try going through the list point for point to ensure you follow it. I spent a lot of time creating the guidelines so I wouldn't have to comment on common mistakes, and rather spend my time improving Awesome.

@sindresorhus I’ve gone through the guidelines carefully and have revised my submission accordingly. Please let me know if there’s anything else that needs adjustment. I appreciate the time and effort you put into creating the guidelines and maintaining Awesome!

[UsNow-maker]

This is what I need to learn...I only recently have had the time...

[ludovicobesana]

Great list! One suggestions:

• The description in the header describes the list, not the topic. Consider: "Coding standards and best practices for programming languages and platforms."

Everything else looks solid. ✅

[Kristories]

Hi @sindresorhus,

Is there anything specific about the PR that needs attention, or would you like me to make any adjustments to better align with the awesome list standards?

Thanks for your time.

[sindresorhus]

Entries have a description, unless the title is descriptive enough by itself. It rarely is though.

---

Descriptions should not be title-case.

[Kristories]

Entries have a description, unless the title is descriptive enough by itself. It rarely is though.

Descriptions should not be title-case.

Updated the descriptions — no longer in title case.

Thanks for the review! 🦄 @sindresorhus

[sindresorhus]

Descriptions should not be title-case.

Not fixed

[Kristories]

Descriptions should not be title-case.

Not fixed

Done @sindresorhus

[sindresorhus]

Insufficient reviews

The template requires 4 substantive reviews. Of the 4 PRs you listed:

PR	What you did	Counts?
#3323	Pointed out TOC should not include Contributing section	Yes
#3129	Blank-body approval, no comments	No
#3210	Blank-body approval, no comments	No
#3256	Blank-body approval, no comments	No

That's 1 qualifying review out of the 4 required. Blank approvals with no body or comments do not count per the template: "Just commenting 'looks good' or simply marking the pull request as approved does not count!"

You need 3 more substantive reviews where you point out specific guideline violations or improvement suggestions.

Top description describes the list, not the subject

Current:

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.

"A set of guidelines...that provides recommendations" describes what the list is, not what the subject is. This matches the explicitly prohibited pattern ("Resources and tools for X"). Something like "Programming style, best practices, and coding conventions." would work.

Entry not placed at the bottom

The diff inserts the entry between Permacomputing and Standards. The guideline requires it to be "at the bottom of the appropriate category" -- it should go after the last entry (currently Copilot Agents), right before the ## Related section.

---

Linked list issues

Many entries have no description (13 total)

The guideline says "Entries have a description, unless the title is descriptive enough by itself. It rarely is though." These entries have no description at all:

• [jQuery Core Style Guide](...)
• [JavaScript Style Guides And Beautifiers](...)
• [JavaScript Style Guide and Coding Conventions](...)
• [Code Conventions for the JavaScript](...)
• [Rust API Guidelines](...)
• [Metova's Swift style guide](...)
• [Guidelines for Responsive Web Design](...)
• [Yelp Styleguide](...)
• [Front-End Checklist](...)
• [Conventional Changelog](...)
• [semantic-release](...)
• [WebAppSec/Secure Coding Guidelines](...)
• [Robot Framework User Guide](...)

Broken links

These are dead or point to unrelated content:

Entry	Problem
http://www.erlang.se/doc/programming_rules.shtml	Connection refused
http://labs.ariel-networks.com/cl-style-guide.html	TLS certificate error
http://crockford.com/javascript/code.html	Timeout (unreachable)
http://pointnorth.io (North, under Tools)	301 redirects to rophim.is, an unrelated site
http://research.metoffice.gov.uk/.../f90_standards.html	301 redirects to a generic Met Office page; original Fortran 90 content is gone
http://aturon.github.io (Rust Guidelines)	It's a personal tech blog, not "Rust Guidelines" as described

Stale redirect

• http://javaranch.com/style.jsp permanently redirects (301) to https://coderanch.com/wiki/718799/Style. Update the URL.

Description issues

• [Agents.md](...) - A simple, open format for guiding coding agents -- missing trailing period.
• [Keep a CHANGELOG](...) - Don't let your friends dump Git logs into CHANGELOGs™. -- this is the project's tagline/CTA, not an objective description.

Image

The header image (<img ... src="https://repository-images.githubusercontent.com/..."/>) has no width attribute. The guidelines require "Set it to a maximum of half the width of the original image" for high-DPI display. If the image also displays "Awesome Guidelines" text, that conflicts with the # Awesome Guidelines heading ("Don't include both a title saying Awesome X and a logo with Awesome X"). Either remove the text heading and use the image in an <h1>, or use an image without the title text.

[monapdx]

Your awesome list URL should end in #readme

[sn7zvqtvhf-star]

What am i supposed to be doing here

[sn7zvqtvhf-star]

I am the original creator and technical owner of this work, repository, and associated assets. I retain full authorship and ownership rights.

[Kristories]

@sindresorhus updated. Please check

[velo4705]

Heya @Kristories !
I'd say it is a very helpful list, but it has brought me to find out some checks are missing from the guidelines:

1. Some entries in README do not have a description yet ("Entries have a description, unless the title is descriptive enough by itself. It rarely is though."). These are:

• [Style Guide](...)
• [Google Common Lisp Style Guide](...)
• [Erlang Coding Guidelines](...)
• [Java Programming Style Guide](...)
• [Mozilla Coding Style Guide for JavaScript](...)
• [Rust Style Guide](...)
• [API Style Guide for Arduino](...)
• [LESS Coding Guidelines](...)
• [Google HTML/CSS Style Guide](...)
• [Semantic Versioning](...)
• [Indent style](...)
• [CodeQL Coding Standards](...)

This, also including entries inside Frameworks and Content Management System Sections should apply this guideline.

---

2. There is this deprecated entry that is actually an archived repository ("Does not contain items that are unmaintained, has archived repo, deprecated, or missing docs. If you really need to include such items, they should be in a separate Markdown file."). I suggest to remove them from the README or else move them to a separate Markdown file:

• [Metova's Swift style guide](...) - Swift style guide for Xcode (archived, deprecated 2022).

---

After this, recommend rechecking the README again to make sure it follows all the guidelines.
Other than that, the README looks very good. ✨

[velo4705]

So I found some things to correct, kinda taken from my previous comment:

1. Some entries in the list do not have a description yet ("Entries have a description, unless the title is descriptive enough by itself. It rarely is though."). These are:

• [Style Guide](...)
• [Google Common Lisp Style Guide](...)
• [Erlang Coding Guidelines](...)
• [Java Programming Style Guide](...)
• [Mozilla Coding Style Guide for JavaScript](...)
• [Rust Style Guide](...)
• [API Style Guide for Arduino](...)
• [LESS Coding Guidelines](...)
• [Google HTML/CSS Style Guide](...)
• [Semantic Versioning](...)
• [Indent style](...)
• [CodeQL Coding Standards](...)

This, also including entries inside Frameworks and Content Management System Sections should apply this guideline.

---

2. There is this deprecated entry that is actually an archived repository ("Does not contain items that are unmaintained, has archived repo, deprecated, or missing docs. If you really need to include such items, they should be in a separate Markdown file."). I suggest to remove them from the list or else move them to a separate Markdown file:

• [Metova's Swift style guide](...) - Swift style guide for Xcode (archived, deprecated 2022).

---

After this, try rechecking the list again to make sure it follows all the guidelines.
Other than that, the List fits as Awesome. ✨