<!doctype html>博客.md
WordCounter Python实现
GitHub地址
项目相关要求
wc.exe 是一个常见的工具,它能统计文本文件的字符数、单词数和行数。这个项目要求写一个命令行程序,模仿已有wc.exe 的功能,并加以扩充,给出某程序设计语言源文件的字符数、单词数和行数。
实现一个统计程序,它能正确统计程序文件中的字符数、单词数、行数,以及还具备其他扩展功能,并能够快速地处理多个文件。 具体功能要求: 程序处理用户需求的模式为:
wc.exe [parameter][file_name]
基本功能列表:
wc.exe -c file.c
//返回文件file.c 的字符数
wc.exe -w file.c
//返回文件file.c 的词的数目
wc.exe -l file.c
//返回文件file.c 的行数
扩展功能: -s 递归处理目录下符合条件的文件。 -a 返回更复杂的数据(代码行 / 空行 / 注释行)。
空行:本行全部是空格或格式控制字符,如果包括代码,则只有不超过一个可显示的字符,例如“{”。
代码行:本行包括多于一个字符的代码。
注释行:本行不是代码行,并且本行包括注释。一个有趣的例子是有些程序员会在单字符后面加注释:
} //注释 在这种情况下,这一行属于注释行。
[file_name]
: 文件或目录名,可以处理一般通配符。
高级功能:
-x 参数。这个参数单独使用。如果命令行有这个参数,则程序会显示图形界面,用户可以通过界面选取单个文件,程序就会显示文件的字符数、行数等全部统计信息。
需求举例: wc.exe -s -a *.c
返回当前目录及子目录中所有*.c 文件的代码行数、空行数、注释行数。
遇到的困难及解决方法
困难描述:
在做扩展功能的时候发现新添加的函数不能很好地和之前的架构相适应。
做过哪些尝试:
对已有架构进行重新改进,讲原本是以函数为主,对文件进行递归处理的架构改为以文件为主,对函数进行递归处理。
是否解决:
得到解决。
有何收获:
编写程序的时候还是要讲究一个大局观,不能局限于当前的功能的实现。所写的程序要有可扩展性,不然会对后期的编程造成巨大影响,甚至要重构。
关键代码or设计说明
关键代码:
1 def set_func(self, option): 2 for opt, arg in option: 3 if opt in ('-x'): 4 w = WC_GUI.Window() 5 break 6 if opt in ('-s'): 7 pass 8 if opt in ('-c'): 9 self.func_list.append('get_font_num(file)') 10 if opt in ('-w'): 11 self.func_list.append('get_word_num(file)') 12 if opt in ('-l'): 13 self.func_list.append('get_line_num(file)') 14 if opt in ('-a'): 15 self.func_list.append('Expansion_a.get_special_num(file)') 16 17 def count(self): 18 for file in self.File_path: 19 print(file) 20 for func in self.func_list: 21 exec(func)
说明:
set_func()
函数根据所输入的参数指令,将相关的函数以序列化的形式写入self.func_list
中,然后在文件列表self.File_path
中递归获取文件路径作为当前文件路径,根据当前文件路径,利用exec()
函数将self.func_list
中的函数执行,以达到以文件为主,对函数进行递归处理的效果。
PSP
PSP | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 120 | 60 |
· Estimate | · 估计这个任务需要多少时间 | 60 | 60 |
Development | 开发 | 60*24 | 60*24 |
· Analysis | · 需求分析 (包括学习新技术) | 60*8 | 60*8 |
· Design Spec | · 生成设计文档 | 120 | 60 |
· Design Review | · 设计复审 (和同事审核设计文档) | 120 | 60 |
· Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 60 | 60 |
· Design | · 具体设计 | 120 | 60*4 |
· Coding | · 具体编码 | 60*5 | 60*8 |
· Code Review | · 代码复审 | 60*2 | 60 |
· Test | · 测试(自我测试,修改代码,提交修改) | 60*5 | 60*5 |
Reporting | 报告 | 60*4 | 60*2 |
· Test Report | · 测试报告 | 60*2 | 60*2 |
· Size Measurement | · 计算工作量 | 60 | 60 |
· Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 60*3 | 60 |
合计 | 60*59 | 60*61 |
解题思路
刚拿到题目的时候,这个项目给我的第一直观感觉就是,他的核心功能是”统计“,分下来有很多个选项,统计字数,词数,行数等等。那么我可以将程序看作:获取要函数控制参数——核心函数的分发——计算结果的输出。这一流程,也就是所谓的架构。
而统计字数、词数等的功能可以以模块的形式被主函数调用,以达到模块化编程的效果。这样做的好处是只要架构不需要修改的前提下,能够很方便地对函数功能进行扩充。
设计实现过程
主要的文件有两个,一个是WordCounter.py
,另一个是WC_GUI.py
函数。前者是在名行模式下的主题函数,负责根据输入参数设置所需要调用的函数,并返回所得值。后者是图形化界面的主要函数文件,功能与前者相似。
其余的Base_Function.py
、Expansion_a.py
、Expansion_s.py
分别为基本模块,扩展模块a
参数,扩展模块s
参数的函数文件。
测试运行
单个文件选择
目录递归
图形化界面
空文件
一个字符文件
一个单词文件
一行文件
项目小结
这次是我第一次编写具有图形化界面的python程序,在实现图形化的过程中我遇到的很多困难,比如说图形化的排版问题,多选框的选择,其中的一些特征变量的使用,图形化界面调用原始函数等等的功能。经历过多次失败的尝试,原本已经放弃实现图形化的功能了。但是这个失败的图形化代码总是纠结在心头,最后还是“忍不住”再再再尝试,也就的道理这个完整的最终版。这是一件令人开心的事情,也多亏了自己的纠结,最终没有放弃这个功能。