如何本地化 Mathematica 中的语法错误？
有没有本地化语法错误的技巧？我在编辑现有代码时偶尔会遇到这种情况。这是一个最新的例子，您是否看到了找到错误的有效方法？ （我已经发现了错误，但效率不高）
Is there a trick to localize syntax errors? I occasionally run into this situation when editing existing code. Here's a latest example, do you see an efficient way to find the error? (I found the error already, but not efficiently)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
可能是，我遗漏了一些东西，但在你的示例中，这很简单：一旦我将你的代码放入笔记本并尝试运行，通常的橙色括号就会出现，当你展开消息时，它非常清楚地表明问题位于
vertexFormula函数中的空括号中。根据我的经验，大多数时候，橙色框给出了足够的提示。我每天使用的另一个好方法是通过工作台中的代码突出显示。它会立即突出显示语法错误，而且您还可以为单个包和多个包提供非常强大的基于 Eclipse 的导航。从交互式前端开发转到工作台似乎会失去一些灵活性，但我发现了相反的情况（或者这可能是我的企业 Java 背景的报复）：您仍然可以将笔记本放在工作台中项目，您可以在其中进行初始开发，但随后它们会附加到项目以及您已经开发和使用的许多包中。从笔记本到包的转换再简单不过了，因为在将代码转移到包中后，您可以继续使用该笔记本，甚至不必担心加载包，只要执行一次即可在一个项目内部。总的来说，我发现一旦你的项目超过了一定的临界质量（我想说，也许大约 1000 loc，但是 ymmv），基于工作台的开发就会变得更有趣。但是，对于完整的新的独立功能块，我仍然更喜欢完全在前端进行原型设计。
如果您在代码中遵守某些特定的编码标准，或者使用符合这些标准的代码，您也许能够开发一些简单的部分解析器，它至少将代码分解为完整的块（函数定义、模块等、复合表达式）。然后，您可以使用 ToExpression（例如，将其映射到部分解析器返回的字符串代码块列表上）来查看哪一段代码有问题（它将返回 $Failed ）。但如果您使用 Workbench，则完全没有必要。
May be, I am missing something, but in your example it was quite easy: once I put your code into a notebook and tried to run, the usual orange bracket appeared, and when you expand the messages, it states very clearly that the problem was in an empty parentheses in your
vertexFormulafunction. In my experience, most of the time, the orange box gives enough hints.Another great way which I use on a daily basis it through the code highlighting in Workbench. It immediately highlights syntax errors, plus you have a very powerful Eclipse-based navigation both for a single package and multiple packages. It might seem as you lose some flexibility by going to Workbench from an interactive FrontEnd development, but I found the opposite (or may be this is the revenge of my enterprise Java background): you still can have your notebook(s) in a Workbench project, where you do the initial development, but then they get attached to the project and a number of packages that you already developed and use. The transition from notebook to a package could not be easier, since you can continue use that notebook after you transfer the code into a package, and you don't even have to worry about loading the package, as long as you do it just once inside a project. Overall, I find the Workbench - based development much more fun as soon as your project goes over some critical mass (I'd say, perhaps around 1000 loc, but ymmv). But, complete new and independent chunks of functionality I still prefer to prototype entirely in the FrontEnd.
If you adhere to some specific coding standards in your code, or work with code which does, you might be able to develop some simple partial parser which at least breaks the code into complete chunks (function defenitions, Module-s etc, CompoundExpressions). Then, you could use ToExpression (say, Map it on a list of string code chunks returned by your partial parser), to see which piece of code is problematic (it will return $Failed on it). But if you use Workbench, this is unnecessary altogether.