命名难，难于上青天

asuka2001

回复 21# OwnWaterloo

我个人感觉这是因为语言缺乏表达力造成的。。。

面向对象是编译器强制要求我们这么去表达我们的思想：我们建立了抽象壁垒，很好的隔离了实现；但是编译器无法理解抽象，它只认实现！只能程序做保姆，把怎么使用这统一的抽象告诉编译器（好吧，继承继承继承），无奈而已！

至于怎么去衡量，怎么折中这是程序员的事！


   

asuka2001

回复 50# AD8018

呵呵其实这也挺好的。保证现在简单，在未来需要时重构下一样可以保持简单。

简单设计原则：）过度的设计只会引入复杂性。真能预料到以后的所有变更，然后做出一版完美的设计的是仙人（好吧，我承认我在吐槽我自己，我就喜欢过度设计，然后反省）


   

asuka2001

回复 68# zylthinking

很赞同。。。要真有一套放之天下皆准的规定，那世界早就大同拉，共产主义早就实现拉，祖国早就河蟹拉!

规则就是为了被打破而设的，区别仅仅在于你是否明白打破规则后的得与失而已！


   

zylthinking

捷径是想岀来的， 而不是别人规定岀来的。 不是谁尊守了什么规矩， 就有远见了。

zylthinking

看大家这么起劲的高谈命名法， 我就丢丢脸吧， 看我怎么命名的， int a::a(int nam){name = nam;}

zylthinking

或 name = name2, name = nm, name = n 之类的也不是没干过。

asuka2001

命名法关键在于希望能够“更”加清晰的表达自己的思想，让代码可读性“更”高，这就消耗脑细胞了，哎！

当然这又是个仁者见仁智者见智的问题了，如果已经比较清晰了还纠结，那也仅仅是满足自己的心理洁僻而已。

现实世界从来就不是二分法能说得清楚的，也许妥协折中才是我们最该具有的素质？

walleeee

回复 39# 三月廿七


    这个问题我们前面不是讨论过类似的么？现在我倾向提供get/set这种函数来访问而不直接访问。

对于命名的问题，我以前也苦于这个，后来我倾向于在成员名字前面加_，多击键2次，比如_avar这种，主要是受了py的影响。而且也不需要键入太多字符影响编码速度，如果用mfc里面提倡的那种m_avar就需要击键3次（多一个m）。

walleeee

回复 75# zylthinking


   

walleeee

回复 73# asuka2001


    其实“一致”才是关键，其实就有限的几行代码，随便用那个都不错，如果面对代码太多，一致就直接决定代码可理解性（非可读性）