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.
I no longer wish to be associated with this site.