编程中的美学
在BLOG注册了很久了,但是一进来就看到了那篇所有博客必读的文章,为了给诸位留下个好的印象,小弟的处女作始终没有诞生,生怕说错了什么,当众出丑.每日只得在这里浏览诸位的文章,心中暗痒.今日家宴与家人一起小酌了几杯,趁着自己尚在朦胧之中,胆气尚足之时,写下自己在这里的第一篇作品.,说的不好你当我 是酒后胡言,你要是认为说的有些道理,那么就请诸位有钱的捧个钱场,没钱的捧个人场.谢谢!
这里我要说的是美学与编程,大多数的人认为,美学是隶属于人类感性范畴之内的事情,与极其强调,逻辑思维与理性的编程扯不上什么关系.
但是随着科学的发展,越来越多的理化学科与美学交汇到了一起,其中最著名的当属物理学与美学的结合,前不久看到了一本物理学的书,书中有这样的一句话:"物理学定律本应是优美的。”因为在经典的牛顿力学中，麦克斯韦电磁学的定律在运动时有复杂而丑陋的表现形式，这一点深深地刺激了菲兹杰拉德（George.F.Fitzgerald）、洛伦兹（Hendrik.A.Lorentz）、彭加勒（Henri.Poincare）、拉莫（Joseph.Larmor）还有爱因斯坦（Albert.Einstein）。他们为了追求一个更加优美的理论，推翻了牛顿创立的以绝对时空观为基础的经典力学，并最终创立了狭义相对论，使麦克斯韦电磁学的定律在任情况下都有简单而优美的形式。甚至于作为爱因斯坦相对论的核心的“相对性原理” 本身就是一个“形而上（metaprinciple）”的原理。从爱因斯坦以后,理论物理学家们对任何物理学公式的评价都是建立在美学的基础上的,这个公式在任何情况下是否动能保证简洁与漂亮,这是评价一个物理学公式的基本要素.
那么什么样的程序算是漂亮的呢?今天越来越多的程序员将编程称之为艺术.很多人也在不断的强调着编程时个人不同的风格,对此我说些自己的看法,一般来说编程的中的美学涉及到2个主要的方向,源程序与用户界面.
首先说下用户界面,任何一个程序的创作的最终目的都是为了服务于用户,无论这个用户是程序员本身还是其他人,良好的界面无疑会给使用者以舒适 的感觉,那么什么是良好的界面呢?首先我们了解到计算机使用者大都是非计算机专业的人员这一趋势的扩大,那么易用无疑是良好界面的基础,在易用的基础上对界面进行适当的美化(包括颜色,皮肤,按钮等,在此不做赘述)相信你的程序会得到更多的好评.最典型的例子就是为什么全世界大多数的人都用WINDOWS而步用LINUX或UNIX,如果WINDOWS也像LINUX一样高级指令需要命令行来完成相信MICROSOFT也不会是今天这样.
接下来主要谈的是源程序中的美学,源程序的美学又表现为两个方面：编辑和编程方法。
我最喜欢用一位真正的高手的话来概括源程序中的美学,那就是李小龙说过的:"简单是美,尽其在我!"
这句话无论对程序代码本身,还是程序的算法都是适用的,要做到这点并不容易,但是前辈们的一些经验还是值得我们学习的,比如说统一书写规范,一直以来程序员们最头疼的莫过于读别人的程序,有的时候自己写的程序时间长了自己都读不懂,因此在程序上加上适量的说明文字是很重要的,遗憾的是很多人没有这样的习惯,而更多的人不清楚适量的说明应该是多少,他们认为自己的写的够详细了,但是很多人依然难以理解,一般说来解释文件起码要占一个程序的百分之五十才可以.如果大家都保持良好的书写风格的话那么程序员之间的交流恐怕就不会这么麻烦了.
至于编程方法，我们有一个原则那就是:"我们编程时尽力把短小高效和简单优美统一起来；但当我们必须在两者之中挑选一个时，我们通常选择后者”，关于这点的细节，前辈们早有总结，如“模块要单入单出”、 “尽量不用GOTO（除非是为了简单优美的目的，但这种情况相当罕见）”等。这点又是与所用的语言有相当的关系，也许这就是著名前辈E.W.Dijkstra（世界上最好的程序设计员）在1975年说：“学了那些不好的语言会使你的脑筋致残”的原因吧。"一般来说，经典的算法通常都是“美”的。比如 GIF 编码/解码程序.
以下是给程序员们的一些建议:
在软件编程过程中，如果每个程序员都按自己的习惯和风格编写程序，这种因人而异的程序风格势必降低程序的可读性，对软件的测试、交流、重用以及软件的维护产生极为不利的影响。为了解决这个问题，最终提高开发效率，必须执行本规范。
本规范在编程基本风格、可读性、结构化、正确性与容错性、可重用性等方面提出了要求，它是程序员编程素质的综合体现。程序员的编程水平＝编程规范＋编程效率。
1.基本要求
1.1程序结构清析，简单易懂，单个函数的程序行数不得超过100行。
1.2打算干什么，要简单，直接了当，代码精简，避免垃圾程序。
1.3尽量使用标准库函数和公共函数。
1.4不要随意定义全局变量，尽量使用局部变量。
1.5使用括号以避免二义性。
2.可读性要求
2.1可读性第一，效率第二。
2.2保持注释与代码完全一致。
2.3每个源程序文件，都有文件头说明，说明规格见规范。
2.4每个函数，都有函数头说明，说明规格见规范。
2.5主要变量（结构、联合、类或对象）定义或引用时，注释能反映其含义。
2.7常量定义（DEFINE）有相应说明。
2.8处理过程的每个阶段都有相关注释说明。
2.9在典型算法前都有注释。
2.10利用缩进来显示程序的逻辑结构，缩进量一致并以Tab键为单位，定义Tab为 6个字节。
2.11循环、分支层次不要超过五层。
2.12注释可以与语句在同一行，也可以在上行。
2.13空行和空白字符也是一种特殊注释。
2.14一目了然的语句不加注释。
2.15注释的作用范围可以为：定义、引用、条件分支以及一段代码。
2.16注释行数（不包括程序头和函数头说明部分）应占总行数的 1/5 到 1/3 。
3.结构化要求
3.1禁止出现两条等价的支路。
3.2禁止GOTO语句。
3.3用 IF 语句来强调只执行两组语句中的一组。禁止 ELSE GOTO 和 ELSE RETURN。
3.4用 CASE 实现多路分支。
3.5避免从循环引出多个出口。
3.6函数只有一个出口。
3.7不使用条件赋值语句。
3.8避免不必要的分支。
3.9不要轻易用条件分支去替换逻辑表达式。
4.正确性与容错性要求
4.1程序首先是正确，其次是优美
4.2无法证明你的程序没有错误，因此在编写完一段程序后，应先回头检查。
4.3改一个错误时可能产生新的错误，因此在修改前首先考虑对其它程序的影响。
4.4所有变量在调用前必须被初始化。
4.5对所有的用户输入，必须进行合法性检查。
4.6不要比较浮点数的相等，
如： 10.0 * 0.1 == 1.0 ， 不可靠
4.7程序与环境或状态发生关系时，必须主动去处理发生的意外事件，如文件能否逻辑锁定、打印机是否联机等。
4.8单元测试也是编程的一部分，提交联调测试的程序必须通过单元测试。
5.可重用性要求
5.1重复使用的完成相对独立功能的算法或代码应抽象为公共控件或类。
5.2公共控件或类应考虑OO思想，减少外界联系，考虑独立性或封装性。
5.3公共控件或类应建立使用模板。
1、交通事故
2、七.web框架-----------VUE路由语法 在项目简单中使用 （七）
3、flex弹性布局
4、POJ2155 Matrix <树套树/二维树状数组>
5、asp.net内置对象session和cookie
这里我要说的是美学与编程,大多数的人认为,美学是隶属于人类感性范畴之内的事情,与极其强调,逻辑思维与理性的编程扯不上什么关系.
但是随着科学的发展,越来越多的理化学科与美学交汇到了一起,其中最著名的当属物理学与美学的结合,前不久看到了一本物理学的书,书中有这样的一句话:"物理学定律本应是优美的。”因为在经典的牛顿力学中，麦克斯韦电磁学的定律在运动时有复杂而丑陋的表现形式，这一点深深地刺激了菲兹杰拉德（George.F.Fitzgerald）、洛伦兹（Hendrik.A.Lorentz）、彭加勒（Henri.Poincare）、拉莫（Joseph.Larmor）还有爱因斯坦（Albert.Einstein）。他们为了追求一个更加优美的理论，推翻了牛顿创立的以绝对时空观为基础的经典力学，并最终创立了狭义相对论，使麦克斯韦电磁学的定律在任情况下都有简单而优美的形式。甚至于作为爱因斯坦相对论的核心的“相对性原理” 本身就是一个“形而上（metaprinciple）”的原理。从爱因斯坦以后,理论物理学家们对任何物理学公式的评价都是建立在美学的基础上的,这个公式在任何情况下是否动能保证简洁与漂亮,这是评价一个物理学公式的基本要素.
那么什么样的程序算是漂亮的呢?今天越来越多的程序员将编程称之为艺术.很多人也在不断的强调着编程时个人不同的风格,对此我说些自己的看法,一般来说编程的中的美学涉及到2个主要的方向,源程序与用户界面.
首先说下用户界面,任何一个程序的创作的最终目的都是为了服务于用户,无论这个用户是程序员本身还是其他人,良好的界面无疑会给使用者以舒适 的感觉,那么什么是良好的界面呢?首先我们了解到计算机使用者大都是非计算机专业的人员这一趋势的扩大,那么易用无疑是良好界面的基础,在易用的基础上对界面进行适当的美化(包括颜色,皮肤,按钮等,在此不做赘述)相信你的程序会得到更多的好评.最典型的例子就是为什么全世界大多数的人都用WINDOWS而步用LINUX或UNIX,如果WINDOWS也像LINUX一样高级指令需要命令行来完成相信MICROSOFT也不会是今天这样.
接下来主要谈的是源程序中的美学,源程序的美学又表现为两个方面：编辑和编程方法。
我最喜欢用一位真正的高手的话来概括源程序中的美学,那就是李小龙说过的:"简单是美,尽其在我!"
这句话无论对程序代码本身,还是程序的算法都是适用的,要做到这点并不容易,但是前辈们的一些经验还是值得我们学习的,比如说统一书写规范,一直以来程序员们最头疼的莫过于读别人的程序,有的时候自己写的程序时间长了自己都读不懂,因此在程序上加上适量的说明文字是很重要的,遗憾的是很多人没有这样的习惯,而更多的人不清楚适量的说明应该是多少,他们认为自己的写的够详细了,但是很多人依然难以理解,一般说来解释文件起码要占一个程序的百分之五十才可以.如果大家都保持良好的书写风格的话那么程序员之间的交流恐怕就不会这么麻烦了.
至于编程方法，我们有一个原则那就是:"我们编程时尽力把短小高效和简单优美统一起来；但当我们必须在两者之中挑选一个时，我们通常选择后者”，关于这点的细节，前辈们早有总结，如“模块要单入单出”、 “尽量不用GOTO（除非是为了简单优美的目的，但这种情况相当罕见）”等。这点又是与所用的语言有相当的关系，也许这就是著名前辈E.W.Dijkstra（世界上最好的程序设计员）在1975年说：“学了那些不好的语言会使你的脑筋致残”的原因吧。"一般来说，经典的算法通常都是“美”的。比如 GIF 编码/解码程序.
以下是给程序员们的一些建议:
在软件编程过程中，如果每个程序员都按自己的习惯和风格编写程序，这种因人而异的程序风格势必降低程序的可读性，对软件的测试、交流、重用以及软件的维护产生极为不利的影响。为了解决这个问题，最终提高开发效率，必须执行本规范。
本规范在编程基本风格、可读性、结构化、正确性与容错性、可重用性等方面提出了要求，它是程序员编程素质的综合体现。程序员的编程水平＝编程规范＋编程效率。
1.基本要求
1.1程序结构清析，简单易懂，单个函数的程序行数不得超过100行。
1.2打算干什么，要简单，直接了当，代码精简，避免垃圾程序。
1.3尽量使用标准库函数和公共函数。
1.4不要随意定义全局变量，尽量使用局部变量。
1.5使用括号以避免二义性。
2.可读性要求
2.1可读性第一，效率第二。
2.2保持注释与代码完全一致。
2.3每个源程序文件，都有文件头说明，说明规格见规范。
2.4每个函数，都有函数头说明，说明规格见规范。
2.5主要变量（结构、联合、类或对象）定义或引用时，注释能反映其含义。
2.7常量定义（DEFINE）有相应说明。
2.8处理过程的每个阶段都有相关注释说明。
2.9在典型算法前都有注释。
2.10利用缩进来显示程序的逻辑结构，缩进量一致并以Tab键为单位，定义Tab为 6个字节。
2.11循环、分支层次不要超过五层。
2.12注释可以与语句在同一行，也可以在上行。
2.13空行和空白字符也是一种特殊注释。
2.14一目了然的语句不加注释。
2.15注释的作用范围可以为：定义、引用、条件分支以及一段代码。
2.16注释行数（不包括程序头和函数头说明部分）应占总行数的 1/5 到 1/3 。
3.结构化要求
3.1禁止出现两条等价的支路。
3.2禁止GOTO语句。
3.3用 IF 语句来强调只执行两组语句中的一组。禁止 ELSE GOTO 和 ELSE RETURN。
3.4用 CASE 实现多路分支。
3.5避免从循环引出多个出口。
3.6函数只有一个出口。
3.7不使用条件赋值语句。
3.8避免不必要的分支。
3.9不要轻易用条件分支去替换逻辑表达式。
4.正确性与容错性要求
4.1程序首先是正确，其次是优美
4.2无法证明你的程序没有错误，因此在编写完一段程序后，应先回头检查。
4.3改一个错误时可能产生新的错误，因此在修改前首先考虑对其它程序的影响。
4.4所有变量在调用前必须被初始化。
4.5对所有的用户输入，必须进行合法性检查。
4.6不要比较浮点数的相等，
如： 10.0 * 0.1 == 1.0 ， 不可靠
4.7程序与环境或状态发生关系时，必须主动去处理发生的意外事件，如文件能否逻辑锁定、打印机是否联机等。
4.8单元测试也是编程的一部分，提交联调测试的程序必须通过单元测试。
5.可重用性要求
5.1重复使用的完成相对独立功能的算法或代码应抽象为公共控件或类。
5.2公共控件或类应考虑OO思想，减少外界联系，考虑独立性或封装性。
5.3公共控件或类应建立使用模板。
以上这些仅仅是对平时编程时的一些个人习惯的建议,希望大家能够逐渐养成上面的习惯,让我们能创造出更"美"的程序.
这是以前在文章里发布的东东！但是我发现没有人看，于是就挪到这里了！嘿嘿！
1、交通事故
2、七.web框架-----------VUE路由语法 在项目简单中使用 （七）
3、flex弹性布局
4、POJ2155 Matrix <树套树/二维树状数组>
5、asp.net内置对象session和cookie