The Weird and The Wonderful

The Weird and The Wonderful forum is a place to post Coding Horrors,
Worst Practices, and the occasional flash of brilliance.

We all come across code that simply boggles the mind. Lazy kludges, embarrassing mistakes, horrid
workarounds and developers just not quite getting it. And then somedays we come across - or write -
the truly sublime.

Post your Best, your worst, and your most interesting. But please - no
programming questions . This forum is purely for amusement and discussions on code snippets. All
actual programming questions will be removed.

Just thought it was an interesting example and it made me think differently about things.
After all these years of OOP I'm beginning to see the real value in the Functional paradigm*.
*Obviously the included sample is not a huge example of Functional programming in and of itself.

How is that any different from calling Console.WriteLine("test"); etc.?
It's just more code to call Console.WriteLine and you aren't chaining anything or using the Tee output

Even worse, an Action<T> assumes a side-effect because it doesn't return a value.
Or is Tee used to "hide" this side-effect?

If I read the wiki page I'd suspect Tee does the Console.WriteLine and you can pass in a File.WriteText or something similar, but even then I fail to see how Tee is helping you. You could just as well call both methods.

What a weird, but interesting, idea.
I think a better example than Helper.Tee("test", Console.WriteLine);
could bestring result = Helper.Tee("test", Console.WriteLine).ToUpper();
That shows the "T" character of that function more clearly: since it returns the input parameter, you can chain a few functions.

You are exactly correct about the return being the important part because it allows you to chain the methods. In another post I mentioned that you can do a "before and after" type of test which might look like:

I wrote an in-house Overtime system for our workers. One particular shift is a 24-hour on-call, which is typically 8am to 8am the next day. A worker happened to do an on-call shift 3/10 8am to 3/11 8am, and the system said it was invalid--because he only did 23 hours due to the clocks being moved forward! Once he changed the end time to 9am, it worked.
Strictly speaking, the system is correct--but it sure looks weird.

Hmmm... one of those annoying issues.
'Work' a full shift, but on that day, it's only 23 hours.. and in the Autumn, it's 25 hours.
What happens if there is overlap for users? This user entered 8:00 AM to 9:00 AM, presumably, someone else may have worked from 8:00 AM on during the same hour.