讨论...关于一段代码的可读性.
其实就是关于匿名函数的可读性.
举个例子,对于数据库事务处理开头和结束的代码都差不多,
于是我写了这样一个函数:

C# code

bool DoTransaction(Func<bool> act)
{
    using (var transaction = connection.BeginTransaction())
    {
        try
        {
            var docommit=act();
            
            if (docommit)
                transaction.Commit();
            else
                transaction.Rollback();
            
            return ret;
        }
        catch (Exception)
        {
            transaction.Rollback();
            throw;
        }
    }
}

然后在使用事务的地方这样调用:

C# code

//非数据库事务操作
DoTransaction (()=>{
   //数据库事务操作 
});
//非数据库事务操作

类似的情况还有GDI+ Graphics的状态保存恢复,多线程的对象加锁解锁等.
这样写的好处很明显:少写了不少重复代码,维护起来也方便;
但是总觉得降低了可读性...

大家对这样的写法是怎么看的呢?

------解决方案--------------------
我觉得还好，写多了也不觉得lambda表达式可读性有多差~~~
------解决方案--------------------

代码很简洁。。。
------解决方案--------------------
学习。
------解决方案--------------------
我觉得可读性挺好的，实现思路也很有意思...
------解决方案--------------------
lambda表达式在对代码的简化方面上，做的太好了.
真正理解了lambda表达式之后，可读性怎么可能差呢
------解决方案--------------------
可以，相当于act里面的逻辑是事务性的
------解决方案--------------------
值得肯定
------解决方案--------------------
纠结。。。。如果懂lambda就觉得还可以，如果不懂的话会搞得人一头雾水。
------解决方案--------------------
就这样挺好，就要最大化利用语言的特性
------解决方案--------------------
代码写的很好啊 没觉得哪不好理解
------解决方案--------------------

探讨

引用:

我觉得还好，写多了也不觉得lambda表达式可读性有多差~~~
唉...曾被说这样写初学的看不懂..


引用:

我觉得可读性挺好的，实现思路也很有意思...
黑长直童鞋不来签个约么?

------解决方案--------------------
不太赞同楼上各位的观点！

感觉代码的可读性确确实实的降低了。
------解决方案--------------------
我想问的是怎么样才能像楼主那样把代码贴不出来，看着像开发工具里的样子。
而不会显示成如以下的那样变成纯文本？
//非数据库事务操作
DoTransaction (()=>{
//数据库事务操作 
});

------解决方案--------------------
代码写的有很多余的地方。

没有必要写try...catch，因为DBTransaction在跳出Using{}的时候，会执行其Dispose。比如SqlDbTransaction就会自动当没有回滚的时候自动回滚。用不着画蛇添足地写什么transaction.Rollback()。

没有必要在正常执行中又搞什么异常bool判断。当正常的流程失败，就抛出异常就行了。不要搞什么返回bool值（这是从十几年前c语言入门教程里学的吧？c语言入门教程里不会有异常机制的）。

这样，你的方法内部也就是一个Using{}，内嵌一个调用act方法，也就剩下两行代码了。

更进一步，既然DoTransaction方法内这两行代码这么简单，许多时候也就没有必要可以封装调用这个方法，而是直接写着两行代码就行了。所以DoTransaction方法也可以省了。
------解决方案--------------------
貌似这样写法还有个优点，往常程序员很容易犯的错误就是结构化不好，在begintransaction 和commit之间直接return或break，开启的事物没有关闭掉，造成错误，而这样写就没有这方面的问题。
------解决方案--------------------
就思路而言，挺不错的思路啊

如果说看不懂那也没办法，你总不能让李昌镐和常昊去下大家都看得懂的随手棋把

在说对于看的懂的，实际上反倒是更容易交流。

一句单例模式，一句策略模式，依赖抽象，ok，俺明白了也你想干嘛了

难道全世界都看的明白的几百行表达出来的一个依赖抽象的东西，比一句依赖抽象这个词更容易交流不？

你很明显不是，你告诉“依赖抽象”这4个字我就明白了，比那几百行滴代码，读都要读个半个小时的东西更容易让人明白