你如何让别人信任你的代码并使用它？

Question

我不时写爱好代码。事情就是这些工具，类或微小的代码库最终会成为一个无望未来的闪存棒！我希望进一步发展我的项目，并让其他程序员信任他们。如果您要使用在Internet上找到的东西，那么您在该编程工具或小型库中寻找的最重要的东西是什么？例如你会考虑单独的文件吗？

---

感谢所有捐助者。我会尽力总结已经说过的话。随意修改列表。更正和补充更受欢迎：）

• 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-tracker，所以其他人可以获得 您项目的最新源代码 编译和使用。

• 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

最重要的是该库是开源的，所以我可以自己阅读代码。如果那是不可能的，那么我坚持要文件。

还要考虑使用项目托管网站（如Google代码或github）。

Answer 3

1. 如果您还没有代码，请拥有明确的许可证 （最好是鼓励修改/改进/分享你的 代码......）

2. 拥有公共版本控制和/或公共错误/问题跟踪器和/或邮件列表。有很多很好的网站免费提供这些服务。

3. 单独的文档对我来说不是决定性因素（如果代码记录良好且代码质量很高）。

Answer 4

• 解释您编写它的原因，启动时的文档，以及它的预期功能。了解你的来源将使我能够看到未来的想法，以及你可能没见过的短暂的想法。
• 解释API的技术文档以及有关如何实现它的一些示例。理想情况下，请将文档保留为遵循该语言的格式。例如，C＃倾向于使用XML语法来定义项目。这让我在阅读时能有宾至如归的感觉。
• 清洁代码 - 我不能强调这一点，因为太多的人写了异常丑陋的代码。如果你的代码很丑陋和/或不可读，我可能更容易从头开始自己写代码。至少，让您的代码保持一致。如果我无法理解代码，我会觉得不舒服。
• 解释您的更改的历史记录。看到项目如何发展，我可以更好地进行规划。它还允许人们看到你如何从错误中吸取教训，并了解你的技能水平。与论坛相比，您可以了解事物的修复速度，然后将其放入新版本中。
• 仔细思考你想要什么样的许可证。公共区域？ BSD？ GPL？限制性更强？
• 关于您是否介意联系以及是否有任何限制的说明。例如，你介意更新吗？我解释安全漏洞？或者你可能会使用论坛或维基？
• 能够让我获得最新作品和/或夜间制作。 SVN什么的。这很有用，所以我知道我发现的错误是否已经修复。

Answer 5

我认为文档是您项目的关键点。

该文件必须注明：

• 您图书馆的目的是什么
• 主要功能是什么
• 一个真正的简短教程，让它在5分钟内运行。
• 许多例子

Answer 6

我让人们相信我的代码在许多项目中，但我敦促人们制作和维护自己的测试，并确保我内容与单元测试。

文档总是很好，但我很想找时间做我想做的事情。但让作者可以接受是有帮助的。

Answer 7

将其发布到开源存储库（例如code.google.com或sourceforge.net）可能是从哪里开始...

接下来为了吸引注意力，在上面的答案之一中清楚地，简洁地记录图书馆/申请的目的。

最后，博客和直接邮件交流发生......

Answer 8

文档可以帮助人们信任您的代码的一个原因是，他们知道某个特定功能是否是您想要代码要做的事情（以及您将在其他条件相同的情况下，将来保留哪些功能）代码的版本），或当前代码恰好发生的事情，但可能随时改变，作为错误修复的副作用或只是重构。

有些人更喜欢通过查看它来找出代码真正做了什么，这很好，但文档告诉你（a）代码应该做什么，并且运气好（b）代码的下一个版本是什么会做。如果我想长期使用你的代码，并在你提供它们时采取bugfix更新，那么我需要知道你已经设计了一个我可以依赖的接口并且你愿意坚持。记录它是一个强烈的暗示，你至少试图这样做。