4 ms·

I actually missed that one part of his response when I agreed in reply. 750 lines is definitely a red flag for refactoring.

krylon 11y ago
Well, I agree that 750-ish lines is a bit extreme, but that function was a Win32-message handler. It basically consisted of a huge switch statement that figured out what the message was, did a little parameter mangling and then called a function that did the actual work. So while that function was very, very long, it was relatively simple to understand and did not contain a lot of logic. Also, the fact that it was a huge switch would have made breaking it up slightly non-trivial.
- SideburnsOfDoom 11y ago
  Yes, the "big switch" is the canonical example of something that's hard(er) to break down and easy(er) to read as 1 function. Though I would still try things like : - making each case in the switch as small as possible, preferably a 1-liner. - making a separate object that does the "parameter mangling". - grouping all the bits of state into an object to hold the "message loop state". - Or most radically but best: these "map", "lookup", "strategy" style patterns that reduce it to a table of (message id, handler fn) pairs http://stackoverflow.com/a/126453 http://stackoverflow.com/a/126453
  - krylon 11y ago
    It was years ago that I worked at that company. Unfortunately, things like refactoring weren't very big there, and the other developers - who were, I should emphasize, really nice guys! - were not exactly open to change. When I was hired there, that application had been in development for ~15 years, and a lot of what I did was maintenance. So making coming in as the new guy, then starting to change things, I had to tread rather carefully. FWIW, I got each of the three developers to individually admit to me that if we had the time and the money, we would basically throw the old code out and rewrite it from scratch, using the lessons they had learnt since. But time and money being what they were, that was not likely to happen. (I was really proud I got them to admit that, though - one of the other developers was very defensive of his work, and getting him to admit that was quite an achievement; I actually gained some valuable people skills in doing so.) I was glad, though, that the code was relatively readable and organized in a sane manner. There was some cruft that had accumulated over the years, but overall it was surprisingly sane. That was one of the first times I had to read somebody else's code, and it was good code for that purpose - sparsely commented, yet very clear. Also, keep in mind that this was C. Different languages offer different ways of decomposing / structuring code.

krylon 11y ago

Well, I agree that 750-ish lines is a bit extreme, but that function was a Win32-message handler. It basically consisted of a huge switch statement that figured out what the message was, did a little parameter mangling and then called a function that did the actual work. So while that function was very, very long, it was relatively simple to understand and did not contain a lot of logic. Also, the fact that it was a huge switch would have made breaking it up slightly non-trivial.

SideburnsOfDoom 11y ago
Yes, the "big switch" is the canonical example of something that's hard(er) to break down and easy(er) to read as 1 function. Though I would still try things like : - making each case in the switch as small as possible, preferably a 1-liner. - making a separate object that does the "parameter mangling". - grouping all the bits of state into an object to hold the "message loop state". - Or most radically but best: these "map", "lookup", "strategy" style patterns that reduce it to a table of (message id, handler fn) pairs http://stackoverflow.com/a/126453 http://stackoverflow.com/a/126453
- krylon 11y ago
  It was years ago that I worked at that company. Unfortunately, things like refactoring weren't very big there, and the other developers - who were, I should emphasize, really nice guys! - were not exactly open to change. When I was hired there, that application had been in development for ~15 years, and a lot of what I did was maintenance. So making coming in as the new guy, then starting to change things, I had to tread rather carefully. FWIW, I got each of the three developers to individually admit to me that if we had the time and the money, we would basically throw the old code out and rewrite it from scratch, using the lessons they had learnt since. But time and money being what they were, that was not likely to happen. (I was really proud I got them to admit that, though - one of the other developers was very defensive of his work, and getting him to admit that was quite an achievement; I actually gained some valuable people skills in doing so.) I was glad, though, that the code was relatively readable and organized in a sane manner. There was some cruft that had accumulated over the years, but overall it was surprisingly sane. That was one of the first times I had to read somebody else's code, and it was good code for that purpose - sparsely commented, yet very clear. Also, keep in mind that this was C. Different languages offer different ways of decomposing / structuring code.