In case these terms are too old for anyone to know them, we used to use the phrase "for effect" to mean a function that was called for the sake of its side-effects, versus "for value" when it was called for the sake of its returned value. (Actually I'm not sure I remember what we called a function with both properties.)
In some code I have seen, the author of the code has written (values) at the end of an implied-progn body. The purpose, pretty clearly, is to signal the reader of the code that the function was purely for-effect, i.e. that the returned value does not mean anything.
This is mostly stylistic. In most cases, returning "nil" means the same thing as returning no values, i.e. (values). The only situation where it makes any difference, as far as I know, is when multiple-value-list is being called, and that's used very, very rarely.
The question is, is it good style? That is, ought we consider it something to be recommended?
The pro is that it presents clear information to the reader of the code. Merely not putting anything at the end of the implied progn means that the value of the last function called is the returned value, and the reader of the code might think that was on purpose.
On the other hand, having a (values) at the end does not actually prove that the function does not have any meaningful value, since a "return" within the function could return a value (or many values).
From a purely emotional/historical point of view, I am not used to seeing these (values) forms, and they seem somewhat ugly and verbose. But that's just based on my own experience and should not carry much weight.
I'd like to write in our programming standards either that they should be used, or that they should not be used. I think it's suboptimal for them to be used in some places and not others, since the inconsistency could lead a reader of the code to draw wrong conclusions.
What do people think?
-- Dan