编程时不要学习这样的行为，听完之后感觉自己中枪无数

RyanBern

拿今天上编程课的破事来水一帖……

今天上课的主要内容是程序代码规范，老师讲了写代码时的基本原则，说了一些千万不能出现的东西，听完后感觉自己处处中枪。

1.方法的长度超过15行

2.临时变量起作用的范围超过5行

3.结构层次超过3层

4.写程序时候用到了ctrl+c / ctrl + v大法

5.经常用一些又短又没有含义的变量名如temp, val, num

总之，一句话，不要写只有自己才能看懂的代码（即使这样也是在短时间内）。
听起来好有道理，我竟然无言以对。

然后就是课堂作业：重构一个小游戏程序，尽量精简代码。
这个代码我贴在下面了，不管你会不会编程，你都能感觉到，“这代码写得太美我不敢看”：

"甜美的代码"

用我现在的水平我大概能精简到原来的1/5吧，当然是保证运行效率不减少的情况下。
老师说这个代码是在网上找的，估计是百度搜出来的（尼玛又黑我大天朝百度）

突然想起了我上数据结构和算法课的时候，老师说过这么一句话：编程的大概分为两种人，一种是搞程序的，一种是搞算法的。这两种人的主要区别是在于他们在编程中起到的地位不同，搞算法的应该属于比较基础的部分，注重细节的实现，而搞程序的倾向于把各种程序“零件”组合在一起，更注重整体的结构（渣理解）。比方说Array#sort这个方法，我们很少关心它是怎么实现的，只需要会使用它就可以了，但是搞算法的就要把它具体怎么实现，细节处理等工作做好。

其实从这方面上我们可以看出，程序员把大部分精力花在了程序结构设计上，想办法降低程序的维护难度，提高程序的可移植性以及代码的可读性，而做算法的专业人员从运行效率出发，写出跑得快（时间复杂度），资源耗费小（空间复杂度）的算法，所以可以写出一个只有自己才能看懂的代码。

因此，老师说，“做程序的就是天天在电脑前面吃泡面的，做算法的就是坐在办公室里面写书的”，感觉这句话黑化了程序员。两种人都认为自己的领域要比对方的重要，这也无可厚非，但是，RB想说的是，做事情的时候一定要把自己的思维调整到最合适的模式，来适应不同任务的需求。（比方说写脚本就应该用程序员的思路）

chd114

我会说直到一个星期前我才知道还有ctrl+z的组合键吗···以前只以为有ctrl+x/c/v的人泪奔···

taroxd

寒冷魔王 发表于 2014-11-28 18:10
还可以啦~反正我是学电气的~

松本行弘不是提出个DRY原则吗，我记得是这个来着Don't repeat yourself

好的程序是一眼就能看懂的，好的算法往往是好多眼都看不懂的。

算法和程序真的是两个世界。

寒冷魔王

还可以啦~反正我是学电气的~

松本行弘不是提出个DRY原则吗，我记得是这个来着Don't repeat yourself

而且我感觉你老师说的什么算法啦程序员啦神马的不是很对，写程序不就是要自己弄出算法来吗。
我没学过算法，只是大概看过书，就是提供很多好的算法，同时便于算法优化神马的。。
很多算法自己想不出来，别人为你想好了，自己直接拿来用就行了。我感觉这就像是学数学，其实数学的内涵我们大都不懂，神马神马公式都不会推导，但是我们会用。
真正的数学家是会自己创造公式的，真正的程序员还是应该会自己创造算法的。所以老师把两者分开是不对的。
很多时候掌握的东西少，所以就不得不想方设法去创造算法来实现。比如我N年前神马都不会，想弄个整数数组排序，于是想啊想想出个把数组元素和新的储存数组序号挂钩的方法。近来才知道那个方法叫做神马箱子排序法= =
所以我觉得写程序应该让自己成为“初级人员”，神马都不会，需要自己来想。这样就成为了创造算法的写程序的人了。

当然学习也是必要的。我感觉算法课应该属于拓展思路，而不是直接拿来用，拿来套。不然只是个初级的程序员。
但是，很多时候是没必要考虑那么多的。
抽象编程对基层的关注不是很高，就像Java里的Arrays.copyOf();，知道它是用C++写的，比迭代快不就行了吗。
当然如果想自己造一门语言当然是要理解那些基层问题了。

