trollish

[RoS]

you are always too secure to be right

one function that do 1000 operation is better than 1000 that have only
one funcionality

example a not bugged standard C sscanf is bettar than all the other
for input all togheter and the str* too

the same a unified way to do input-output: socket , files, pipes etc

**all is easy** only people find a smart way for complicate it
or for not document it or for reject it

 

[Kelsey Bjarnason]

[snips]

you are always too secure to be right

one function that do 1000 operation is better than 1000 that have only
one funcionality

Actually, exactly the opposite is true: it is better to have 1,000 that
each do one job, than one that does 1,000 jobs.

First, the huge 1,000-option function is likely to be much harder to port
and to debug, making it less all-around useful.

Second, it's going to tend to make things big: if I'm working on a small
system, I get this huge function which does 900+ things I don't need,
instead of getting a few small functions which do exactly what I need, and
don't waste space otherwise.

It also tends to make the code cleaner and more maintainable. As a simple
example, if the function can be used to read both strings and single
chars, and I use the "read single char" option, is that what I actually
meant, or did I actually mean to read a string? If I'm calling
get_string(), it's pretty obvious, and if I'm calling get_string but
trying to store the result in a char, or I'm calling get_char() and trying
to store the result via a pointer, chances are the compiler will warn,
where a "multipurpose" function will tend to bypass most such warnings.

 

[RoS]

In data Fri, 21 Dec 2007 04:54:06 -0800, Kelsey Bjarnason scrisse:

[snips]

you are always too secure to be right

one function that do 1000 operation is better than 1000 that have only
one funcionality

Actually, exactly the opposite is true: it is better to have 1,000 that
each do one job, than one that does 1,000 jobs.

but for doing this you have to remember how work 1000 differents
functions (*that always not follow the same rules*)
for example
the rule for errors
the rule for the first argument
the rule for the second argument etc etc

First, the huge 1,000-option function is likely to be much harder to port
and to debug, making it less all-around useful.

it is false

Second, it's going to tend to make things big: if I'm working on a small
system, I get this huge function which does 900+ things I don't need,
instead of getting a few small functions which do exactly what I need, and
don't waste space otherwise.

it is false (true only if you need a reduced functionality)

It also tends to make the code cleaner and more maintainable. As a simple

this is false

example, if the function can be used to read both strings and single
chars, and I use the "read single char" option, is that what I actually
meant, or did I actually mean to read a string? If I'm calling
get_string(), it's pretty obvious, and if I'm calling get_string but
trying to store the result in a char, or I'm calling get_char() and trying
to store the result via a pointer, chances are the compiler will warn,
where a "multipurpose" function will tend to bypass most such warnings.

i see the thing in this way, but it probably i make errors

 

[Richard Heathfield]

RoS said:

In data Fri, 21 Dec 2007 04:54:06 -0800, Kelsey Bjarnason scrisse:

[snips]

you are always too secure to be right

one function that do 1000 operation is better than 1000 that have only
one funcionality

Actually, exactly the opposite is true: it is better to have 1,000 that
each do one job, than one that does 1,000 jobs.

but for doing this you have to remember how work 1000 differents
functions (*that always not follow the same rules*)

The whole point of having functions is that you don't have to remember
their internal workings all the time. On those occasions when you need to
find out, however, it's easier to read a short function than a long one.
At times of maintenance, it's easier to find and fix a problem or outdated
code section in a short function than in a long one - and it's easier to
get a short function working in the first place.

i see the thing in this way, but it probably i make errors

Yes. Your view of code development is not one that will ever gain
widespread acceptance amongst people who know what they're doing.

 

[Richard Bos]

Actually, exactly the opposite is true:

Why are you rtying to educate a piece of rock?

Richard

 

[Default User]

Why are you rtying to educate a piece of rock?

I agree with Richard. Killfile or ignore is the best solution for him,
Kenny, various other trolls and nutters. You will not be able to
logically convince them of anything.



Brian