Code reviews in a nutshell...

Nope. Quality of code is not subjective. It's either good or bad.

@telephantasm it is very subjective when it tends to be good.

But I agree, When it is bad is bad.

@telephantasm Disagree a lot... You can spot bad code easily, but it's not as if there's always precisely one amazing solution to every coding problem. Recently, a colleague of mine employed a design pattern that I particularly dislike, and we had a huge debate over it even if the design pattern was executed well. All patterns have advantages and disadvantages.

@telephantasm It''s about trade-offs. The same code might be the very worst or absolute best given a certain scenario.

@piehole @k0pernikus

What you guys mean is "it's either good or bad".

:D

@k0pernikus exactly. Imagine for example you have a program that, for some reason, needs to calculate fibonscci numbers every so often. Would you rather implement a clean recursive algorithm, a more efficient recursive one, or either of them with some sort of caching? Well, the clean code has the good mantainance, but is not efficient. The iterative one is more efficient, but not as much as the cached one, and is not as clean as the recursive. The cached recursive would seem the best, however, it has a memory impact, and in an embedded situation that might be an issue. Always have to take some trade-offs

@aritzh fibonacci numbers are very bad example because there is a constant time algorithm (which is the best solution). Recursive algorithm is also pretty much the worst choice there.

@SgnfcntOverflow Oh yes, I always forget the golden ratio!

@aritzh Well, even if it wasn't possible to get the fibonacci number in constant time, iterative algorithm has better time complexity than recursive one. If you were to store previously discovered numbers with recursive one, you could also cache them with iterative algorithm and add single int to store last discovered number. But whatever… I'm nitpicking a bit too much.