Welecome

最近闲来无聊，本来想写下自己对反射的理解以及它的好处，结果，碍于懒惰，再加上平时网络上关于反射的东西太多，所以就搁浅了。

在我看来，了解反射机制并不是最困难的，也不是我最关心的，我在乎的是在最短的时间内学会使用反射机制进行操作数据，完成项目要求，OK。

数据绑定，对大家来说并不陌生，特别是采用对数据库的访问，然后把返回值赋值到能够接收该数据源的控件上，如dataGridView这种（Winform方向）。而且关于绑定这样的数据的介绍太多太多，我也不关心。如果我们需要将数据放到文本框中显示时，就要采用txtBox.Text=“××”的赋值方式。然后获取的时候还要访问一次txtBox.Text，然而这种方式并不是不好，只是我们应该尝试着换一种方式，如数据绑定，即使这个控件没有DataSource属性。

我们在修改控件属性的时候，我们常常都看到

最近在一个网站上看到了一篇文章，收集了一些经典的编程引言，特意摘了几条比较喜欢的放在这里。再附上自己的理解。

1、过早的优化是万恶之源。

Premature optimization is the root of all evil!
- Donald Knuth

嗯。有道理，一般来说，需求变更会导致代码变更，代码变更会导致你做的代码优化工作付诸东流。所以，往往采用 “ 先实现再优化 ” 的原则，不管代码性能有多么差，先实现功能再说，把功能拿给客户，当客户确认了这个功能就是他要的东西而不是什么别的，（通常他会提出一些小意见），那么好，接下来，就可以实现这些小意见了，并且可以放心的优化代码了，至少不必担心大部分的优化工作付诸东流了。呵呵。

另外还有几种情况，也是和不要过早优化有关。

要实现非常复杂

n自己所作的项目中开始慢慢接触到程序的优化部分，慢慢的对这些有了很多的理解。代码的书写规范化有助于团队中成员对你代码快速的理解。代码的优化有助于让程序运行速度更快一些。所以如下特转一些文字说明和本人的一些愚见。

C#代码优化拾贝

1、Float并不比Double要快

   软件测试和优化工作的一个重要原则是以实验为基础，一切以实验结果为准；我曾想当然的认为Float类型的位数少，理所当然应该比Double类型运算的要快。然而实验证明，这种想法是错误的；

考察如下代码的速度：

           int i,j;