Not prefixes, but case. Consider using
TurgidCapitalCaseNames() for 'opinionated' functions and
brief_lower() names for basic 'raw' functions.
This presumes you can separate your application into 'raw' and 'opinionated' parts. Sort of like what Linux calls policy/mechanism. Then, your question of where to put the decision work to satisfy preconditions answers itself: In the opinionated functions.
error_type mkdir_and_parents(string path);
Dir MakeAnEmptyOutputDirectory(string subdir);
Mixing identifier case like this disgusts some people, but it might work for you?
By 'opinionated', I mean functions that would be:
- cock-sure: deluded with the unquestionable reachability of the goal
- expedient: taking short cuts to success, e.g. succeeding silently if the directory exists already
- precocious: acquiring needed resources without a second thought, allocating memory, making parent directories
- stubborn: e.g. retrying while the system responds with 'filesystem full'
- robust: gets stuff done; might log warnings when someone else is at fault, but probably has a fallback answer
Your 'raw' functions could be quite the opposite:
- subservient: don't do anything unless asked, and when asked, do only that
- leaky: make no attempt to cover up the horror, should anything go wrong; Keen to hand problem back to someone else
- humble: assume no control over any resource not expressly given
- simple: only knows about a very small range of things
I doubt there is much of a middle ground. It would be very confused ground.
Aside: I think internal subsystem code and system interfaces are usually 'raw'-like. On the other hand I've found most customer-facing 'event response' code is usually very opinionated: eg key command handlers, view renderers, report generators, cron tasks.
Such a correlation might be because it is more important that world-facing parts of the system achieve a robust something instead of a fragile nothing. Maybe it reflects the human or business user's rough needs and expectations, versus the conservative, detail-oriented engineer-artisan's needs for dealing with complexity and diagnosing faults.