反对解析克苏鲁方式的论点是什么?
我的任务是为一种可能对公司非常重要的工具实现领域特定的语言。该语言很简单,但并非无关紧要,它已经允许嵌套循环,字符串连接等,并且实际上可以确定,随着项目的进行,还会添加其他构造。 我从经验中知道,除非语法很琐碎,否则手工编写词法分析器/解析器是一个耗时且容易出错的过程。因此,我有两个选择:解析器生成器y yacc或组合器库(如Parsec)。前者也很好,但是我出于各种原因选择了后者,并以功能语言实现了该解决方案。 结果在我看来非常壮观,代码非常简洁,优雅,可读/流利。我承认,如果您从未使用Java / c#以外的任何程序进行编程,它可能看起来有些怪异,但是对于未使用Java / c#编写的任何内容,这都是正确的。 但是在某个时候,我确实遭到了同事的攻击。快速浏览一下我的屏幕后,他宣布代码令人难以理解,并且我不应该重新发明解析方法,而应该像所有人一样使用堆栈和String.Split。他大声喧noise,我无法说服他,部分是因为我感到惊讶,没有明确的解释,部分是因为他的观点是不变的(没有双关语)。我什至提出要给他解释语言,但无济于事。 我很肯定讨论将再次出现在管理层面前,因此我正在准备一些扎实的论据。 这些是我想到避免基于String.Split的解决方案的前几个原因: 您需要大量的if来处理特殊情况,而事情很快就会失控 大量的硬编码数组索引使维护工作陷入困境 很难处理像函数调用那样的方法参数(例如add((add a,b),c) 如果出现语法错误,很难提供有意义的错误消息(极有可能发生) 我全都是为了简单,清楚和避免不必要的智能加密,但我也认为,精简代码库的每个部分以使汉堡包都可以理解它是一个错误。我听到的是相同的论点,即不使用接口,不采用关注点分离,在周围粘贴粘贴代码等。毕竟,在软件项目上需要最低的技术能力和学习意愿。(我不会使用这个论点,因为它可能听起来令人反感,发动战争不会帮助任何人) 您最喜欢反对解析克苏鲁方式的论点是什么?* *当然,如果您能说服我说他是对的,我也会很高兴