コード共有のベスト/悪い習慣は？[閉まっている]

Githubを探索すればするほど、好きになります。コーディングがより社会的になっているのを本当に楽しんでいます。

プログラマ同士がコードを共有する際に避けなければならない悪い習慣があるかどうか知りたいです。そして、悪い習慣に名前を付ける際に、コード共有のベストプラクティスは何ですか？

例えば：

単一のリポジトリが「MiscProjects」という名前の複数のスクリプト/プロジェクトを持つことは悪い習慣ですか？このレポは、名前が示すように、さまざまな小さなスクリプトとプロジェクトのコレクションです。これは、プログラマーが自分のローカルストレージでプロジェクトを編成する方法に似ている可能性がありますが、コード共有に最適ではない可能性がありますか？

たぶん、良いREADME /ドキュメントができれば、それはより良いでしょうか？または、それが十分に文書化されている限り、何が起こりますか？

他のバージョン管理システムと同様に、「悪意のある慣習」はありませんが、慣例があります。

Gitリポジトリはできるだけ小さくする必要があります。CVS / SVNモジュールを使用している場合は、構造化された単一のリポジトリを使用するのが一般的でした。このリポジトリは、複数のプロジェクトの複数のリポジトリで構成できます。Gitの方法は、これらのアップを分割し、各プロジェクトのための別々のGitのリポジトリを持つことです。理由は次のとおりです。

• 小さなリポジトリの場合、Gitの方が高速です。
• その設計により、各操作はリポジトリ全体に影響します。必要なプロジェクトの1つだけで作業している場合、必要なプロジェクトに対してGit操作を実行することは非効率的です。

いつものように、ドキュメントは必須です。人々はコードを読むことに長けていますが、必要以上にコードを解釈したくはありません。トップレベルのREADMEを使用してプロジェクトとGitリポジトリの構造を説明することは、プロジェクトに関与している（または関与しようとしている）人々にとって常に良いことです。

GitHub上のプロジェクトの大部分は、規約に準拠しています。これらを、将来のプロジェクトを構成する方法の例として使用してください。