5.3 KiB
贡献
随时欢迎你提供贡献！以下是一些指南.
合适的候选项
在贡献之前，请确保您要添加的新链接符合合适候选项的标准.
以下是一个非限制性列表, 这些项目是适合纳入awesome列表的.
错误认知类文章
遵循谬误认知定义的文章是该awesome列表的首选候选项。
此类文章以假设开发者对某个领域存在简单而天真的看法为开端，接着列出一系列程序员可能持有的误解性假设。每个假设故意是错误的，并且在最佳情况下配有反例来加以说明。
一份错误认知列表通常是逐步设计的，旨在精炼相关概念。 在阅读了整个谬误列表后，读者应该对某个领域有更好的了解，同时消除其错误认知， 指出常见的陷阱并展示其微妙之处
从某种意义上说，谬误文章是一套冗长的单元测试，涵盖了现实世界使用提供的广泛边缘情况
世界很混乱。发现一个领域比预期复杂得多会导致挫败感。可能会破防,直接掀桌 (╯°□°)╯︵ ┻━┻。这是该名单的优秀候选项的标志！
包含仅适用于一种产品（或一项服务）的项目的文章不能被视为足够通用，应避免使用.
库
如果编程库或模块能够解决或减少上述谬误文章指出的复杂性，那么它们也是不错的选择
这样可以把刚才掀起的桌子放下. ┬─┬ ノ( ゜-゜ノ)
数据结构
本页也欢迎足够通用的数据模型和数据结构来涵盖和解决大多数谎言。
PR和issues
-
在提出新issue/PR之前，请先搜索以前的issue/PR。你在做的可能是重复或者是已经在进行的工作
-
每次提交仅包含一个列表项.
-
每个PR只有一个commit. 应用修改的之后总是会squash commits.
-
检查你的拼写和语法.
-
补充说明为何该链接资源值得推荐。以及它对现有内容的补充或提升
-
保持翻译内容与您的提案同步更新. 将更改传播到所有
readme.*.md文件. 依赖自动翻译工具，之后会由双语贡献者进一步完善结果.
代码规范检查
请确保你的PR通过 官方Awesome List的代码规范检查.
不需要额外的工作，因为它已经通过GitHub actions集成了
在本地执行代码规范检查，执行以下命令:
$ npm i npx
$ npx awesome-lint
格式化
额外规则未被awesome-lint覆盖，以保持内容整洁。
如果这些规则与代码规范检查冲突，代码规范检查的规则应优先。请应用它.
通用内容
-
删除任何尾部空格.
-
使用空格，不要使用制表符进行缩进.
-
使用单个ASCII标记的撇号：
'. -
尝试引用原始内容以总结链接内容的要点.
-
如果直接引用不合适，可以对项目的标题和描述进行改写.请记住，这是一种精选过程：我们通过聚合和分类来提升原始内容的价值，同时进行恰当的编辑优化。只需尊重原始内容的精神即可.
章节
-
各章节按字母顺序排列，因为所有主题都是相互独立的。
-
章节可能包含一段介绍和一张图片（图表、绘图、照片）.
项目标题
-
链接标题需去除 "程序员认为" 部分，以保持简洁
-
如果可以，URL必须用HTTPS协议.
-
不要用弧形引号
“和”. 它们仅保留用于描述中的原始内容引用. -
引用时请使用单引号或双引号：' 和 "，并确保它们成对使用.
项目描述
-
尽量提供可操作的简短总结作为描述，如果原文已足够完整，可直接引用.
-
删除描述中的
TL;DR:前缀. 每个描述都应该是简短的摘要. -
引用内容应使用
“和”弧形引号正确分隔 -
你可以使用括号内的省略号
(…)来缩减原文. -
对于引用内部的引文，使用单引号
'或双引号"，并确保它们成对出现 -
要将列表序列化为描述，请使用以下格式:
描述性文字总结该条目。以下是关于 "一个随机主题：1. xxx；2. xxx？3. xxx。" 的原始内容列表，并在最后添加一些总结文字.
此格式为视觉上提供了锚点，有助于提升可读性和快速内容浏览.
-
您可以跳过原始列表中的某些项目并重新编号.
-
但不应重新排序原始列表的顺序.
-
-
描述中允许附加链接，但应限于少数情况，例如指向更大的概念、首字母缩写的定义或参考资料（如书籍、传记等）.
命令行助手
用于修复一些常见格式错误的单行命令。请谨慎使用，并始终仔细检查和编辑结果.
-
将星号列表项标记替换为短横线:
$ sed -i 's/^* /- /g' ./README.md -
将排版引号替换为 ASCII 引号:
$ sed -i "s/‘/\'/g" ./readme.md $ sed -i "s/’/\'/g" ./readme.md -
强制引号以句点结尾:
$ sed -i 's/`$/`\./g' ./readme.md
其他可用的单行命令 在我的博客上.