Best Coding Practice

On Aug 24, 5:41 am, "burgermeiste...@gmail.com"
<burgermeiste...@gmail.com> wrote:
> 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?

I will choose option 2.

Or better store it like this:

array (
[0]
type=>free
prod=>pid
[1]
type=>paid
prod=pid

)


http://satya61229.blogspot.com

On Aug 24, 5:41 am, "burgermeiste...@gmail.com"
<burgermeiste...@gmail.com> wrote:
<snip>
> #1.
> public function addArrayA($object){
> //logic
> $a[] = $object;
>
> }
>
> public function addArrayB($object){
> //same logic
> $b[] = $object;
>
> }

This may be a good solution for just 2 object arrays. But, for some
generalization, I'd prefer:
public function addArray($object, $key='a'){
$arr[$key][] = $object;
}

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

R. Rajesh Jeba Anbiah wrote:
> On Aug 24, 5:41 am, "burgermeiste...@gmail.com"
> <burgermeiste...@gmail.com> wrote:
> <snip>
>> #1.
>> public function addArrayA($object){
>> //logic
>> $a[] = $object;
>>
>> }
>>
>> public function addArrayB($object){
>> //same logic
>> $b[] = $object;
>>
>> }
>
> This may be a good solution for just 2 object arrays. But, for some
> generalization, I'd prefer:
> public function addArray($object, $key='a'){
> $arr[$key][] = $object;
> }
>
> --
> <?php echo 'Just another PHP saint'; ?>
> Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/
>

But this creates much more problems - like keeping track of keys, etc.

Better would be having one array in the object with an "Add" function.
If you need two different arrays, create two different objects.

And if you need to relate the objects, have a second class which allows
you to add as many of these objects as you wish.

This allows as many arrays as the user needs without having to worry
about ensuring you have the correct keys, etc.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

In article <37tzi.25409$4A1.3675@news-server.bigpond.net.au>,
"rf" <rf@invalid.com> wrote:

> "Sanders Kaufman" <bucky@kaufman.net> wrote in message
> news:nHszi.4651$LL7.2735@nlpi069.nbdc.sbc.com...
> > rf wrote:
> >> "Sanders Kaufman" <bucky@kaufman.net> wrote in message
> >
> >>> Refactoring?
> >>> What's that?
> >>
> >> http://www.google.com.au/search?q=refactoring
> >
> > http://en.wikipedia.org/wiki/Refactoring
> >
> > Oh, I get it. It's a politically-correct, bidness-safe way of saying you
> > did something fundamentally wrong and have to re-design the whole damned
> > thing.
>
> No it is most definately not. If you had read and understood the above
> article you would know that.
>
> While you are looking again at the article you may wish to follow the link
> to Extreme Programming, of which refactoring is an integral component.
>
> This is not, of course, programming 101. It's many levels above that.

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.

In article <KFRzi.25911$4A1.12032@news-server.bigpond.net.au>,
"rf" <rf@invalid.com> wrote:

> "Sanders Kaufman" <bucky@kaufman.net> wrote in message
> news:whNzi.24$FO2.2@newssvr14.news.prodigy.net...
> > Jerry Stuckle wrote:
> >
> >> No, refactoring is changing the implementation without changing the
> >> interface.
> >>
> >> IOW, you change HOW you do things, but not WHAT you do. You changed the
> >> interface.
> >>
> >> An example of refactoring would be to change a class so that it gets its
> >> data from a relational database instead of a flat file. The function
> >> calls (interface) remain the same, but the code in the functions
> >> (implementation) changes.
> >>
> >> Refactoring in OO would mean you would not have to change anything
> >> outside of the class itself.
> >
> > Ahh - so when I had to use new kinds of parameters - I was rewriting. But
> > if I'd made it all zero-impact on how it's used, it would have been
> > refactoring.
> >
> > I don't get it. I can repeat it and rephrase it. But I don't get it.
>
> This is a real example, taken from the 1970's but still valid.
>
> A function was required to invert a matrix. The programmer decided to use
> one method [1] which worked perfectly on the 6x6 test matrix. However when a
> real world matrix was fed to the function took too long (estimates (by IBM)
> were that for a 30x30 matrix it would have taken, with the then current
> hardware, thousands of years to complete).
>
> The function was refactored to use a different [2] method, which inverted
> the 30x20 matrix in seconds.
>
> This was _not_ fixing a bug, or even a programming mistake. It was changing
> internals of the function to use a more efficient algorithm. Nothing in the
> functions interface changed.

So it was re-written. Why not say that and avoid the bullshit.

On May 7, 2:56 pm, Tim Streater <timstrea...@waitrose.com> wrote:
> In article <KFRzi.25911$4A1.12...@news-server.bigpond.net.au>,
>
>
>
> "rf" <r...@invalid.com> wrote:
> > "Sanders Kaufman" <bu...@kaufman.net> wrote in message
> >news:whNzi.24$FO2.2@newssvr14.news.prodigy.net. ..
> > > Jerry Stuckle wrote:
>
> > >> No, refactoring is changing the implementation without changing the
> > >> interface.
>
> > >> IOW, you change HOW you do things, but not WHAT you do. You changed the
> > >> interface.
>
> > >> An example of refactoring would be to change a class so that it gets its
> > >> data from a relational database instead of a flat file. The function
> > >> calls (interface) remain the same, but the code in the functions
> > >> (implementation) changes.
>
> > >> Refactoring in OO would mean you would not have to change anything
> > >> outside of the class itself.
>
> > > Ahh - so when I had to use new kinds of parameters - I was rewriting. But
> > > if I'd made it all zero-impact on how it's used, it would have been
> > > refactoring.
>
> > > I don't get it. I can repeat it and rephrase it. But I don't get it.
>
> > This is a real example, taken from the 1970's but still valid.
>
> > A function was required to invert a matrix. The programmer decided to use
> > one method [1] which worked perfectly on the 6x6 test matrix. However when a
> > real world matrix was fed to the function took too long (estimates (by IBM)
> > were that for a 30x30 matrix it would have taken, with the then current
> > hardware, thousands of years to complete).
>
> > The function was refactored to use a different [2] method, which inverted
> > the 30x20 matrix in seconds.
>
> > This was _not_ fixing a bug, or even a programming mistake. It was changing
> > internals of the function to use a more efficient algorithm. Nothing in the
> > functions interface changed.
>
> So it was re-written. Why not say that and avoid the bullshit.

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