Dan Weinreb's Notes on Organising Lisp Files

You ought not get a warning for a forward reference to a function. Lisp compilers generally defer these checks until the end of a "compilation unit", so that it will only tell you that a function is undefined if the function was not seen in this compilation unit, or earlier in the compilation.

Macros must precede usage. If you're going to use the macro throughout many files, e.g. if it is a general utility, it's often good to put it in a separate file of utility macros. If it's only going to be used within one file, just put it at the beginning of that file.

If a class's methods are going to be dispersed amongst many files, then you might want to put the class definition in a separate file. Otherwise it's fine to just put it into a file and then put the method later in the file.

I think it's very good practice to use explicit defgeneric forms, particularly so that you can use their doc strings to explain the generic meaning of the function. You can put them anywhere after the class definition. You might want to put them all together, after the class definition, so that someone reading the code can see the whole "protocol" all together.

A slightly more tricky issue is Lisp functions that are called by macros: not by the code that the macro expands into, but by the macro itself during expansion. Such functions must be available when the macro is expanded. You can either use eval-when to make sure that they get defined at compile-time, or you can put them into another file (Y) and tell ASDF that in order to compile X, you must first load Y.

Yes, it's unfortunate that a Lisp programmer has to worry about all this. Many of us have talked about the possibility of doing a Lisp IDE that would take care of all this automatically. But as far as I know, nobody has that yet.