When it will be freed?

[Guest]

Some programmers do not like the idea of multiple return points from a
function; they want all code paths to reach a single return point at the
end of the function.

I think they were probably put through an over-harsh potty training
regime

 They often extend the same logic to main(),
basically banning the use of exit() and requiring all functions to
return so that (the first instance of) main() returns from a single point..

While there are some advantages to having a single return point, more
pragmatic programmers believe that complex code is often easier to
understand with multiple return (or exit()) points.  This is not unlike
the debate about "goto"; avoiding it is a good idea in general, but
there are times it's the best tool for the job.

<snip>

 

[Guest]

agreed

I don't find that to be so. Though it might depend on what you mean
by
"a lot". I don't find myself with vast argument lists when I use
many small functions. I suppose there tends to be some sort of
ptr-to-context (may be an object...) being passed around.
I don't find it a burden.

the old structured programming people used to encourage small
functions. A large function taht did many things would be said to
"lack cohesion".

The Xtreme Programming people and their Factor Mercilessly
(it's their sloganising that puts me off...) tend to end up with
many, small functions.

There's nothing wrong with that.  If anything it's an advantage.

how so an advantage?

--
Nick Keighley

"It startled him even more when just after he was awarded the
Galactic Institute's Prize for Extreme Cleverness he got lynched
by a rampaging mob of respectable physicists who had finally
realized that the one thing they really couldn't stand was a smart-
ass."
Douglas Adams, The Hitchhiker's Guide to the Galaxy (1979)

 

[Ian Collins]

how so an advantage?

As you said in your reply "there tends to be some sort of ptr-to-context
being passed around.". I see this as good design, cooperating functions
operating on a shared state. It's much easier to test and add
functionality once the state in separated form the actions.

 

[Mark Wooding]

the old structured programming people used to encourage small
functions. A large function taht did many things would be said to
"lack cohesion".

I find that odd. If anything, I find it easier to write /large/
functions which do a single thing. Individual components of it tend to
be more tangled up with each other. It's as if there's an optimum
granularity (which varies according to exactly what it is I'm actually
doing) below which either (a) describing the function's purpose and
effects becomes too difficult or (b) you don't actually save anything by
calling it.

As a firm believer in `once and only once' (from before I heard that
slogan attached to it), I'll strip stuff out into a separate function if
I need it in two places[1]. Apart from that, a piece of functionality
has to lift out very cleanly for me to think it's worth separating.

[1] This pursuit also leads me into macrology that leaves some others
queasy. :-(

-- [mdw]

 

[James Kuyper]

I think they were probably put through an over-harsh potty training
regime

The idea of structured programming was developed to deal with a very
real problem. Following the precepts of structure programming absolutely
is a a less-than ideal solution to that problem. That's a reason to look
for a better solution; it's no legitimate basis for casting personal
aspersions on the advocates of that solution.

 

[Guest]

(e-mail address removed) writes:

I find that odd.  

I'm surprised you find it odd...

If anything, I find it easier to write /large/
functions which do a single thing.

that *I* find odd

 Individual components of it tend to
be more tangled up with each other.

if it's got "components" I'd argue it was too big

 It's as if there's an optimum granularity (which varies
according to exactly what it is I'm actually doing)

with you up to here!

below which either (a) describing the function's purpose and
effects becomes too difficult or

I usually find it easier to describe what a small function
does. Large functions tend to require some sort of
compound sentence to describe them.

(b) you don't actually save anything by calling it.

if you mean time or memory, then no. But there are
other reasons write functions...

As a firm believer in `once and only once' (from before I heard that
slogan attached to it),

me too

I'll strip stuff out into a separate function if
I need it in two places[1].

I thought the idea that this was the only reason to
encapsulate a piece of code in a function died out
in about 1956

 Apart from that, a piece of functionality
has to lift out very cleanly for me to think it's worth separating.

if it can't be lifted out cleanly then maybe the whole
function needs redesigning.

Ok my code isn't composed entirely of cohesive, loosly coupled,
small functions; each of which Does One Thing Well and can
be described with a short, pithy phrase (most likely embedded
in the function's name). But I can dream.

[1] This pursuit also leads me into macrology that leaves some others
    queasy. :-(

ug. macros the 8th plague.


--
Nick Keighley

Programming should never be boring, because anything
mundane and repetitive should be done by the computer.
~Alan Turing

"The best software is simple, elegant, and full of drama"
- Grady Booch

"Programs must be written for people to read, and only
incidentally for machines to execute."
- Abelson & Sussman, Structure and Interpretation of Computer Programs

 

[Stephen Sprunk]

The idea of structured programming was developed to deal with a very
real problem. Following the precepts of structure programming absolutely
is a a less-than ideal solution to that problem.

Rules can be good because they simplify things. However, to be truly
effective, one must understand why the rules exist, when they should not
apply, and therefore when it is acceptable to break them. Slavish
obedience does you no good in the long run...

S

 

[Guest]

how so an advantage?

As you said in your reply "there tends to be some sort of ptr-to-context
being passed around.".  I see this as good design, cooperating functions
operating on a shared state.  It's much easier to test and add
functionality once the state in separated [from] the actions.

not very OO is it