Technical interview performance is kind of arbitrary

Re:Technical interview performance is kind of arbitrary by acveilleux on Wednesday February 17, 2016 @05:48PM (#11122170)

I hear "Let's use reflection!" as "It's time to find something else to work on!" Outside of writing developer tools or unit test frameworks, I can't think of a worse code smell. It's a klaxons blaring, we're doomed kinda thing.

Everytime I've seen it used, it turned into a quagmire of subtle regressions, strange effects at a distance and extremely brittle code.

I think the best pattern there are:

1. Thou shalt never write code that uses reflection on its own code base.

2. Thou shalt never use reflection unless all other options have been proven worse.

Which leaves mostly unit test frameworks for some reason...

[ Parent | on HN ]

Re:Technical interview performance is kind of arbitrary by fennecfoxen on Wednesday February 17, 2016 @07:50PM (#11122843)

I hear "Let's use reflection!" as "My language's tools for code reuse are hard to use and ineffective in practice, so I'm going to put annotations everywhere and use reflection instead! It'll be ten times harder to understand the code than it would have been with a little metaprogramming!"

But then, my opinion may be unduly influenced by Java vs Ruby.

[ Parent | on HN ]

Re:Technical interview performance is kind of arbitrary by tdeck on Wednesday February 17, 2016 @10:29PM (#11123505)

Unfortunately you practically have to use reflection for certain things if you work in Go, although the language authors have tried to discourage it by making the APIs absolutely awful.

[ Parent | on HN ]