【背景】
很多人，在开发软件期间，有很多不好的行为。
之前一直想去总结和提醒了。
一直没去写帖子。
后来的下面这个例子，很好的说明了该问题。
所以整理过来。
举例说明：软件开发中，好的习惯，很重要
举例：
中的问题：
由于标准库的urllib/urllib2比较弱，所以安装了requests开源库。 |
我的解释：
从你的： def get(url)
print "in get, url=",url然后： 此时： 再去把你的： /Users/Eric/Desktop/requests.py 改名，比如改为： /Users/Eric/Desktop/requestsTest.py 再去运行，则肯定就可以了。 另外： 不论此处错误的原因是否是我上面的推测的原因 你此处的： /Users/Eric/Desktop/requests.py 中都不是好的做法，即： 打算去测试某个模块，结果python文件名: requests.py 却起成和模块名同样的名字： requests 这样的做法，本身就是不推荐的， 甚至可以说是：很不好的习惯 所以，建议： 无论是否是此原因出错 今后，做类似的事情之前， 都尽量要有个更好的习惯 这样，不论是写代码，还是做其他事情， 最终都会让你自己体会到：使得做事情的效率更高，效果更好。 |
什么叫好的习惯，什么叫坏的习惯，坏习惯又有何坏处？
先说坏的习惯：
以上面为例：
对于一个模块去做测试，而该模块叫做：requests
坏的习惯是：
随手，就起了个名字，比如
test.py
demo.py
a.py
坏的习惯，有何坏处，有何缺点？
而作为：
你，过了很长时间之后，再回来看你这个代码
或者是别人来看你的代码
对于
test.py
demo.py
a.py
子类的名字，就根本不知道其是干啥的，不知道该程序的目的是什么。
什么是好的习惯？
而如果像之前已经提到的，正确的做法：
既然是去测试一个叫做requests的模块，
那么最好就把对应的文件名，起成你所要实现的目的：
测试request模块
对应的，转换成，有意义的，有价值的，见名知意的，文件名，就可以写出：
- 文件的驼峰命名法：
- demoRequests.py
- testRequests.py
- 或：
- requestsDemo.py
- requestsTest.py
- 对应的，Linux下划线的写法可以写为：
- demo_requests.py
- test_requests.py
- 或：
- requests_demo.py
- requests_test.py
当然，如果你想要，从文件名本身，就区分出对应的版本，也可以加上对应的版本信息：
- 用日期表示的版本：
- demoRequests_20131012.py
- testRequests_20131012.py
- 或：
- requestsDemo_20131012.py
- requestsTest_20131012.p
- 用主次版本号表示的形式：
- demoRequests_v1.0.py
- testRequests_v1.0.py
- 或：
- requestsDemo_v1.0.py
- requestsTest_v1.0.py
对好的习惯的质疑
估计会有很多人会说：
你不就写个测试代码，给测试代码的文件起个名字嘛，
有必要搞得这么复杂吗
搞得单独给文件起名字，都多"浪费"了好几秒。。。
对此，我的回答，解释是：
- 等你项目代码多了
- 不同版本的代码多了
- 等你之后很长时间之后再回来看自己的代码时
- 等你把你的代码给别人看的时候
- 等你（由于某些原因，比如发现之前某个班版本的代码工作，现在代码不工作）想要再去找你测试的某个版本的代码
- 。。。
你就会发现：
如此的，多浪费个几秒，起个更，见名知意，有含义的文件名时
后续对于整体事情的效率的提升
对于你后续搞清楚问题：
- 这个测试代码是哪个项目的？去为了搞清楚当前的这个文件是干啥的
- 在一堆的杂乱的文件中，到底你所要找的文件是哪个
- 自己之前写的这行代码，是啥意思？（后缀当初没有加注释，文件名没有写个更清楚的）
- 自己代码出了问题，需要找别人寻求帮助，但是文件很乱，代码很乱，搞得别人一头雾水，无法及时帮你解决问题
所花的时间，绝对属于：
小巫见大巫
换句话说：
往往是你之前，浪费了那几秒去：
- 文件命名都尽量做到见名知意
- 代码变量命名也尽量做到见名知意
- 代码有基本的，合理的注释
- 等等。。。。
时，而使得后续出现其他问题时，
由于文件名，变量名，代码注释等都很合理，所以相对来说，解决问题的时间大大缩短
反正是应了那句：
出来混，迟早要还的
刚开始做事情（给文件命名，给变量起名，给代码注释等等），偷懒，不严谨，
之后，不是容易出现之类问题，就是出现那些问题
完事都是反面：坏习惯，当然也有坏习惯的好处
当然，凡事都是其对立面
即使是此处的坏的习惯，也有其好处：
此处就是：
由于程序，没有像期望的那样正常运行，
却出现，本以为很奇怪的错误
而使得：
别人和自己，花精力解决问题，
最终，学习到，有错误相关的知识
此处就是：
对于Python在搜索路径（的顺序和逻辑）方面的知识，有了，深刻，切身的体会
（当你是其他阶段遇到，更严重的问题，那就是，大家所（喜闻乐见（的别人的））的血泪教训了,^_^）
如何才能养成好的习惯？
遵循，我之前见到过别人所总结的，一个规律：
第一次做事情，就做对：不要第一次把事情做得，所谓的差不多，然后再来优化，再来修改
即：
事情要么不做，要做，就尽量一次性做好
在做软件开发时，有哪些需要注意的，好的习惯？
很多。
尤其是开发软件，软件代码风格方面。
其中涉及很多方面，涉及很多概念，比如文件命名，版本命名，变量命名，代码注释，代码缩进，等等等等；
对于此方面的总结，其实也算是，概念很多，也是不同语言，可能有不同约定和规则。
这部分内容，网上已有别人的部分总结。
比如：
C语言的：
另外，我抽空会自己去整理相关的知识的。
最终目标是：
多种语言都整理出来
多种相关的习惯，概念
等等。
除了和习惯相关的，也常涉及到：基础知识
即开发某种东西，会需要有相关的背景知识
比如此处上面的例子，
如果本身对于
库文件搜索路径
这个概念，没有任何经验，
那么，也是想不到，可能会是Python中库文件搜索路径，搜索库的逻辑，方面的错误，
从而就很难找到错误。
以后，会陆续整理出来的。
目前，已经整理出来的，基础开发知识，有：
总结
1. 把（任何）事情做好，不（仅仅）是为了方便别人，（往往）是方便（后来的）自己
2.出来混迟早要还的：之前（在开发期间，写代码期间）犯下的（bug，孽债），（后来）早晚都会还的（去解更大的bug，去解自己挖的坑）
3.做事情，尤其是软件开发，的确是要对于其所涉及的相关背景知识有一定掌握，才能真正理解程序的含义，出错的原因的
- 只能靠自己慢慢学习和积累
- 如果有好的导师，那可以帮你少走很多弯路
- 拼人品，运气好，或许能遇到好老师
- 如果有好的，能解释的清楚概念的教程，那也很好
- 好的教程，也是我的目标：我正在慢慢写，暂时写了一些，不多，但以后会慢慢丰富的
转载请注明：在路上 » 【软件开发基础】好的习惯很重要