[miz6565]

Every single time I learn a new computer language, I challenge myself to do the Number to Word Converter with that language. What I mean by "Number to Word" converter is I input a number and it spits out the word. Usually I do this with recursion numbers 1 - a million.

ex -
2 prints out two

53 prints out fifty three
and so on..

The thing is I found out a new algorithm I can use. What I usually do is go by standard place to place, convert the number to a string and use recursion for each placement. But I found out I can do it another way. Function by function. So I can make one function for the tens place, another for the hundreds place, another for the thousands place, and so on. Then put it in an array and conclude the algorithm like that.

The thing is I'm asking what would be better. A guy mentioned this on the logo forum (logo computer language, when I was learning it) that he used an algorithm that makes many functions with small lines of code. I made one function with a lot of lines of code. I argued that with his algorithm he would have to add more code if he wanted to update it, while I had to add one statement to update it.

Can someone tell me, which would be better? One big function with a lot of code or many functions with small code in them?

Thanks ;)

[jimblumberg]

Can someone tell me, which would be better? One big function with a lot of code or many functions with small code in them?

In my opinion, opt for the many small functions. You have several advantages with small functions. The biggest advantage is they are much easier to implement and test. Properly testing a large function is much more difficult, and it is easier to miss edge cases.

Jim

[purvip]

First go with small functions only check the results and then u can do for big functions.. :)

[jwdonahue]

There's always trade-offs to be made. One big gnarly function might be a tad more efficient at run-time but completely ungrokable. If future maintenance is a concern, it's almost always best to error on the side of verbosity. After you've been programming for a few years, you'll discover the need for clearly written code when you go back to modify or repair some old 100 line function you wrote a few years back.

Yes, sometimes that single function can be bent with fewer lines of code, but how hard is it to figure out exactly the correct few lines in the right place? More verbose code, that is; lots of functions with descriptive names can be easier to understand and therefore, more amenable to being fixed/modified correctly on the fist try. Maybe I have to write one or two new functions and even delete one or two I no longer need, but I can probably get it done before you've figured out how your 100 liner actually works and where to make the changes.

You can carry this too far however and it's not just a matter of personal style. Every time you go to write a function, ask yourself what kind of function is it? Is it a "high level" function, "low level" or somewhere in-between. Does the specification contain domain specific language? Will domain experts ever read the code? Is it a write-once and use-once function or will it be used more than once? Only used in just this one program/component or shared more widely?

Books have been written on this subject (search for Uncle Bob Martin for instance) so there's no way any of us can give it a really good treatment here.