我经常使用基于特定定义算法的代码.这得到了很好的评论,似乎是正确的.对于大多数数据集,算法运行良好.
但随后边缘情况,特殊情况,启发式方法被添加以解决特定数据集的特定问题.随着特殊情况的数量增加,评论越来越模糊.我担心在一年左右的时间内回过头来查看这段代码并试图记住为什么会添加每个特殊的特例或启发式.
我有时希望有一种方法可以在源代码中嵌入或链接图形,所以我可以有效地说,“在这个数据集的图形中,这个特殊功能导致例程不正确地触发,所以这就是为什么这个代码被添加“.
处理这种情况的最佳做法是什么？
似乎总是需要特殊情况来处理这些异常/边缘情况.如何管理它们以使代码保持相对可读性和可理解性？
考虑一个处理照片特征识别的例子(不完全是我正在研究的,但类比似乎很合适).当我找到一般算法失败并且需要特殊情况的特定图片时,我尽可能地在评论中记录该信息(或者如下面的某人建议的描述性函数名称).但是经常缺少的是指向展示相关行为的特定数据文件的永久链接.虽然我的评论应该描述这个问题,并且可能会说“请参阅文件foo.jp以获取此行为的示例”,但此文件永远不会出现在源代码树中,并且很容易丢失.
在这种情况下,人们是否会将数据文件添加到源树中以供参考？
解决方法
如果您有项目的知识库或维基,则可以在其中添加图表,根据
Matthew’s Fowler quote在方法中链接到该图表,也可以在源控件提交消息中添加边缘案例更改.
//See description at KB#2312
private object SolveXAndYEdgeCase(object param)
{
//modify param to solve for edge case
return param;
}
Commit Message: Solution for X and Y edge case,see description at KB#2312
这是更多的工作,但比单纯的测试用例或评论更能彻底记录案例.尽管有人可能认为测试用例应该是足够的文档,但您可能不希望将整个失败的数据集存储在其中.
请记住,模糊的问题会导致模糊的解决方案.