只能说是创造语言和使用语言的人有差别，我认为搞算法和写程序的没神马差别。

精灵使者

其实，这个比喻可以比喻成“卖饭的老大妈”
我们经常来买饭，看到的是卖饭的老大妈，而不是看到后面的厨房。
虽然老大妈接了钱之后，就给后面的厨房下命令做饭，然后做出来的饭再放到前面来给我们吃……

orochi2k

【黑幕】在GAMELOFT家的某个游戏的某的函数我们写了100多行，又因为各种需求乱改后来变成了300多行

金圭子

呃，好像我前面回帖的时候没看完全贴？
晚上回来才看到后面一段关于“算法”和“程序”的说法。

我以前老师好像从来没说过（我也是学计算机的），不过我自己倒是一直这么理解的（虽然不知道对不对）：
计算机编程的过程分为两步：数学建模和实现（我自己起的名字，其实我们大学都没教过数学建模，学的是高数而不是应用数学）。其中“数学建模”就是把用户的需求（哪怕是你自己为了你自己写了一个程序，也是有“用户”的，就是你自己）逐步分解到最细，比如烧水就可以分解为买水壶等设备（如果有的话可省略）、打水、灌壶、劈柴、烧火、等烧开、灌在热水瓶里这几个步骤，比如一个排序算法的程序就分为两两比大小、交换（交换还可以再细化为A到tmp，B到A，tmp到B）再各种循环（这里就体现算法了）。而“实现”就是用计算机语言把每个步骤写出来。

我一直就是这么理解的，不过说实话才知道原来这是两种人去做的？（好吧我很少和人合作写东西，所以从头到尾都是我一个人包办了……）
好像我唯一一次和人合作写程序是还在大学读书的时候给一个网站写社区游戏（类似现在我们网站的口袋怪兽这种），当时我写前台实现部分（主要就是游戏创意和javascript部分），而我一起混那个论坛的一个同学写后台数据库部分（主要是php和mysql读写的部分），主要原因是当时我比较有激情有想法，但是一旦做到自己能玩了就会习惯性把它扔到了一边，而我同学就把“我能玩”变成“大家都能玩”，所以……

无脑之人

感觉这个规范并不是那么令人可以接受呢【
1.方法的长度本应该视情况而定，如果是一个比较复杂的东西长了也是正常的。为了减少方法长度而去不停地分出子函数来，未必是件好事。毕竟，可不是所有语言都能优化inline。
2.妈呀这年头局部变量这么没人权？5行作用就不让起了？卧槽我见过很多代码都是局部变量持续使用的。
3.妈呀这坑爹规则还有人用？
4.小程度上的可以考虑，毕竟不是每个语言都有宏，也不是所有相似的代码都值得去泛化。
5.卧槽我觉得temp，val，num含义太TM明显了——这就是临时使用的局部变量。不过变量名的选取的确需要斟酌。
至于最后老师说的话，我个人觉得有点道理，但是搞程序的也应当考虑程序的效率，搞算法的也应该考虑代码结构方面的东西——比起极端化来说，能够兼顾是更好的吧。

grayuncle

千万别说自己是搞程序的  找不到女朋友的！就说自己是搞设计的  
搞程序是很耗阳气的东西

RyanBern

金圭子 发表于 2014-11-26 15:17
关键是这句话，看了下楼主的情况介绍，我猜你说的是大学的计算机专业课程吧？
呃，说句“过来人”的话， ...

您说的这些道理我也想过，一定程度上确实是这样。不过这句话并不是只出现在计算机专业课中，其实只要是写代码就应该有这种出发点。这也可以说是一直培养一种习惯吧，说不好听一点叫强迫症（雾）。至于大学学的知识在工作中的分量，这个应该和工作性质有关。如果你要当一个教授（当然是你所学专业的），那么知识的吻合度就非常高，不过，基础就是基础，虽然表面上看不出来和实际工作的联系，但是没有基础是绝对不可以的。

代码规范是写程序时的一个必要条件，特别是多人合作或者是代码公开时，当然如果你要自己用的话，只要你自己能认识，怎么写都可以。