深夜2点的编程心得:尽量避免推倒重来

深夜2点的编程心得:尽量避免推倒重来

大家好!此刻深夜2点,我在修改代码的过程中感悟颇深,决定和大家分享一下这段经历。希望你们能从我的故事中找到一些启发,避免犯我所犯的错误。

故事的起因:编写编译器遇到的困境

我正在编写一个自定义语言的编译器,目前已经进行到了parser部分。但因为语义分析的deadline临近,parser部分写得又十分糟糕,我开始感到焦虑。

经过今晚,我有了一个坚定的信念:绝对不重新写代码,一定要设计得非常合理。

翻阅C语言的grammar:重新认识Token

为了解决这个问题,我研究了C语言的grammar,并经过3个小时的阅读,逐渐理解了大概400行的grammar。这个过程让我发现,lexer中的Token分类并不符合主流的方式。比如将Type token之前包括: int float string bool四个类型重新定义为,如今我想拆分为四个小token INT FLOAT, STRING BOOL

的确应该拆分更好,虽然在parser部分已经实现了区分它们的函数。可我修改代码的方式却是推到重来。如今事实证明我是错误的,绘制DFA太费时间,绘制成功后,

冲动的我,竟然想重写lexer!

反思:推倒重来的代价

我开始意识到绘制DFA非常耗时,即使成功绘制出来,我也已经不想用Java重新实现了。因为实现起来虽然不难,但确实太琐碎。

最后的妥协:灵活的代码设计

最后,我回过头来看之前的代码,发现其实还是比较灵活的。在Type类型中定义返回具体Token,这样做的好处是不用合并DFA,而且实现起来很快。虽然如此,当我写到这篇文章时,还是有些后悔,因为修改了Symbol构造函数,也意味着parser部分也需要改动。

成也曹操,败也曹操:

我的成功在于之前的代码设计还算合理,使用了合适的设计模式,改动起来相对方便。但失败在于太过于刻板追求设计模式,以至于居然想重新写它。

我的教训:

实际上,parser写得一团糟的原因是grammar设计得不好,导致代码不断地反复修改。即使使用了不错的实现方法,也抵不过错误的设计带来的损失。

总结:

希望大家能够从我的教训中吸取经验,在写代码之前一定要设计好,最好是定义好测试函数。这种思维方式不仅仅适用于编程,也适用于生活。把如何做人的原则运用到编程中,应该是不会错的。

关键点:

  1. 不要轻易推倒重来:即使你觉得代码写得糟糕,也要尽量避免重新写。尝试从现有代码中发现潜在的优势和可改进之处,然后进行优化。

  2. 设计好再动手:在开始写代码之前,一定要对整体结构和细节有清晰的规划。这样可以避免在后期不断修改,浪费时间和精力。

  3. 测试至上:定义好测试函数,这将有助于验证你的设计是否正确,同时也可以及时发现问题,避免在后期累积过多的问题需要修复。

  4. 把握核心原则:在编程过程中,将生活中的原则运用到实践中,如同在生活中一样,把事情做好,做到极致。

你可能感兴趣的:(代码规范)