|
|
|
|
|
|
by chris_wot
949 days ago
|
|
|
I have a trick for understanding code. What I do is I look at the function, and when there is an if statement or loop, I extract this (and possible some of the surrounding code, depending on what the code does) into a named function. Slowly, the function starts to make sense. Another thing that works for me, is I write a unit test for a function. Personally, I’m beginning to loathe encapsulation in classes, because what would be better would to write a unit test for the extracted function, but if it is a private function - we’ll, that means you can’t easily write a unit test. On that last bit - the only way I know of unit testing private functions is to ensure that a unit test for the public function is writtten. I then place a temporary assert into the private function code path I am exercising and run the unit test. If the test fails because of the assert, then I know I’ve tested that code path. A dreadful way to test, at least that’s how I feel. I am increasingly looking at Haskell which is a revelation! I now know why some people aren’t happy with OOP… |
|
|