On two occasions I have been asked [by members of Parliament], "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?." I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question
Input and output are critical in any design, because they mediate the interface of an application or library. To most users of your software, what your I/O components do is their entire experience of what the software is. So good I/O practices are essential to usability.
I/O operations are also particularly susceptible to inefficiencies, especially on large data sets. I/O is frequently the bottleneck in a system, and usually doesn't scale well. So good I/O practices are essential to performance too.
Yet another concern is that I/O deals with the software's external environment, which is typically less reliable than its own internals. Dealing successfully with the multiple failure modes of operating systems, filesystems, network connections, and human beings requires careful and conservative programming. So good I/O practices are essential to robustness as well.
Don't use bareword filehandles.
One of the most efficient ways for Perl programmers to bring misery and suffering upon themselves and their colleagues is to write this:
open FILE, '<', $filename or croak "Can't open '$filename': $OS_ERROR";
Using a bareword like that as a filehandle causes Perl to store the corresponding input stream ...