Best Coding Practice

First, let me say that this question is a rather general programming
question, but the context is PHP, so I figured this group would have
the most relevant insight.

Anyways, this is also more of an opinion based question than one
seeking a definite answer. Recently, while maintaining a rather large
system. I needed to add an array class member to an object. It was
exactly the same as another class member, except that one array stored
regular products, and the other stored free promotional products. As
such, I needed a way to add products to the new, free array. Since all
the logic was the same between the two arrays aside from the price, I
had a few different options to do this. I'm interested in polling
which way some of the group members feel would have been the best.
Naturally these are abbreviated versions of what I envisioned as
possible solutions.
#1.
public function addArrayA($object){
//logic
$a[] = $object;
}

public function addArrayB($object){
//same logic
$b[] = $object;
}


#2. (These next two are arranged as such, because the class using
these functions is included in many script files,
all of which I may not be aware of, so there would have to be some
default value for the array that was always used
before this new array was needed)
public function addArray($object, $free = NULL){
//logic
if(!$free){
$a[] = $object;
}else{
$b[] = $object;
}
}

or

#3
public function addArray($object, $arr = "a"){
//logic
$$arr[] = $object;
}



I ended up going with option number 1, because I felt that despite the
inefficient, redundant code it would later be more readable to other
programmers that might work on the project. Additionally, I didn't
feel wholly comfortable with default variables being the only
difference between a full price product and a free product. Thoughts?

re: Best Coding Practice

In article <37tzi.25409$4A1.3675@news-server.bigpond.net.au>,
"rf" <rf@invalid.comwrote:
Hmmm, had a quick look at this. Not sure I can see how it differs from
simple best practice. I would call it programming defensively so as not
to get in a mess.

Or is there some big deal I am missing.

re: Best Coding Practice

In article <KFRzi.25911$4A1.12032@news-server.bigpond.net.au>,
"rf" <rf@invalid.comwrote:
So it was re-written. Why not say that and avoid the bullshit.

re: Best Coding Practice

On May 7, 2:56 pm, Tim Streater <timstrea...@waitrose.comwrote:Awesome! Resurrecting a conversation almost a year old!

Well, my stance on calling it 'refactoring' rather than 'internal code
re-written to keep the code scaleable/maintainable/etc' serves a
couple purposes:

First, 'refactoring' means something specific. Not just 're-written',
not just 'debugging'. I personally feel the best person to define
what code refactoring means is Martin Fowler http://www.refactoring.com/
(I'm not saying this looking for a fight, just my opinion). After
reading a little about what refactoring really is, you can see that it
means something different than simple 're-writing'.

Second, it goes along with one of the core reasons we have Design
Patterns - it gives the programmers a language to use to mean specific
things quickly and without having to elaborate. I guess this goes
along with my first point a bit, but bear with me. It is much easier
to say "We'll need to consider refactoring xyz component before we
extend its functionalities" than it is to say "We'll need to review
the architecture and design of the xyz component and see how it is
specifically implemented in regards to its internal interfaces with
sub-components (etc) before we extend its functionalities".

Everyone is welcome to their opinion, and if they feel 'refactoring'
is synonymous with 're-writing' that's fine...as long as your team and
customers understand what you mean. But, if you join my team, you can
be sure that we will use the term 'refactoring' and 're-writing' as
meaning two separate things. Re-writing is when you need to retain
the functionality of a component, but there is no hope in refactoring
the existing (it is so terrible, it will take less resources to throw
it out and start over). Re-writing is NOT the ideal way of doing
things, especially if your code is evolved.

In short, it could be boiled down to something my father said many
times when I was younger 'Say what you mean and mean what you say' (I
know he didn't coin this, but he did say this).

Regards,

Steve