
Good code is cheap code - dicka_j
http://www.geekm.ag/Archive/Good_code_is_cheap_code
======
BerislavLopac
I've started seeing design patterns in a vastly different light once I
realised that, in PHP, all of the Abstract Factory pattern can be replaced by
a simple:

    
    
        $instance = new $className();

~~~
thefreshteapot
Im not quite sure what you mean. Would you like to expand a little more?

~~~
kia
He means that instead of implementing an Abstract Factory for creation of
related objects you can simply use plain old KISS new keyword.

~~~
InclinedPlane
He's saying that PHP's ability to dynamically instantiate classes by using
class-names stored in string variables obviates the need for more complex
factory based patterns.

Schlepping around a particular factory instance is akin to keeping track of
the class one desires to instantiate, which is easily achieved in PHP through
the use of a string.

A lot of the canonical design patterns are applicable only for harshly
statically typed languages such as Java, for dynamic languages like PHP many
of those patterns are no longer applicable or useful. It's still quite
possible to be a cargo cult programmer even if you happen to be using
highfalutin' GoF design patterns.

------
nazgulnarsil
amortize "cheap" over the expected lifetime of the code. If man hours to write
is the primary criteria then you'll have an uncommented mess of crap. I doubt
the author means for this to be taken to the extreme. It makes for a good
sound bite, but there is no simple rule of thumb when deciding how much effort
to allocate to various parts of a project.

------
InclinedPlane
He's right. Most of the expense in software development goes into bad code.

Consider: good code is less buggy, easier to debug when there is a problem,
easier to maintain, easier to modify, easier to understand, etc. When devs
work on good code it takes less effort and there are fewer problems so
projects are done sooner. Good code is like a repellent for developer effort.
Sometimes good code doesn't even need updating or maintenance, it just keeps
working from version to version. In contrast, bad code is typically a time and
effort sink. And because it's so difficult to work with, bad code typically
doesn't improve in quality (merely in functionality) so it becomes more and
more of an effort sink over time.

Time is money, developers spend more of their time mired in bad code, thus bad
code is more expensive.

------
jasonkester
Full title: Good code is cheap code, provided you substitute the following
non-standard definitions for "cheap" and "good".

How about instead, you simply say what you're saying, without forcing the rest
of us to do algebra on the language:

"Maintainable code is brief" pretty much summarizes that entire article. Note,
however, that if you'd used that as the title we wouldn't have needed all
those paragraphs of definitions.

------
maeon3
What has been helping me out is the phrase: "Code that cannot fail is
infinitely easier to maintain then code that has many paths through it which
might fail."

Murphy's law: "What can go wrong WILL go wrong". So go over every line of code
and ask: "How might this function do something unintended?". If you find any
answer to that question then you need to change how the function works until
the answer is: "This function physically cannot do something unintended". If
the hardware and compiler are working to specification then the ONLY path
through this code is the correct way through (or a pretty exception/error that
tells you what the programmer/user did wrong or what the hardware/compiler
failure was).

For example: you have a function calculate() which takes a collection of
Strings which represents items to process. The problem is that function foo()
might run incorrectly and some String items may become invalid or incorrect.
Then calculate() will make its best attempt, then calculate may throw an
exception/error or worst of all, it may work. The solution here is to make it
physically impossible for the items in the list to become invalid/wrong, don't
use an array of String, use an array of class
Student/Airplane/Book/ProcessItem which has a constructor which validates its
own existence as soon as it is made, it will produce a runtime error (or
better yet a compile time error) the instant the programmer/user made a
mistake.

The millions of unintended paths through calculate() which may throw a cryptic
runtime exception has been eliminated. Imagine how much easier it is to
diagnose a "InputProcessItemException" than a cryptic off-by-one error inside
calculate();

