一个Sub由呼叫其他Sub组成的东西组成，这不好吗? [英] Is it bad to have a Sub made up of nothing but calls to other Subs?

问题描述

我以前在代码审查"中发布了此内容，但我猜这不是正确的地方.希望是.

I previously posted this in Code Review, and I guess it wasn't the right place. Hopefully this is.

我为Excel工作表订单表单的各种操作创建了数十个Subs.一天要完成数百项操作，因此必须检查许多事情.

I have created dozens of Subs for various actions for Excel worksheet order forms. Hundreds of these are done a day, and many things must be checked.

例程是，当有人打开这些​​工作表中的一个时，他们做的第一件事是运行一个宏，该宏调用许多其他工作表.所以本质上是这样的:

The routine is that when someone opens one of these worksheets, the first thing they do is run a macro that calls dozens of others. So it's essentially something like this:

Sub AllMacros()
Call Macro1
Call Macro2
Call Macro3
Call Macro4
Call Macro5
Call Macro6
Call Macro7
Call Macro8
Call Macro9
Call Macro10
Call Macro11
Call Macro12
Call Macro13
Call Macro14
Call Macro15
Call Macro16
Call Macro17
Call Macro18
Call Macro19
Call Macro20
End Sub

之所以这样做，是因为有时只需要运行其中一个Sub，因此它们将被单独执行.

I did it this way because there are times when only one of those Subs needs to be run, and so they will be executed individually.

我的主要问题是:这种技术天生不是一个好主意吗?我知道我没有显示所有代码，但这不是重点.这里有太多的代码可以发布.我想我正在寻找的共识答案是是的，那很好".或不，最好这样做."

My main question is this: Is this technique inherently not a good idea? I understand I'm not showing all the code, but that's not the point. There's way too much code to post here. I suppose I'm looking for the consensus answer to be either "Yes, that's fine." or "No, it's better to do it this way."

推荐答案

如果您在CR上发布了实际的真实代码，则会获得更大的帮助&有意义的答案.

If you posted your actual real code on CR, you'd get a much more helpful & meaningful answer.

从设计的角度来看，您所拥有的是一个协调器"，其作用是按特定顺序调用其他过程 ，这本身并不坏.

From a design standpoint, what you've got is a "coordinator" whose role is to invoke other procedures in a specific order, which isn't bad in itself.

从务实的角度来看，您所获得的内容与任何其他过程中的任何其他一系列可执行语句都没有什么不同:任何可执行语句都将调用 something 的成员在某一点或另一点.

From a pragmatic point of view, what you've got is not any different than any other series of executable statements in any other procedure: any executable statement is going to be invoking a member of something at one point or another.

将20个宏内联到此上帝过程"中并像您一样拆分它们之间的区别是抽象-

The difference between inlining your 20 macros into this "god procedure", and splitting them like you did, is abstraction - one of the key concepts of object-oriented programming.

您是否拥有好的抽象名称，无法用这些假名称来分辨，并且不明确地知道所有这些宏都在解决什么问题，而 正是代码的原因评论想要查看您的真实代码，以及为什么这样做:

Whether you have good abstractions is impossible to tell with such fake names and without knowing specifically what problem is being solved by all these macros, and that is exactly why Code Review wants to see your real code, and why this:

我想我正在寻找的共识答案是是的，那很好".或不，最好这样做."

用假设的 Macro1 ... Macro20 存根代码无法回答.

Is unanswerable with hypothetical Macro1...Macro20 stub code.

如果宏之间的交互作用使得它们之间的全局状态发生了变化，并且执行顺序很关键，那么您得到的是不好的，因为您具有隐式 时间耦合:如果执行顺序发生变化，事情就会崩溃/破裂-就像您先 Activate 激活一个单元格然后关闭 ActiveCell 或选择，如宏记录器代码.

If the interactions between the macros is such that global state is altered between them and the order of execution is critical, then what you've got is bad because you've got implicit temporal coupling: if the order of execution changes, things fall apart / break - much like when you Activate a cell and then work off ActiveCell or Selection, like macro-recorder code.

如果不是这样:

OpenFiles
ProcessNewData
GenerateReports
SaveCSVs
'...

您有这个:

Set files = OpenFiles
Set reportData = ProcessNewData(files, targetBook)
Set reports = GenerateReports(reportData)
SaveCSVs(reports)

您应该使时间耦合更加明确，消除以错误的顺序执行其中一个宏的机会，并消除全局状态.

You would have made the temporal coupling much more explicit, removed the chance for executing one of the macros in the wrong order, and eliminated the global state.

您的答案是这取决于您的真实代码是什么样的".

Your answer is "it depends what your real code looks like".

这篇关于一个Sub由呼叫其他Sub组成的东西组成，这不好吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！