First of all, \makeatletter is unnecessary in .sty or .cls files, as the default catcode regime includes it; this is presumably to encourage package writers to hide their macros using @-laden names. For this reason, I believe that using this command is harmless in package files.
However, using the pair of commands together is harmful, because unlike in a document, you do not want to return to the @ = other setup within the package. These are document commands and the standard ordering \makeatletter \makeatother assumes that \makeatother is actually undoing the previous change, whereas in packages, it is the one making the change.
Edit: Here is a more informed answer. According to source2e.pdf, the following scheme is used to load packages and classes:
- First, the options and such are gathered.
- Then the name of the current file (i.e.
mypackage.sty), along with the catcode of @, are saved on a stack.
- Then
\makeatletter is run and, if appropriate, the requested file is loaded.
- Afterwards, the stack is popped and the pre-package-load state restored.
In other words, the following ignorant code has no effect at all:
\documentclass{article}
\usepackage{bad}
\begin{document}
\end{document}
bad.sty:
\makeatletter
\makeatother
\RequirePackage{unsuspecting}
However, it is quite possible that a package does not use \RequirePackage, but just \input. In that case, the catcode is not protected and indeed, errors can arise, as you can check yourself by making bad.sty, for example:
\makeatletter
\makeatother
\input{pgfkeys.sty}
If that seems artificial, have a look at pgfkeys.sty itself: it \inputs pgfkeys.code.tex, and that file, in turn, \inputs pgfkeysfiltered.code.tex. Presumably, the author felt himself safe once within his own package, but did not suspect that someone else might circumvent the package-loading protection mechanisms also!
\inputfiles when you mean to\usepackagethem". – Ryan Reich Jul 08 '12 at 06:06bar.texshould be a package. It could be anauxfile,toc,outor anything. There's no reason to assume the use of\AfterPackagewouldn't work, so leaving@as other at the end of a package is clearly an error. – Stephan Lehmke Jul 08 '12 at 06:08