Rules and standards are unlikely to be helpful unless you first establish why people have been putting main loops inside of modules. If you outlaw a legitimate practice, your programmers will jump through hoops to get things done and things may end up even more of a mess than they were before.
You might benefit from consolidating main loop processing into a single "main loop management module". On the other hand, you may have some very good reasons for needing separate ways of handling the main loop portion of a program. Placing the main loop of a program in a module separate from the launch script is a well established programming practice, especially if the action of the main loop is complex and needs lots of supporting functions. Only your team (or close analysis of the code) can answer that question.
I'd also take a careful look at how your code is factored into modules. It is usually a good idea to keep main loop code in a separate module from general purpose code. People may have lots of reasons to use that super-duper-string-muncher subroutine, but if super-duper-string-muncher is sitting in a module with an event loop, only programs that need both string-muncher and that particular event loop can use it safely. Perhaps a rule that "main loops" need to be in a separate specially named module (OurCompany::MainLoop::AppNameHere for example) would solve the problem better than an arbitrary limit on the number of main loops.
Best, beth
In reply to Re: MainLoop in Perl Module
by ELISHEVA
in thread MainLoop in Perl Module
by wjmarlett
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |