The silent and sporadic errors are the nasty ones (from my PoV). Some ideas:
- Control flow: A conditional stray last or next in a subroutine that is called from within a loop can have interesting effects.
- Variable names: Take a descriptive name but use it for something else,
e.g. store user-ids in %IP_Tables. Or use something like $result_aref but don't let it refer to an array.
-
I/O: print in combination with select offers some pitfalls...
- List context: remove or displace some parenthesis ...
- Return values: implicit return values (instead of a proper return)...
- Side effects (global variables w. and w/o local)...
- Implicit use of @_, e.g. by &some_sub; (see perlsub)...
- shift can operate on @_ or @ARGV...
- poison input: remove/add some TAB characters... swap some columns...
- ...
Is this approach intended to test a maintenance programmer?
Maybe I got something wrong, but I feel a little bit uncomfortable
with the approach of laying out a
code-minefield.
Wouldn't it be more constructive to give the candidate a task to start from scratch?
... or to find an alternative solution to the already solved problem?
... or let her/him optimise/refactor the script concerning speed/memory/code-formatting/robustness?
... turn a script into a module?
... wrap a GUI around it?
...