《软件随想录》的随想

      这是一本很有趣的书,让我经常在公车上傻笑,不枉推荐人的强力推荐+免费送货上门。       学到一些东西,比如要装B应该找些比设计模式复杂的东西。他选择的是递归函数论。以前有句古话:五十步笑百步。在现代社会可以改成八十步笑五十步兼笑百步。他在书中一边抨击java、设计模式太简单,不能体现智力差别;一边说动态数理逻辑不够实用,不能用来实现真正有用的东西,所以他不读计算机科学的研究生。嗯。他觉得合适的点是递归函数论,我一直以小人之心腹诽那是因为他正好学过而且学得不错。怎么办呢?我们学校没教过递归函数论。不过我学过自动机与可计算理论,而且学得很好,成绩高达95大分。以后不跟人说设计模式了,言必及自动机。设计模式? too naive,让我们来聊聊可计算理论吧。       很多观点我同意他的,或者说我只能同意他的,因为我没开过公司卖过软件,项目管理也很山寨。但此书有两个观点我是严重不同意的。       第一,关于匈牙利命名法。他说那是合理的,是大家误会了匈牙利命名法的本意。也许匈牙利命名法的本意的确是标志kind而不是傻乎乎的type。但类比一下,现在大家都默认臭指代不好的气味,虽然在太古时代臭的意思是中性词:味道,但是现在会有人说这股臭真好闻吗?所以带type匈牙利命名法被打倒了就别翻黄历想翻案。在变量名中带kind还是有一定道理的。尤其是要表述的意思太长的时候,width和height比 wFoo和hFoo孰优孰劣一目了然。但如果要表示的是点的数目, pixelCntInWidth 就略显啰嗦了,pcWidth和pcHeight将更简明。规则的适应需要时间,但适应后应该可以提高编程效率——如果软件很多地方需要用到“pixel 数”这个概念的话。上面这个例子也说明kind和 type的区别,如果是带type的匈牙利命名法,iWidth和iHeight?或者iPixelCntInWidth和 iPixelCntInHeight?这个变量是啥类型只要鼠标移过去不就清楚了吗?除了折腾程序员几乎毫无用处。所以当年程序员暴动反抗傻不隆冬的带type匈牙利命名法毫不奇怪。       第二,关于异常。他对异常有偏见并且举的例子也很烂。我也不浪费时间分析了。
相关文章
相关标签/搜索