434
社区成员
发帖
与我相关
我的任务
分享谈《数学之美》之图论和网络爬虫。
在离散数学以及数据结构的课程中,我们学习过图论相关课程,其中图的遍历就是十分典型和具有代表性的应用。曾经,我们想到图,回应到的往往是实际生活中的交通道路,蕴含了纯粹的图的思想。而在《数学之美》中,他讲到图在计算机的应用之一是网络。“互联网其实就是一张大图,我们可以把每一个网页当作一个节点,把那些超链接(Hyperlinks)当作连接网页的弧。”初读这句话,让人醍醐灌顶,联想到的是“维基百科六度分隔理论”,相互链接的维基百科词条用一个链条(至多包含6个主题,包括原来的两个主题)连接起来。而在《数学之美》中,还提供了一个最朴素的基本想法,就是从一个出发,建立“哈希表”查重,从而像蜘蛛结网一样,将网页数据悉数获得,令我大受震撼,如同浩瀚星空,需要点点相衬,才能构成一张包裹的“网”
关于命名长度,在能够表达含义的额情况下,命名当然是越短越好。在大多数的情况下,短的命名不如长的命名更能表达含义,很多书籍是不推荐使用缩写的。
使用短命名
1.1.1、对于一些默认,大家都熟知的倒是可以使用缩写的命名
1.1.2、对于作用域比较小的变量,我们可以使用相对短的命名
指的是不要用一些特别生僻、难发音的英文单词来命名。
对于接口的命名,一般有两种比较常见的方式。一种是加前缀“I”,表示一个Interface。比如IUserService,对应的实现命名为UserService。另一种是不加前缀,比如UserService,对应的实现加后缀“Impl”,比如UserServiceImpl。
命名再好,毕竟有长度限制,不可能足够详尽,而这个时候,需要注释就来补充。
我们写数注释的目的是让代码更易懂,注释一般包括三个方面,做什么、为什么、怎么做。
对于逻辑比较复杂的代码或者比较长的函数,如果不好提炼、不好拆分成小的函数调用,那我们可以借助总结性的注释来让代码结构更清晰、更有条理。
注释本身有一定的维护成本,所以并非越多越好。结构体和函数一定要写注释,而且要写得尽可能全面、详细,而函数内部的注释要相对少一些,一般都是靠好的命名、提炼函数、解释性变量、总结性注释来提高代码可读性。
是不要超过一个显示屏的垂直高度,最大代码行数不能超过50。
一行代码最长不能超过IDE显示的宽度。
一个小模块的内容完了,通过空白空格进行分割。