Return to Answer

added 339 characters in body

edited Mar 6, 2012 at 23:12

29.1k
11
107
119

BecauseBecause, applied to your example:

(+ flexibility) if you ever had to change the behavior of the doStuffX, you'll want to kill yourself or whoever wrote it,
+ readability

Less code often translates to less noise. _{(not always...)}
(+ extensibility) if you had extracted the distinct parts to a data-structure of your choice and then just iterated over it by calling a generic doStuff, you could just as well add one line in your data structure where you want a new entry, or remove one, and changing the behavior will just mean editing doStuff
+ flexibility

If you ever had to change the behavior of the doStuffX, you'll want to kill yourself or whoever wrote it,
(+ cost efficiency) less code
+ extensibility

If you had extracted the distinct parts to a data-structure of your choice and then just iterated over it by calling a generic doStuff, you could just as well add one line in your data structure where you want a new entry, or remove one, and changing the behavior will just mean editing doStuff. Easier to maintain.

+ cost efficiency

less code here means:
- => less development => reduced cost
- => less probability for bugs => less support time => reduced cost
(+ possible managed optimization) depending on the language, the compiler/interpreter might have a bigger chance of determining that generic doStuff does always the nearly identical things often one call after another, and could inline it or attempt to optimize it. Probably wouldn't for X variations of doStuffX)
+ (possible) managed optimization

Depending on the language, the compiler/interpreter might have a bigger chance of determining that generic doStuff does always the nearly identical things often one call after another, and could inline it or attempt to optimize it. Probably wouldn't for X variations of doStuffX.
(+ testing and quality) testing is easier: doStuff needs testing, and that's it (well, not exactly, but that covers already _more. Only its IO expectations vary and need to be tested under different conditions, but it's still a lot easier to test (and more maintainable) than all the variations of doStuffX
+ testing and quality

Testing is easier: doStuff needs testing, and that's it. Well, not exactly, but that covers already more. Only its IO expectations vary and need to be tested under different conditions, but it's still a lot easier to test and more maintainable than all the variations of doStuffX.

Overall this accounts for more maintainable code and an improved development efficiency for your team, and it is one of many good practices to help you produce more robust and dependable software.

Because, applied to your example:

(+ flexibility) if you ever had to change the behavior of the doStuffX, you'll want to kill yourself or whoever wrote it,
(+ extensibility) if you had extracted the distinct parts to a data-structure of your choice and then just iterated over it by calling a generic doStuff, you could just as well add one line in your data structure where you want a new entry, or remove one, and changing the behavior will just mean editing doStuff
(+ cost efficiency) less code
- => less development => reduced cost
- => less probability for bugs => less support time => reduced cost
(+ possible managed optimization) depending on the language, the compiler/interpreter might have a bigger chance of determining that generic doStuff does always the nearly identical things often one call after another, and could inline it or attempt to optimize it. Probably wouldn't for X variations of doStuffX)
(+ testing and quality) testing is easier: doStuff needs testing, and that's it (well, not exactly, but that covers already _more. Only its IO expectations vary and need to be tested under different conditions, but it's still a lot easier to test (and more maintainable) than all the variations of doStuffX

Because, applied to your example:

+ readability

Less code often translates to less noise. _{(not always...)}
+ flexibility

If you ever had to change the behavior of the doStuffX, you'll want to kill yourself or whoever wrote it,
+ extensibility

If you had extracted the distinct parts to a data-structure of your choice and then just iterated over it by calling a generic doStuff, you could just as well add one line in your data structure where you want a new entry, or remove one, and changing the behavior will just mean editing doStuff. Easier to maintain.

+ cost efficiency

less code here means:
- => less development => reduced cost
- => less probability for bugs => less support time => reduced cost
+ (possible) managed optimization

Depending on the language, the compiler/interpreter might have a bigger chance of determining that generic doStuff does always the nearly identical things often one call after another, and could inline it or attempt to optimize it. Probably wouldn't for X variations of doStuffX.
+ testing and quality

Testing is easier: doStuff needs testing, and that's it. Well, not exactly, but that covers already more. Only its IO expectations vary and need to be tested under different conditions, but it's still a lot easier to test and more maintainable than all the variations of doStuffX.

