程序的可读性跟性能是成反比的

程序的可读性和性能是成反比的？
如题

都说说自己的优化心得

有多少人认为正则表达式比较快的,举个手?





------解决思路----------------------
正则表达式是最慢的.无需说明...
------解决思路----------------------
个人无法举例认证，不过我可以举反例子：

程序性能低下，代码混乱，风格不统一=》 可读性一定差。
------解决思路----------------------

引用:

那举手之劳即可完成的性能优化 比如这样的

//写法1
if(state == 1)
{
    return true;
}
else
{
    return false;
}
//写法2
return state == 1 ? true : false;
//优化后
return state == 1;

我会采用写法2。。。  因为直接看到return state == 1我会先楞个半秒
------解决思路----------------------
性能跟可读性没必然联系吧，有的人代码很漂亮啊，可是执行效率低
------解决思路----------------------
过早优化是祸害。

看不懂的代码怎么优化？？？

程序遵循2-8定律，也就是说，只有20%的代码消耗了80%的时间，因此抛开代码被执行的概率不同这个现实不谈，要求程序处处高效，既不经济也不现实。
------解决思路----------------------
不能这么绝对地说“程序可读性和性能成反比”。特别是当你把可读性夸张了的时候。

在可读性方面，只有较低级的“只有极少量单词匹配需求”的程序才用到那个。比如说有人想匹配
     <img class="1234" src="kadkfakf"></img>
它不考虑img改成大写的情况，不考虑class之前还有别的属性的情况，不考虑双引号中有>符号的情况，不考虑src跟=之间有空格的情况，也不考虑 <img></img>写成<img />的情况，等等。只是想去简单匹配个别词儿，而不懂语法分析。此时说它具有“可读性”，其实是因为读他的人首先就只知道这一点词儿。

对于极简单的字符串处理，那么你说或许是个真理。就好像有人说要用“字符串来执行程序”，他倒是可读性高了，可是他不知道这不仅仅是性能降低50倍的问题，其实是当程序扩展重构之后“立刻变得诡异”的问题，在工程上的“乱”早已经被看破了。
------解决思路----------------------
应该不一定吧
------解决思路----------------------
正则表达式的强大在于它的功能，而不是它的性能。
------解决思路----------------------

------解决思路----------------------
首先想说的是可读性和性能之间没什么必然联系。
如果你想拿正则表达式来说事的话，我就想说为什么要创造出正则表达式以及LINQ?如果自己用字符串以及条件判断也能做到它们做到的结果，它们的出现主要是能够够方便地让我们写程序。
而且正则表达式你觉得可读性不强只是因为你没学好而已，熟悉的话就不会这样觉得。
------解决思路----------------------

引用:

过早优化是祸害。

看不懂的代码怎么优化？？？

程序遵循2-8定律，也就是说，只有20%的代码消耗了80%的时间，因此抛开代码被执行的概率不同这个现实不谈，要求程序处处高效，既不经济也不现实。

同意