> That beeing said I think the main task of scripts is to get things done via >running them end to end in a fresh session. Now, it very well may happen that >a lot of stuff has to be done. Than splitting up scripts into subscripts and >sourcing them from a meta script is a straightforward solution. It might also >be that some functionality is put into functions to be reused in other places. >This can be done by putting those function definitions into separate files. >Than one cane use source wherever those functions are needed. Now, putting >stuff that runs code and scripts that define/provovide functions into the same >script is a bad idea. Using the main()-idioms described might prevent this the >problems stemming from mixing functions and function execution. But it would >also encourage this mixing which is - I think, a bad idea anyways.
I actually would agree entirely that files should not serve as both source files for re-used functions as well as application code. The suggestion for a main() idiom is merely to reduce variable scope and bring R practices more in line with generally recommended programming practices, not so that they can act as packages/modules/libraries. When I compared R scripts containing main functions to packages, I only mean in the sense that they help manage scope (the latter through package namespaces). Any other named functions besides main would be functions specifically tied to the script. I do see your point, though, that this could result in bad practice, namely the usage mixing you described. Best, CG ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
