命名方式

[夏天的鼻涕怪]

各位，你们喜欢哪种命名方式：
①Myfunction()
②myfunction()
③myFunction()
④my_function()
⑤my_funct()

[赵4老师]

请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。

意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。

试对比
图书馆（对图书的分类够结构化了吧）
和
搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索）
哪个处理信息更方便、更高效。

所以
与其费劲去重构代码让其看上去更简洁、更合理
不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。

结构越复杂，越难修改，越难除错。
有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。

程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George

前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题：
◆“要保证这个问题不会再出现，我该怎么做？”
◆“要想少出些Bug，我该怎么做？”
◆“要保证Bug容易被修复，我该怎么做？”
◆“要保持对变化的快速响应，我该怎么做？”
◆“要保证我的软件的运行速度，我该怎么做？”
如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。

[AlbertS]

基本上用过1,3,4
写代码时看周围环境，融入周围的代码中

[Votangroom]

4 5 如果5的简洁能让 我更顺眼的话会选择5

[日立奔腾浪潮微软松下联想]

MyFunction、my_func...

[ooolinux]

MyFunction（驼峰）
myFunction（Qt）

[smwhotjay]

my_funct c++ 全小写

[划过星空20216]

3和4 这两个是我比较常用的

[赵4老师]

比用什么风格更重要的是在任何地方，任何时候都坚持用一种风格。
比爱哪种美眉更重要的是在任何地方，任何时候都坚持爱一个美眉。

[走好每一步]

驼峰好用，匈牙利比较坑爹了，已经被主流抛弃了。
1、3

[ForestDB]

1和2是典型的异类，我同事这样写我是会叫的；
3和4是标准的命名法；3是标准的骆驼，常见于OO语言，比如Python；4是标准的UNIX/Linux风格；
如果你是UNIX/Linux大牛，你可以考虑5。