First of all, functional programming is currently what all the cool kids are doing. The Anti-Pattern was talking about procedural programming really (it would be clearer if the technique were called "procedural decomposition" but it's not), and I think you were too.
The anti-pattern talked about bad ways of writing procedural code in an object oriented language, the other page talked about bad was of writing Java - in truth there is no language so fantastic that you can do everything you want to do but can't write bad code.
In practice, I've seen a little more engineering in object oriented code than procedural -a little less under engineering and a little more over engineering.
In your case, it would depend on the specifics, and I'm not sure what you actually do in a procedural style. Is it correct, clear, testable, easy to modify, etc? The criteria to judge the code should be based on such practical concerns, and not on purity of one particular style. It sounds like in your case reasonable and knowledgeable people could disagree (and do!) about those concerns, and if so there is probably no objective way to determine the truth of the matter.
The main point of a CSRF token is that it can't have been sent from another site. So therefore it (a) can't be predicted or detected by an attacker, and (b) is not automatically attached to a request the way a cookie is.
So theoretically if a CSRF token is never disclosed to third parties, again theoretically, you don't have to expire them at all. But then you run the risk of your token getting "leaked" somehow. So your expiry period really should be short enough to combat the prospect of a token getting out and being used against your user.
There aren't really any guidelines, but a good solid techique is to auto-generate a new token on EVERY request which embeds a signed timecode, and then accept tokens up to a certain age.
A sample function might be:
concat(current_time,salt,sha256_sum(concat(salt,userid,current_time,secret_string)))
The token contains timing information and a salt, but also contains a signature which can't be forged and which is tied to the userid.
Then you can define your own expiry interval -- an hour, a day, 2 hours. Whatever. The interval in this case isn't tied to the token, so you're free to set expiry rules however you want to.
At the very least, though, CSRF tokens should expire when the login session expires or when the user logs out. There's no expectation by the user that a form that you brought up BEFORE you logged out will continue to work AFTER you log back in again.
Best Answer
As a general guideline, libraries should be totally disconnected from the environment. That means that they shouldn't perform operations on standard streams, on specific files, or have any expectation about the environment or the context they are used.
Of course, there are exceptions to this rule, but there must be a very good reason for it. In the case of using
stdin, i can't find any reason (unless your library actually provides routines for reading from stdin, likestd::cinfrom C++). Also, taking the I/O streams from a parameter rather than having them hardcoded adds so much flexibility that it's not worth not doing it.