Rewrote some of that for clarity and emphasis

Source Link

edited Feb 16, 2012 at 1:35

haylem

29.1k
11
107
119

Because, inapplied to your example:

(+ flexibility) if you ever had to change the behavior of the doStuffXdoStuffX, you'll want to kill yourself or whoever wrote it,
(+ extensibility) if you addhad extracted the distinct parts to a data-structure of your choice and then just iterated over it by calling a generic doStuffdoStuff, you could just as well add one line in your data structure where you want a new entry, or remove one, and changing the behavior will just mean editing doStuff

less code => less development => reduced costdoStuff
less code => less probability for bugs => less support time => reduced cost(+ cost efficiency) less code
- => less development => reduced cost
- => less probability for bugs => less support time => reduced cost
(+ possible managed optimization) depending on the language, the compiler/interpreter might have a bigger chance of determining that generic doStuffdoStuff does always the nearly identical things often one call after another, and could inline it or attempt to optimize it. Probably wouldn't for X variations of doStuffXdoStuffX)
(+ testing and quality) testing is easier: doStuffdoStuff needs testing, and that's it (well, not exactly, but that covers already _more. Only its IO expectations vary and need to be tested under different conditions, but it's still a lot easier to testa lot easier to test (and more maintainablemore maintainable) than all the variations of dotuffXdoStuffX

Because, in your example:

if you ever had to change the behavior of the doStuffX, you'll want to kill yourself or whoever wrote it,
if you add extracted the distinct parts to a data-structure of your choice and then just iterated over it by calling a generic doStuff, you could just as well add one line in your data structure where you want a new entry, or remove one, and changing the behavior will just mean editing doStuff

less code => less development => reduced cost
less code => less probability for bugs => less support time => reduced cost
depending on the language, the compiler/interpreter might have a bigger chance of determining that generic doStuff does always the nearly identical things often one call after another, and could inline it or attempt to optimize it. Probably wouldn't for X variations of doStuffX)
testing is easier: doStuff needs testing, and that's it. Only its IO expectations vary and need to be tested under different conditions, but it's still a lot easier to test (and more maintainable) than all the variations of dotuffX

Because, applied to your example:

(+ flexibility) if you ever had to change the behavior of the doStuffX, you'll want to kill yourself or whoever wrote it,
(+ extensibility) if you had extracted the distinct parts to a data-structure of your choice and then just iterated over it by calling a generic doStuff, you could just as well add one line in your data structure where you want a new entry, or remove one, and changing the behavior will just mean editing doStuff
(+ cost efficiency) less code
- => less development => reduced cost
- => less probability for bugs => less support time => reduced cost
(+ possible managed optimization) depending on the language, the compiler/interpreter might have a bigger chance of determining that generic doStuff does always the nearly identical things often one call after another, and could inline it or attempt to optimize it. Probably wouldn't for X variations of doStuffX)
(+ testing and quality) testing is easier: doStuff needs testing, and that's it (well, not exactly, but that covers already _more. Only its IO expectations vary and need to be tested under different conditions, but it's still a lot easier to test (and more maintainable) than all the variations of doStuffX

Source Link

answered Aug 24, 2011 at 2:06

haylem

29.1k
11
107
119

Because, in your example:

if you ever had to change the behavior of the doStuffX, you'll want to kill yourself or whoever wrote it,
if you add extracted the distinct parts to a data-structure of your choice and then just iterated over it by calling a generic doStuff, you could just as well add one line in your data structure where you want a new entry, or remove one, and changing the behavior will just mean editing doStuff
less code => less development => reduced cost
less code => less probability for bugs => less support time => reduced cost
depending on the language, the compiler/interpreter might have a bigger chance of determining that generic doStuff does always the nearly identical things often one call after another, and could inline it or attempt to optimize it. Probably wouldn't for X variations of doStuffX)
testing is easier: doStuff needs testing, and that's it. Only its IO expectations vary and need to be tested under different conditions, but it's still a lot easier to test (and more maintainable) than all the variations of dotuffX