数学之美读后感&代码规范的思考
笔者尚未将数学之美读完，故此处写下印象最深刻的几处。
甫一打开这本书的pdf，在眼中出现地最密集的便是“熵”字。熵的概念在第一章多个分目录中出现过，在1.4中出现了信息熵——一个由香农提出用于对信息的量化度量的概念。文中举的例子贴近生活，是我最关注的足球问题，另外也提到了汉字的使用问题。其鲜明地指出了度量信息量应考虑在大量数据下每个数据出现概率不等的情况，信息量在归类优化后的重新计算也会出现一个不同的结果，信息也存在着冗余的情况；另一个熵的概念出现于1.17处所提出的最大熵模型，其提到了利用最大熵模型诸多成功案例，如google的机器翻译等，但自己的模型是否是最大熵模型，这个问题的答案是模糊的。学者们将自己的模型当作最大熵模型，但真正能做到的寥寥无几，最后反而更像是在打补丁。故找最大熵，优化算法是一个漫长的探索过程，成果固然诱人，能将复杂问题简化是所有人的梦想，但真要实行属实不易。
另一个感触是数学之美，其美在于化繁为简。1.15中布莱尔即持该种观点，他着眼于“去粗取精”，挑出有用的，删除无用的，直至找不到无用的为止。看似简单笨拙的方法，布莱尔却用其在自然语言处理领域取得了大成功，他也成为了微软搜索研究的领军人物之一。而1.6又向我们展示了网络设计和程序设计技术的重要性了，同样是化繁为简，举出的例子也令人震撼：索引200亿个网页需要634年，是一个漫长的时间，这便迫切需要数学发挥作用，来建立这样一个这么大的网络系统了。
数学之精之妙，无愧为解决信息检索和自然处理的最好工具。
另一方面谈谈关于代码规范问题。
代码是这个专业的人每天离不开的名词。算法有优化解，代码故也有整理令其美观一说。
首先明确一个观点，代码虽然是写给机器运行的，但同时也是写给人看的，看的人通常也不仅仅只有你一个，下面谈谈什么是漂亮的代码。
其一是命名的规范问题。命名应能望文知意，通常来说，还需要在旁边解释所命名的变量的具体含义，那么这样的代码便不算成功。选择好的名称需要花费时间，但这时间远比以后维护代码时用于弄懂自己命名的是什么东西短。
其二是函数的专一使用，函数不应过大来嵌套别的结构，缩进不应大于一个或两个，且同一个函数中若混合不同层次的抽象，一方面不利于管理函数，另一方面会令人疑惑。一个函数应实现其功能的最大化，且是专一功能专一使用，如此才能做到高效而美观。
其三是参数问题，参数越多，组合输入的情况也就越多，测试一多便容易出问题，通常来说你能一眼看出返回值，但输出参数相比于返回值更难以理解，且非常不直观，违背了代码易懂的原则。
其他琐碎的问题诸如括号的位置，每一行代码中空格的使用（如int a = 1这样等号两边的空格）等等，虽然相比之下是小问题，但细节决定成败，每一处能优化的都尽量实现才是我们的目标。
文末有感：程序员是受害者，但很多时候更是加害者，代码的规范问题是时候该提上日程了！