|
其实很早以前,在看 何宗斌 的 8位机开发和编程规范 那本书 知道了 pc-lint和misrac以后。 我就一直想试图使用这些 经典的 检查工具。
然而pc-lint曾有过一阵子想安装,无奈当时实在看得一头雾水,也没有现在足够的耐心。所以一直没玩通。
这几天在折腾 工具链。 最终觉得gnu下实现似乎有点困难,而且gnu的器件支持列表也让我对此不再具有足够的 动力。
于是我转而开始另一种更现实的做法。
我在使用的ide中集成进这些工具。 它们有的有带这个工具的专用接口,集成起来相对简单,我只要安装好这个工具,放在特定路径下,立马就能使用。
而有的就没有,它们大概是提供了一个通用工具接口,以方便我们集成更多不同种类的工具,但是这却加大了集成难度。 比如昨天我花了一天多时间才把pc-lint集成到vc6下,而且使用起来还并不是我很满意的方式。 不知为什么,它总是要把信息打印到终端上,而不是ide中的输出窗口。
今天上班,我几乎没费太大的劲,就把pc-lint集成进我工作的ide里,理由是,它提供了这个专门给pc-lint使用的接口——它写好了命令——而我对此最是陌生,最是不懂。
但是我自己使用的iar for stm8,显然也是vc6的方式,提供的是通用接口。 看来我还得费不少劲。
这段时间因为折腾gcc和这些工具链,三四天里,我没有更新代码大全的笔记——因为根本没看,也没有 更新基于stm8s的 通用程序框架,因为没写。 玩了一阵子以后,我开始回到正途。
所以,现在我工作的项目可以开始使用来自pc-lint的建议去修改和优化——至少是从静态检查上去实现。至于更高级的动态分析和质量分析恐怕这个项目轮不上了。
而我的 通用程序框架。我希望它从一开始就能用上—— 今天我在查看pc-lint的结果时 发现很多错误都是集群出现,往往是一个错误不断重复犯。而这些往往源自一个相同的原因 所以我有理由相信,在编码的过程中间隔性多次使用 pc-lint检查,不仅有助于在更早的时间里完善和优化,更能降低修改成本—— 你改过了几次的错误,也许你不会再犯,而不至于到了最后,你对着这些不断重复的错误傻傻的发呆。
所以。在接下来继续开始 通用程序框架 的编写之前,我会努力把pc-lint集成到iar里。 同时,在实际修改错误中学习pc-lint的内容本身。 让自己在实际修改中熟悉和了解pc-lint。
写出更好的代码,一直以来都是我的梦想。 让它们更稳定,更高效。
|
|