Tiffany started the code review with an apology. "I only did this to stay in style with the existing code, because it's either that or we rewrite the whole thing from scratch."
Jim J, who was running the code review nodded. Before Tiffany, this application had been designed from the ground up by Armando. Armando had gone to a tech conference, and learned about F#, and how all those exciting functional features were available in C#, and returned jabbering about "immutable data" and "functors" and "metaprogramming" and decided that he was now a functional programmer, who just happened to work in C#.
Some struggling object-oriented developers use dictionaries for everything. As a struggling functional programmer, Armando used tuples for everything. And these tuples would get deeply nested. Sometimes, you needed to flatten them back out.
Tiffany had contributed this method to do that:
public static Result<Tuple<T1, T2, T3, T4, T5>> FlatternTupleResult<T1, T2, T3, T4, T5>(
Result<Tuple<Tuple<Tuple<Tuple<T1, T2>, T3>, T4>, T5>> tuple
)
{
return tuple.Map(x => new Tuple<T1, T2, T3, T4, T5>(x.Item1.Item1.Item1.Item1, x.Item1.Item1.Item1.Item2, x.Item1.Item1.Item2, x.Item1.Item2, x.Item2));
}
It's safe to say that deeply nested generics are a super clear code smell, and this line: Result<Tuple<Tuple<Tuple<Tuple<T1, T2>, T3>, T4>, T5>> tuple
downright reeks. Tuples in tuples in tuples.
Tiffany cringed at the code she had written, but this method lived in the TaskResultHelper
class, and lived alongside methods with these signatures:
public static Result<Tuple<T1, T2, T3, T4>> FlatternTupleResult<T1, T2, T3, T4>(Result<Tuple<Tuple<Tuple<T1, T2>, T3>, T4>> tuple)
public static Result<Tuple<T1, T2, T3>> FlatternTupleResult<T1, T2, T3>(Result<Tuple<Tuple<T1, T2>, T3>> tuple)
"This does fit in with the way the application currently works," Jim admitted. "I'm sorry."