4 ms·

I just had to deal with extending an absolutely massive C++ function the other day and it was a nightmare. The function was 2500 lines long and littered with se

I just had to deal with extending an absolutely massive C++ function the other day and it was a nightmare. The function was 2500 lines long and littered with several dozen exit points - all of which execute under slightly different conditions. Throw in a couple several hundred lines long switch-case statements and you can see what I'm getting at. Figuring out the right place to put a breakpoint that will actually fire due to a maze of conditions and returns took me a couple hours. Of course, I've seen many cases where people take this to the opposite extreme and start breaking up functionality that logically belongs together and can't be reused in other contexts. It makes it pretty apparent that writing decent readable code is hard (for many people anyway).

virmundi 13y ago
"start breaking up functionality that logically belongs together and can't be reused in other contexts" I know you said you're in the C++ world, so I don't think what I'm doing fits yours, but I've responded to the same behavior in the Java world in a way that tends to confuse and mystify my co-workers. In Java I've started to declare classes within methods. These classes can compute complex processes, but are nicely tucked away in the only logical place they make sense, that method. My reason for this is that the method really belongs to the containing class. I can't break it down or abstract it out. I could use composition, but the new method-class isn't usable by anything else. The sub steps in the method aren't usable by any other method within the housing class. I could put them there, but they would just muddy the outer class. So now the code looks something like this. public class Outer { void doSomethingComplex(final params) { class ComplexThing { private void step1() {...} private void step2() {...} public void goToTown() {...} } new ComplexThing().goToTown(); } } ComplexThing gets access to the outer params. This cuts down on constructor complexity and cements the intricate bond between the two entities, method and inner class. The logic is broken down nicely. Finally, nothing is needlessly shared. This might make the outer class a bit larger, but I find this structure pleasant. It's also a useful pattern for writing tests. Each test method gets a class (could have inheritance) that has a setup, test, tear down. All of that is encapsulated in one place.
JoeAltmaier 13y ago
I know that code. Mine was a serial protocol with a maze of flags and conditions. I drew a table on a large sheet of paper, and recopied the code as a state machine. When I was done, it was clear where the problem lay: the state machine was woefully incomplete. I rewrote the thing AS a state machine with all state-event pairs handled. Voila! It worked. Had to go back and diddle with some events (better way to handle parity error during checksum calculation etc) but at least I could find exactly the place in the code to do that.

virmundi 13y ago

"start breaking up functionality that logically belongs together and can't be reused in other contexts" I know you said you're in the C++ world, so I don't think what I'm doing fits yours, but I've responded to the same behavior in the Java world in a way that tends to confuse and mystify my co-workers. In Java I've started to declare classes within methods. These classes can compute complex processes, but are nicely tucked away in the only logical place they make sense, that method. My reason for this is that the method really belongs to the containing class. I can't break it down or abstract it out. I could use composition, but the new method-class isn't usable by anything else. The sub steps in the method aren't usable by any other method within the housing class. I could put them there, but they would just muddy the outer class. So now the code looks something like this. public class Outer { void doSomethingComplex(final params) { class ComplexThing { private void step1() {...} private void step2() {...} public void goToTown() {...} } new ComplexThing().goToTown(); } } ComplexThing gets access to the outer params. This cuts down on constructor complexity and cements the intricate bond between the two entities, method and inner class. The logic is broken down nicely. Finally, nothing is needlessly shared. This might make the outer class a bit larger, but I find this structure pleasant. It's also a useful pattern for writing tests. Each test method gets a class (could have inheritance) that has a setup, test, tear down. All of that is encapsulated in one place.

JoeAltmaier 13y ago

I know that code. Mine was a serial protocol with a maze of flags and conditions. I drew a table on a large sheet of paper, and recopied the code as a state machine. When I was done, it was clear where the problem lay: the state machine was woefully incomplete. I rewrote the thing AS a state machine with all state-event pairs handled. Voila! It worked. Had to go back and diddle with some events (better way to handle parity error during checksum calculation etc) but at least I could find exactly the place in the code to do that.