^^^ This 1000 times. I suggest this approach for all scripts. Entry points should be nothing more than delegators

I agree for logical separation but I don't think logic always needs to be removed to separate files (aka custom module) as I think @creece implies?

scripts should be dumb entry points and have no business logic in them. If you extract them out into a library, you have everything separated and your scripts just become some try/catches of exactly whats going on. Whats the use case for not doing this?

for me the use case is just simplicity - especially for simple scripts.

yeah if its like 1 thing maybe not.. but if its gonna be a big script i'd do it.

agreed, I do try to balance the complexity both inside a given script file and across multiple files as needed rather than force a pattern for all scripts. My scripts do tend to be shorter and easier to understand though.

It's exceedingly rare I don't have a separate file for the primary logic. The only decisions in my entry point are generally which module(s) to delegate to

fair enough

For really small straightforward stuff, @mattdahse has rubbed off on me and I've started making more workflows (depending on client)

I'm all for decoupling things, but it's also nice to see all the logic in one file.

I’m with @stalbert on this. Separate modules for their own sake doesn’t make sense if I’m just adding a button or setting a field.

I admit my most common use case for creating a custom module is code reuse

We have a whole conversation about workflows vs scripts on Matt's YT channel

It isn't separating logic just to separate it. You want to make your code clean and easy to maintain and moving things out into modules really helps that. If there's like 1 method or something sure, there's no real reason to break that out. This really applies to larger scale scripts.

Thanks for the link Eric, can't wait to watch a couple NetSuite celebs duke it out 🙂

We're always looking for more voices