Validating "Read the Source, Luke"
So recently Jeff Atwood quoted wrote a pretty nice article about why learning to read source code is so important for developers. I absolutely could not agree more with that post.
As a tribute, I thought I would share a recent example where this principle would have settled an argument on Stackoverflow, and perhaps not lead to me using two unwitting souls for fodder in this blog post.
The question itself was pretty trivial. "How to select List<> by its index and return the content?"
One of the answers suggested using the ElementAt extension method as an alternative to using the standard indexer. No big deal, but what ensued was a pretty fun little comment argument. I've changed the names to protect the innocent:
So Bob is making a legitimate claim that using ElementAt would be inefficient compared to using an indexer. Unfortunately he also makes a pretty wild claim about ElementAt not returning the same value that calling the indexer on a List would.
Larry then decides to defend himself in a way that every programmer has probably done at some point; he writes a small test program. You can see the code here: http://ideone.com/H0A2X
Despite the test program being fundamentally flawed (see fixed program here: http://ideone.com/hooQB), Larry got the numbers he was looking for. Armed with a helping of confirmation bias, and his new numbers, Larry decides to respond back to Bob.
So what is the truth? What does the source code say? Let's use DotPeek and find out:
Turns out that ElementAt is optimized for anything that implements IList<T>and simply calls the indexer. A 30 second look at the source code would have ended this argument before it started. In reality ElementAt is 3 times slower when called on a List<T> because of the cast.
If you need to know how something works, then you need to go to the source code and see for yourself. Without this skill, you will never know for sure how stuff works. Don't waste your time arguing about how you think things work when the answer is right at your finger tips.
Follow Jeff and Brandon's advice and Learn to Read the Source, Luke
As a tribute, I thought I would share a recent example where this principle would have settled an argument on Stackoverflow, and perhaps not lead to me using two unwitting souls for fodder in this blog post.
The question itself was pretty trivial. "How to select List<> by its index and return the content?"
One of the answers suggested using the ElementAt extension method as an alternative to using the standard indexer. No big deal, but what ensued was a pretty fun little comment argument. I've changed the names to protect the innocent:
So Bob is making a legitimate claim that using ElementAt would be inefficient compared to using an indexer. Unfortunately he also makes a pretty wild claim about ElementAt not returning the same value that calling the indexer on a List
Larry then decides to defend himself in a way that every programmer has probably done at some point; he writes a small test program. You can see the code here: http://ideone.com/H0A2X
Despite the test program being fundamentally flawed (see fixed program here: http://ideone.com/hooQB), Larry got the numbers he was looking for. Armed with a helping of confirmation bias, and his new numbers, Larry decides to respond back to Bob.
And what else did Larry have to say about his results:
"When it comes to errors, the MSDN documentation and a wealth of empirical evidence suggests that such concerns are wholly unfounded... The ElementAt()
method is definitely faster... I have tested Lists of type double, float and string with similar results..."
In the end... both of these guys are wrong!So what is the truth? What does the source code say? Let's use DotPeek and find out:
Turns out that ElementAt is optimized for anything that implements IList<T>and simply calls the indexer. A 30 second look at the source code would have ended this argument before it started. In reality ElementAt is 3 times slower when called on a List<T> because of the cast.
If you need to know how something works, then you need to go to the source code and see for yourself. Without this skill, you will never know for sure how stuff works. Don't waste your time arguing about how you think things work when the answer is right at your finger tips.
Follow Jeff and Brandon's advice and Learn to Read the Source, Luke