Ideological Programming Question...
-
Would you break up a method into more then one method just to make it smaller even if the code is not going to be used elsewhere? The program I am working on has one method that will probably be about 200-250 lines of code. Is too much for a single method? Should I create a couple helper methods just to make it more readable?
I didn't get any requirements for the signature
Before Visual Studio 2005's "Refactor -> Extract Method" I'd have said 200 - 250 lines was pushing it but not worth missing a deadline over. With Extract Method, it's a cinch to go back and move large swaths of code into a method call so it's easier to be a little tighter on the length of a function. I have never gotten to the point where every method is entirely visible on a single page. People who sprang for VisualAssist (or whatever it was called) may have a lower tolerance for long methods.
-
IMHO 200 lines of code is at least 10 times the size a method should be if you want it to be testable. Make it testable, and maintainable will follow quite happily. :)
Anna :rose: Having a bad bug day? Tech Blog | Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
I have to sorta object here. If you think of every conditional as doubling (at least) the number of tests required for complete coverage, and estimate that 1/10th of all lines of source are conditionals, then a single method that has 200 lines of code has at least 20 conditions. That's 2^20 variations to test (~million). Add a few more such methods and it quickly becomes entirely infeasible to test every execution path. Testing is critical. Very important. But testing is not a substitute for good coding habits. "Provable Correctness" has not yet found its way into the commercial world and testing is no shortcut to it. Apologies for hijacking this thread!
-
Dalek Dave wrote:
Who will be caring for the poor wee beastie?
Well, this is a problem. Another "programmer" was responsible for this project. But he really can't cut the mustard, so I am doing all the coding. My boss said he will be responsible for it and if not he'll be out of job... Since this other "programmer" has not helped at all, for he has not written one line of code, I don't know what is going to happen. It will probably be me for a little while...
I didn't get any requirements for the signature
ToddHileHoffer wrote:
Well, this is a problem. Another "programmer" was responsible for this project. But he really can't cut the mustard, so I am doing all the coding. My boss said he will be responsible for it and if not he'll be out of job... Since this other "programmer" has not helped at all, for he has not written one line of code, I don't know what is going to happen. It will probably be me for a little while...
Then do the poor backstitch a favor and break it up into subroutines with easily understood names so that, when he breaks it, he'll break it in one spot that can be trapped with ease. Large blocks of code are almost always more difficult to debug because the time it takes for the eyes to traverse them can cause "code blindness". Also, it's easier to label an error message with a subroutine name than try to designate a block of larger code with a label. Finally, if each subroutine that is used by the method implements its own error handling including a subroutine-speoific message, even this other should be able to isolate the error pretty quickly...and get enough help to get the thing fixed before his boss notices.
-
ToddHileHoffer wrote:
Well, this is a problem. Another "programmer" was responsible for this project. But he really can't cut the mustard, so I am doing all the coding. My boss said he will be responsible for it and if not he'll be out of job... Since this other "programmer" has not helped at all, for he has not written one line of code, I don't know what is going to happen. It will probably be me for a little while...
Then do the poor backstitch a favor and break it up into subroutines with easily understood names so that, when he breaks it, he'll break it in one spot that can be trapped with ease. Large blocks of code are almost always more difficult to debug because the time it takes for the eyes to traverse them can cause "code blindness". Also, it's easier to label an error message with a subroutine name than try to designate a block of larger code with a label. Finally, if each subroutine that is used by the method implements its own error handling including a subroutine-speoific message, even this other should be able to isolate the error pretty quickly...and get enough help to get the thing fixed before his boss notices.
Yes, I created six well named subroutines. I have it down to about 50 lines of code. It is much more readable.
I didn't get any requirements for the signature
-
Yes, I created six well named subroutines. I have it down to about 50 lines of code. It is much more readable.
I didn't get any requirements for the signature
ToddHileHoffer wrote:
Yes, I created six well named subroutines. I have it down to about 50 lines of code. It is much more readable.
Yup, sounds about right. Now, comment the living heck out of it, with some explanations of what's going on as well as (if you can figure this out) what the most likely errors might be in the various sections. I've programmed for the chimpanzee class before. Every little bit of help can make the difference between a usefully employed chimpanzee or an empty desk waiting for another potential Frankenstein's Monster.
-
I have to sorta object here. If you think of every conditional as doubling (at least) the number of tests required for complete coverage, and estimate that 1/10th of all lines of source are conditionals, then a single method that has 200 lines of code has at least 20 conditions. That's 2^20 variations to test (~million). Add a few more such methods and it quickly becomes entirely infeasible to test every execution path. Testing is critical. Very important. But testing is not a substitute for good coding habits. "Provable Correctness" has not yet found its way into the commercial world and testing is no shortcut to it. Apologies for hijacking this thread!
That's exactly why I consider that keeping functions short is important. A 200 line function is not likely to be testable; a 20 line one is. :) Although mathematical correctness of code is unlikely to be provable in the general case, a good test coverage can mitigate this by warning when behaviour has changed in an unintended way - perhaps as an unintended side effect of a change. If you disagree, you could always come along to the ACCU Conference[^] next year and present your hypothesis. If you do, believe me, the debate will be lively and interesting[^]... ;)
Anna :rose: Having a bad bug day? Tech Blog | Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
modified on Wednesday, June 3, 2009 12:14 PM
-
Would you break up a method into more then one method just to make it smaller even if the code is not going to be used elsewhere? The program I am working on has one method that will probably be about 200-250 lines of code. Is too much for a single method? Should I create a couple helper methods just to make it more readable?
I didn't get any requirements for the signature
-
Readability, Readability, Readability. Oh yeah. It should be understandable. Sure. Break it up a little, into logical pieces. Make it yours. It sounds like it might be any way. After our family packed up from a weekend of camping, we'd stand side-by-side and "walk" our camp site, and pick up any trash or sticks. We'd leave the site in better condition than we found it. I apply the same policy to codeing. Leave the site in better condition than you found it. Break up a method here. Comment better there. ... you might return there again someday. ;)
We tried vacuuming. It just seemed to make things worse.
_____________________________ Those who study history are doomed to watch others repeat it. -Scott M.
-
Would you break up a method into more then one method just to make it smaller even if the code is not going to be used elsewhere? The program I am working on has one method that will probably be about 200-250 lines of code. Is too much for a single method? Should I create a couple helper methods just to make it more readable?
I didn't get any requirements for the signature
I stumbled on a nice trick when using Resharper with C#: If you have non-public methods in an effort to avoid those long methods, make the helper methods static and pass in all needed information through parameters. It keeps it clear that the helper methods are not accessing field variables. I think Resharper recommended this trick when it recognized that a helper method did not access local fields, and I adopted it as my general strategy.
-
Depends on the complexity. I might break it up into discrete functional components. I don't like real long functions, nor files longer than 1000 lines.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
