最近在看公司源代码的时候,经常有一些超长函数出现,甚至超过 1000 多行的函数都大有存在,这大大影响我对代码的理解,所以写下此文,当然只是自己的想法,不强加于人,只为勉励自己。
在以往的软件开发中,对于函数我也是想写多长就写多长,从来不去想它有多长这个“无聊的问题”,因为对于一个函数应该写多长并没有一个确切的定义,这应该看具体情况决定。
我个人觉得,无论是类还是函数,都应该满足单一职责原则,如果出现一个函数过长或者代码块嵌套过深的情况,常常是因为没有满足这一原则,这两种情况都能够通过更好的重构来解决。
以我工作中的一个代码片段为例来看一下,函数写多长,如何拆分函数。


1


2

3

4

5



6

7

8

9



10

11

12

13


14

15

16

17



18


19

20

21

22

23



24

25

26



27

28



29

30

31



32

33

34



35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53


54

55

56



57

58

59

60

61

62

63

64

65

66

67

68


69

70

71



72

73

74

75

76

77


78

79



80

81

82

83

84

85

86

87

88



89

90

91

92

这是一个窗体的加载事件,运行过程是这样,首先从系统模板配置文件中找到实时模板类型信息,然后验证该信息中指定的模板类型文件是否存在,如果存在的话把
XML
文件中的实时模板信息加载到对象列表中,然后通过该模板类型列表得到一个绑定下拉框的数据源对象列表,用来绑定下拉框。
上面函数中算很长的了,函数过长的一个原因是因为临时变量,因为临时变量只有在所属函数中才能使用,所以它会驱使你写出更长的函数,所以我们在开发过程中尽量少用或不用临时变量(可以使用一些重构准则实现)。函数过长的另一个原因是它承担了过多的职责,上面函数承担了多项职责:加载
XML
文件来获取模板信息对象列表;加载数据源对象列表;绑定模板下拉框等,我们首先把这三个职责抽取出来,分别用一个专职的函数来实现。


1


2

3

4

5



6


7


8

9

10

11

12

13

14



15

16

17

18


19

20

21

22



23


24

25

26

27

28



29

30



31

32



33

34



35

36

37



38

39

40


41

42

43



44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60



61

62

63

64

65


66

67

68

69

70



71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86


87

88

89

90

91



92

93



94

95

96

97

98

99

100

101


102

103

104

105



106

107

108

109



110

111

112

113

114

115

116

通过上面的重构过程,加载事件看起来容易理解一点,但是对于
XML
文件的处理过程还是很复杂,另外,我们在此类中处理模板下拉框并显示实时模板数据的,而处理
XML
的职责也写在了此类中,所以此类也可以抽取出来,放在一个单独的类中,用来专门处理
XML
模板信息配置文件,最后处理结果如下:


1


2

3

4

5



6


7

8

9

10

11


12

13

14

15

16


17

18

19

20

21



22

23

24

25

26


27


28

29

30

31

32



33

34

35

36


37

38

39

40

41



42

43

44

45

46


47


48

49

50

51

52



53

54

55

56



57

58



59

60



61

62

63

64



65

66

67

68

69

70

71

72

73

74


75

76

77

78

79

80



81

82

83

84


85

86

87

88

89



90

91

92

93


94

95

96

97

98



99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116


117

118

119

120



121


122


123

124

125

126

127

128

129



130

131

132

133


134

135

136

137



138

139

140

141

142

143

144



145

146

147

148

149


150

151

152

153

154



155

156

157

158



159

160

161

162

163

164

165

166


167

168

169

170

171



172

173



174

175

176

177

178

179

180

当我们遇到过长的函数或者需要注释才能让人理解的代码块的时候,就应该考虑可不可以使用重构提取函数,不用管函数有多长,哪声只有一句,只要可以强化代码的清晰度,那就去做。就算提取出来的函数名称比函数体还长也无所谓。
过长的函数和嵌套过深的代码块(比如 if 、 for 、 while 和 try 代码块)是使函数更难于理解和维护的密不可分的两大元凶(而且经常毫无必要)。
我们不必担心函数拆分过多的问题,函数调用的开销可以忽略不计,使用小函数有以下几个好处:
1 如果每个函数的粒度都很小,那么函数之间彼此复用的机会就更大;
2 使得高层代码读起来就像是一系列注释;
3 如果函数都很小,那么函数的覆写就比较容易;
在命名函数的时候,每个函数都应该是顾其名而能思其义,我们应该以它“做什么”来命名,而不是以它“怎么做”命名,只有在你可以给小函数很好地命名时,它们才能真正起作用。
更多文章、技术交流、商务合作、联系博主
微信扫码或搜索:z360901061

微信扫一扫加我为好友
QQ号联系: 360901061
您的支持是博主写作最大的动力,如果您喜欢我的文章,感觉我的文章对您有帮助,请用微信扫描下面二维码支持博主2元、5元、10元、20元等您想捐的金额吧,狠狠点击下面给点支持吧,站长非常感激您!手机微信长按不能支付解决办法:请将微信支付二维码保存到相册,切换到微信,然后点击微信右上角扫一扫功能,选择支付二维码完成支付。
【本文对您有帮助就好】元
