Project1

标题: 编程时不要学习这样的行为，听完之后感觉自己中枪无数 [打印本页]

---

作者: RyanBern    时间: 2014-11-25 20:07
标题: 编程时不要学习这样的行为，听完之后感觉自己中枪无数


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

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

1.方法的长度超过15行

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

3.结构层次超过3层

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

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

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

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

"甜美的代码"

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

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

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

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

---

作者: 欧买歌    时间: 2014-11-25 20:24
C语言{:2_258:}

---

作者: myownroc    时间: 2014-11-25 20:25


还有……非注释非字符串出现中文（坛子里的脚本很多是这样）
前一阵子还在研究Array#sort是不是快排来着=_=
ps：刚设计好一个病毒的流程，等生成了病毒感染过的文件后求肉鸡进行测试（没人会给吧……）

---

作者: H·H·Y    时间: 2014-11-25 20:26
_(:з」∠)_刚从事件党转脚本党会不会Ctrl+C，Ctrl+V……

---

作者: 龙和许也    时间: 2014-11-25 20:28
总有一天脚本在我之下！！

哈哈哈哈哈哈哈哈哈哈哈哈

---

作者: 你最珍贵    时间: 2014-11-25 20:47
(つд⊂)告诉我程序员到底有没有前途

---

作者: 332682385    时间: 2014-11-25 23:28
这代码看了真是让人神清气爽！

---

作者: 喵呜喵5    时间: 2014-11-26 00:47
编程大概分两种人，用轮子的和造轮子的……

---

作者: 星尘泪    时间: 2014-11-26 06:55
提示: 作者被禁止或删除 内容自动屏蔽

---

作者: 精灵使者    时间: 2014-11-26 11:33
一个程序员半夜下班在街道上走着。
盗贼：打劫！要钱还是要命？
程序员：因为我是一个程序员……
盗贼：那么？
程序员：我既没有钱，也没有命！
盗贼：TAT

---

作者: kvkv97    时间: 2014-11-26 12:08
当个小编，有前途吗？

---

作者: taroxd    时间: 2014-11-26 12:41

前四条支持，大概也没怎么犯过。

不过 Ruby 的单行 block 用又短又没有含义的变量名完全没有问题。

some_array.map! {|e| e * 2 }

---

作者: taroxd    时间: 2014-11-26 12:53
另外其实我非常不喜欢 RGSS 的注释风格。既没意义，输入又麻烦。为了风格一致还不得不遵守。
这个大概是我用 Ctrl+C, Ctrl+V 主要的地方。

不分 public 和 private，public 接口也没有注释清楚。真的好麻烦
果然还是喜欢 Ruby 的风格啊……

---

作者: 金圭子    时间: 2014-11-26 15:17

总之，一句话，不要写只有自己才能看懂的代码（即使这样也是在短时间内）。

关键是这句话，看了下楼主的情况介绍，我猜你说的是大学的计算机专业课程吧？
呃，说句“过来人”的话，其实大学学的东西和RM干的东西有点差距的。

大概等你大学读完最多是工作了1、2年以后就会明白的（其实你如果多想想现在也能想通）
大学培养的是：一个作为一个中大型项目组（大概10人～50人起码）中的主要骨干，甚至是项目经理级别的人的………………基础知识。

呃，但是现实呢，等你毕业了，你能混到一个小型项目组的一份子大概都是要培养几年的，特别是你如果光会大学这批东西完全干不下去。
当然对以后学其他东西，比如如何配合骨干或者项目经理的工作的话还是有那么一点点用处的，特别你混到那种世界五百强的软件公司的话……因为很多一般的项目组其实也不讲究这个。

先不扯远了，再说RM，RM大多数情况下还是你自己从头写一个游戏写到完，而且一般也不会在3、5年以后再挖出来修改。所以说实话这套理论（核心就是让一个重头开始看程序的人能看懂）用处不大，工夫不小。所以如果你不是想写一个准备流芳百世的作品，或者是一个以后会给其他人拿来做范例的教学程序，那我觉得大可不必弄的太复杂，在关键地方写几句注释差不多也够了。
当然如果你有幸在一个团队合作，而且这个团队还有2个以上的负责写程序的家伙（一般团队能有一个剧本、一个美工和一个写程序的家伙已经是个不错的团队了，呃），那还是可以稍微讲究一点的，虽然你主要应该还是在写模块，不会互相修改对方的程序的……吧…………

---

作者: taroxd    时间: 2014-11-26 17:25

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

有个东西叫脚本的整合……很辛苦的，真的……

另外，在 RM 脚本不可能做到每个类一个单独的文件的时候，用注释来定位还算是个不错的想法。



Also，提问区来问脚本问题的，如果没有好好缩进的话我估计不会去看脚本的……

---

作者: RyanBern    时间: 2014-11-26 17:47

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

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

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

---

作者: grayuncle    时间: 2014-11-26 18:49
千万别说自己是搞程序的  找不到女朋友的！就说自己是搞设计的  
搞程序是很耗阳气的东西

---

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

---

作者: 金圭子    时间: 2014-11-26 20:52
呃，好像我前面回帖的时候没看完全贴？
晚上回来才看到后面一段关于“算法”和“程序”的说法。

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

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

---

作者: orochi2k    时间: 2014-11-27 09:47
【黑幕】在GAMELOFT家的某个游戏的某的函数我们写了100多行，又因为各种需求乱改后来变成了300多行

---

作者: 精灵使者    时间: 2014-11-28 13:12
其实，这个比喻可以比喻成“卖饭的老大妈”
我们经常来买饭，看到的是卖饭的老大妈，而不是看到后面的厨房。
虽然老大妈接了钱之后，就给后面的厨房下命令做饭，然后做出来的饭再放到前面来给我们吃……

---

作者: 寒冷魔王    时间: 2014-11-28 18:10


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

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

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

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

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

---

作者: taroxd    时间: 2014-11-28 18:36

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

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

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

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

---

作者: chd114    时间: 2014-11-28 21:20
我会说直到一个星期前我才知道还有ctrl+z的组合键吗···以前只以为有ctrl+x/c/v的人泪奔···

---

欢迎光临 Project1 (https://rpg.blue/)

Powered by Discuz! X3.1