你如何讓別人相信你的代碼並使用它？

Question

我不時編寫愛好代碼。事情就是這些工具，類或者小代碼庫最終會成爲一個無望的未來！我很想進一步開發我的項目，並讓其他程序員信任它們。如果您打算使用您在互聯網上找到的東西，那麼您在該編程工具或小型圖書館中尋找的最重要的東西是什麼？例如你會考慮單獨的文件嗎？

---

感謝所有的貢獻者。我會盡我所能來總結所說的話。隨意修改列表。更正和補充更多的歡迎:)

• Start a blog and let others know you are here.

• Choose the most suitable license. Possibly Open Source licenses are the best for hobby projects.

• 把你的計劃，人們可以在 達到它。考慮google-code, github,sourceforge或 其他網站。

• 使用公共版本控制和 的bug跟蹤器，以便其他人可以獲取項目的最新 源代碼編譯 和使用。

• Write a decent documentation, beside commenting your code clearly of course. The documentation should explain the purpose of the library and provide at least simple examples.

• 編寫測試，如果你願意提供真實世界的代碼。

• 如果你正在建立一個圖書館，把一個 大量的努力，設計一個穩定的 接口。

Answer 1

獲取博客，通過它發佈代碼。解釋你爲什麼寫它，它解決了什麼問題。並鼓勵他人改進，並儘可能保持現有的代碼。如果您的工具非常有用，您將很快開發出一種「信任」您的代碼的以下內容。

對於小工具來說，單獨的文檔並不是必須的，但是如果你想從社區中獲得任何認真的採用，任何爬到框架世界的東西都應該有足夠的文檔和例子。

Answer 2

最重要的是該庫是它的開源，所以我可以自己閱讀代碼。如果這是不可能的，那麼我堅持文件。

也考慮使用項目託管網站（如谷歌代碼或github）。

Answer 3

我認爲文檔是您的項目的關鍵點。

該文件必須註明：

• 你的庫
• 的目的是什麼的主要特點是
• 一個真的簡短的教程，以使其在運行5分鐘。
• 許多例子

Answer 4

我讓人們信任我的代碼中的一些項目，但我敦促人們做出和維護自己的測試，我確保我內容與單元測試。

文檔總是很好，但我非常愧疚地花時間做我想做的事情。但讓作者相當接觸是有幫助的。

Answer 5

張貼在一個開放的源代碼庫，如code.google.com或sourceforge.net可能是從哪裏開始？

下一個吸引眼球，文件明確和succintly庫/應用程序的目的作爲上述答案之一的概述。

最後，博客和直接郵件往來發生......

Answer 6

1. 與你的代碼一個明確的許可，如果你沒有一個已經 （最好是一個鼓勵修改/改進/分享你的 做代碼...）

2. 擁有公共版本控制和/或公共bug /問題跟蹤器和/或郵件列表。有很多很好的網站免費提供這些服務。

3. 單獨的文檔對我來說並不是決定性的因素（如果代碼是有據可查的，代碼質量很高）。

Answer 7

• 文檔解釋爲什麼要這麼寫，當你開始的，它的預期的功能。瞭解你來自哪裏將會讓我看到未來的想法以及你可能未曾見過的短暫想法。
• 解釋API的技術文檔以及如何實現它的一些示例。理想情況下，請將文檔保存爲遵循該語言的格式。例如C＃傾向於使用XML語法來定義項目。這讓我在閱讀時有賓至如歸的感覺。乾淨的代碼 - 我不能強調這一點，因爲太多人寫出格外難看的代碼。如果你的代碼是醜陋的和/或不可讀的，我可能會更容易從頭開始編寫它。至少，讓你的代碼一致。如果我無法理解代碼，我會感到不舒服。
• 解釋您的更改的歷史記錄。看到這個項目如何發展，可以讓我做出更好的計劃。它還讓人們看到你如何從錯誤中學習，並瞭解你的技能水平。與論壇相比，您可以感受到事物得到修復的速度，然後放入新版本。
• 長時間思考你想要什麼樣的許可證。公共區域？ BSD？ GPL？限制性更強？
• 關於您是否介意被聯繫以及是否有任何限制的說明。例如，你會介意更新嗎？我解釋安全漏洞？或者你可能會使用論壇或wiki？
• 我能夠獲得最新工作和/或每晚構建的能力。 SVN什麼的。這很有用，所以我知道我發現的錯誤是否已經修復。

Answer 8

原因之一文檔可幫助人們信任你的代碼，是他們知道一個給定的特徵是一些你預期代碼來執行（和你，所有其他條件相同，保持在未來的版本代碼），或者是當前代碼恰好這樣做的事情，但它可能在任何時候都會作爲錯誤修正或重構的副作用而改變。

有些人更喜歡通過查看代碼的真正功能，這很好，但是文檔告訴你（a）代碼應該做什麼，並且運氣好（b）下一個版本的代碼會做。如果我想長期使用您的代碼，並在提供它們時採取bug修正更新，那麼我需要知道您設計了一個我可以依賴的接口，並且您願意遵守。記錄它是一個強烈的暗示，你至少試圖做到這一點。