我一直在评估一个在纸上看起来很棒的框架。问题是示例代码不完整且质量差。提供的参考实现在大多数情况下并不打算使用（因此它们也可以被视为示例代码）并且只是成功地让我感到困惑。
我知道事情在纸上看起来更好是很常见的，但我对示例代码的经验让我不愿进一步调查。
您是否让糟糕的代码示例改变了您对框架/库的判断？到目前为止，我的经历类似于“简历效应”：如果有人不努力检查简历的拼写，他们可能不会得到这份工作......
【问题讨论】：
标签： frameworks
对我来说，确实如此。我倾向于避免使用代码示例不完整的库。如果库是开源的，我会忽略它，因为我可以直接查看代码，看看库的内部是否合理，而且我知道，如果有一天出现问题，我可以（如果必须）修复它。
如果图书馆是商业的，并且他们的样本和/或文档很差，我会寻找其他地方。我只是将其视为风险管理——糟糕的样本让我对图书馆的整体质量感到担忧。
无论纸面上或理论上有多好，编程时仍然可能是废话。
【讨论】：
我认为这是拒绝和评估其他库的正当理由。作为库的潜在用户，缺乏文档和/或错误的代码示例给人的印象是该库还不够成熟，无法供第三方使用。随着时间的推移，它很可能会获得缺失的部分，但在那之前我认为寻找其他地方是合理的。
我最近正在评估人们上传到 github.com 的大量博客应用程序，我很快跳过了那些没有文档的应用程序，因为它们显然还没有准备好供其他人使用。最后剩下的那些有一个很好的自述文件，其中包含有关如何启动和运行应用程序的信息以及运行代码的在线示例。
【讨论】：
糟糕的代码示例加上糟糕的文档将使我远离图书馆，除非有令人信服的理由使用它。但是，具有或者 好的代码示例或 好的文档的库通常值得使用。 （假设图书馆本身满足我的需求。）
【讨论】：
如果我找不到很好的例子（和/或文档）来说明如何使用这个库，我肯定不太可能使用它——实际上，它会让我更难弄清楚如何。但我不在乎 实现 库本身的代码是什么样的。我不认为我会选择一个库/框架而不是另一个，因为一个库/框架的开发人员已经表现出编写更清晰代码的能力（这就是我理解的“恢复效应”的意思）。
【讨论】：
缺乏文档和示例使我不太可能使用该特定库。如果存在解决问题的替代解决方案，我不值得花时间测试并试图弄清楚黑匣子是如何工作的。
【讨论】：
是的，当然。每个库都应该附带一个使用程序和 CLI 接口的简单示例（对于具有 <3 方法和
如果你的框架很难使用，甚至原始编码人员在使用它时都会出错，为什么它“看起来很棒”？
【讨论】：
这对我来说当然很重要。编码草率/不完整和沟通不畅的证据降低了我对实际实现代码稳定和健壮的信心。
【讨论】：
我自己是的，但肯定有一些人不会因此而被关闭，否则很多开源项目早就死了。
【讨论】：