Re^2: How do I prototype a function with a varying number of arguments?

And see On comments for a long discussion between BrowserUK and I about the meaning and value of comments. BrowserUK is strictly a minimalist (or perhaps a zeroist), and feels comments only get in the way, and I'm a semi-maximalist, who feels that comments should be there to clarify intent, point out pitfalls, and explain complex code to the reader. That said, I too agree that comments which simply mirror the code are not needed.

In the example noted, the comment is not needed; if there were some specific limitation on what the return value should be or a special case that might occur, a comment would be a good idea. That's a marginal case and might or might not be better put in the POD for the subroutine (which should also be there); it would depend on the context. In an internal-use-only subroutine that was not part of a documented external interface, I'd use a comment; in a published, intended-for-use-without-reading-the-code situation, I'd put it in the POD.

Comment on Re^2: How do I prototype a function with a varying number of arguments?

Replies are listed 'Best First'.
Re^3: How do I prototype a function with a varying number of arguments? by JavaFan (Canon) on Jul 31, 2011 at 21:15 UTC
BrowserUK is strictly a minimalist (or perhaps a zeroist), and feels comments only get in the way, and I'm a semi-maximalist, who feels that comments should be there to clarify intent, point out pitfalls, and explain complex code to the reader. I tend to be both. I feel comments should be there to clarify intent, etc. I also prefer to have as few comments as possible. Impossible you say? I disagree. If your code is simple enough, there just isn't much reason to add a comment. If I feel the need to write a comment to explain my code - I also consider rewriting the code instead so the comment may no longer be needed.	[reply]
Re^4: How do I prototype a function with a varying number of arguments? by pemungkah (Priest) on Aug 08, 2011 at 17:47 UTC
Completely agree on both these points. Sometimes you just have to explain what the heck is going on because there are reasons you had to do it that way (the kernel bug I reference in my post is an example). If it is possible to clarify to eliminate the need for the comment without sacrificing performance or correctness then I'm all for the code that doesn't need it.	[reply]