3 ms·

Declaring functions in another location is the purpose of functions, yes? Otherwise we would code in a purely linear fashion. Some code locality should be sacr

Declaring functions in another location is the purpose of functions, yes? Otherwise we would code in a purely linear fashion. Some code locality should be sacrificed for readability, reuse, and clarity. Not to make a "forest of functions", but to define separate ideas more clearly than stuffing one thought into a parameter of another thought. It's like if I was telling you about something funny that happened when I got to work, but first I have to describe every detail of my drive to work... It's a thread on ineffective coding habits, so I thought I would piggyback with a general question. I regrettably did not pursue an undergrad CS degree, and so sometimes wonder about the gaps in my education such a degree would have filled. Thank you for your time.

Roboprog 9y ago
If the function is large, sure, make it into it's own name thing (with as restricted a scope as you can get away with). However, many languages support callbacks/lambdas/closures/blocks as parameters to generic library code, and these dangly bits are often one or two lines. E.g. (pseudo-code) - * list.for-each : print * list.filter : is-wanted * db-connection.bracket-transaction : compound-update This allows you to use, or create your own, library code as extensions of the language to reduce boiler-plate code for visiting, filtering, resource management, etc. Have a look at something like the Ruby language to see how this is exploited to reduce A LOT of code noise.
- Roboprog 9y ago
  Some might also argue that "private methods", which are visible to every other method in a class, are a bad thing, rather than making a nested function within the only function / method that used said code. One of the things I used to be able to do in Pascal, that C ... Java and their ilk took away. Fortunately, most FP languages gave that back, with interest (closures).
  - int_19h 9y ago
    C# just got true nested functions back in 7.0. Although, as you have said, it is somewhat redundant with closures, and even more so with local type inference. C++, C# and Java all let you do what effectively amounts to a local function these days.

Roboprog 9y ago

If the function is large, sure, make it into it's own name thing (with as restricted a scope as you can get away with). However, many languages support callbacks/lambdas/closures/blocks as parameters to generic library code, and these dangly bits are often one or two lines. E.g. (pseudo-code) - * list.for-each : print * list.filter : is-wanted * db-connection.bracket-transaction : compound-update This allows you to use, or create your own, library code as extensions of the language to reduce boiler-plate code for visiting, filtering, resource management, etc. Have a look at something like the Ruby language to see how this is exploited to reduce A LOT of code noise.

Roboprog 9y ago
Some might also argue that "private methods", which are visible to every other method in a class, are a bad thing, rather than making a nested function within the only function / method that used said code. One of the things I used to be able to do in Pascal, that C ... Java and their ilk took away. Fortunately, most FP languages gave that back, with interest (closures).
- int_19h 9y ago
  C# just got true nested functions back in 7.0. Although, as you have said, it is somewhat redundant with closures, and even more so with local type inference. C++, C# and Java all let you do what effectively amounts to a local function these days.