Kaneboy贴了一段日本程序员写的代码，JGTM对代码作了重构，俺觉得还可以继续重构成如下 ：
public void UpdateDataCell(DataTable table, int rowIndex, string columnName, object value)
{
table[rowIndex][columnName] = value;
}
public void GetGridItemIndexInCurrentPage(DataGrid grid, int itemPagedIndex)
{
return grid.CurrentPageIndex * grid.PageSize + itemPagedIndex;
}
public void XXX(...)
{
UpdateCell(dt, GetGridItemIndexInCurrentPage(meisaiIchiran,e.Item.ItemIndex), t.BindFldName, txt);
}
我觉得如果某个变量如果只被赋值一次，而且赋值之后只被用到很少几次的话，在不影响可读性和性能的前提下，可以replace temp with query，提倡节约使用，能省就省。
打印 | 张贴于 2004-03-09 10:25:00 | Tag:暂无标签
留言反馈
对，尤其是对public成员，最佳实践中也是建议为其写上一两句，尤其是C#中的XMLDoc功能，甚是好用（因为这个信息将出现在IntelliSense中，所以写这个内容还是为使用这个成员的程序员着想了，这和我的理念是不谋而合啦）。
BTW: 我的毛病是能看英文的不看中文（即只看original的），而写程序的时候也是能写英文的不写中文，因为偶可是想让自己的代码冲出亚洲、走向世界的！嘿嘿~~~ :D
因为根据重构的原则，函数名称、变量名称尽量能够表达他的意思
但是有时候，对于一个类的功能性注释还是要的撒
因为从另一个角度来看，英文的code好像都是代码
只有中文的code东西才是注释，而且每个人都有那么一点点惰性，能看中文的不看英文，呵呵，这个估计是我一个人的毛病了：）
同意你的观点。在原文这段代码中这个方法提取确实必要性不大（因为只用到一次，而且意义尚可表达），我只是结合经验，认为这种代码应该会很多。实际上refactoring就是这么一个渐进的过程，没有一步到位的，也没有绝对的正确，跟程序的特征、环境、开发阶段都有关系，关键是要了解重构的目标（先不说大的目标——refactoring towards design patterns）——要让程序能让别人容易得读懂（但不是靠注释！靠注释才能说明白的程序才是shit），然后才是没有重复代码、继而改善软件结构……
BTW: 我把e.Item.ItemIndex赋给一个重命名的变量的意图主要是觉得e.Item的意义不明确？e是什么？是事件参数。事件的什么参数？读不下去了，你得先了解这个事件处理程序传入的参数的意义……所以通过命名一个变量，我相当于写了一行注释，表达了这个值的意义。另外，t.BindFldName也是同样道理，意义不清，影响阅读。这里面我有一个原则，就是每一个方法都应该是self-descriptive，就是说不需要参考任何文档、其他方法等等就可以读明白某一个方法的意图和逻辑，这才是好的重构、好的代码。这种代码拿出来不用多说，老板给的工资就会不一样（不给？换地儿！），威望也不一样，因为别的程序员都会感激你，因为你写程序很为别人着想，我个人以为这是一个专业程序员的基本素质——虽然我自己也不能说100%都做到，但是这种意识越来越强烈的说。
至于性能，我觉得编译器还会把这个query再变回temp，不信你可以反编译看看，看看是不是酱紫。:D
但UpdateDataCell现在extract出来意义不大
当然也不排除以后重构的可能性