这是我的界面，所以叫我...maybe

Question

我正在检查VBA代码以查找过时的代码构造--即显式Call语句，如下所示：

呼叫DoSomething(42)

“正确”的代码构造是省略Call令牌并删除括号--我的代码定位过时的Call语句，并像这样重写它们：

DoSomething 42

我有一个IdentifierReference类，用于在我解析的整个VBA代码中存储各种标识符引用的上下文。为了让我的代码检查能够轻松地找到使用过时的Call语法的方法调用，我将这个方法添加到IdentifierReference类中：

public bool HasExplicitCallStatement()
{
    try
    {
        var call = ((dynamic)Context.Parent).CALL();
        return call != null && call.Symbol.Text == Tokens.Call;
    }
    catch (Exception)
    {
        return false;
    }
}

但是我不喜欢在这里处理异常，所以我用更强类型的方式重写了它，如下所示：

public bool HasExplicitCallStatement()
{
    var memberProcedureCall = Context.Parent as VBAParser.ECS_MemberProcedureCallContext;
    var procedureCall = Context.Parent as VBAParser.ECS_ProcedureCallContext;

    return HasExplicitCallStatement(memberProcedureCall) 
        || HasExplicitCallStatement(procedureCall);
}

private bool HasExplicitCallStatement(VBAParser.ECS_MemberProcedureCallContext context)
{
    if (context == null)
    {
        return false;
    }
    var statement = context.CALL();
    return statement != null && statement.Symbol.Text == Tokens.Call;
}

private bool HasExplicitCallStatement(VBAParser.ECS_ProcedureCallContext context)
{
    if (context == null)
    {
        return false;
    }
    var statement = context.CALL();
    return statement != null && statement.Symbol.Text == Tokens.Call;
}

现在我想知道..。这真的是一个进步吗？

是否有更优雅的方法来处理应该共享接口而不是共享的不同类型呢？ECS_ProcedureCallContext和ECS_MemberProcedureCallContext是ANTLR生成的类型，嵌套在VBAParser类中，由我使用的语法文件生成。

Answer 1

回到你原来的代码。我认为一点反思就能让你摆脱尝试捕捉阻塞的局面。

public bool HasExplicitCallStatement()
{
    var theObject = ((dynamic) Context.Parent);
    if(theObject.GetType().GetMethod("CALL") != null)
    {
        var call = theObject.CALL();
        return call != null && call.Symbol.Text == Tokens.Call;
    }

    return false; 
}