Best Coding Practice

[burgermeister01]

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($obje ct){
//logic
$a[] = $object;
}

public function addArrayB($obje ct){
//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($objec t, $free = NULL){
//logic
if(!$free){
$a[] = $object;
}else{
$b[] = $object;
}
}

or

#3
public function addArray($objec t, $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?

[Michael Fesser]

..oO(Jerry Stuckle)

>But if you change the function name, parameter list and/or return value,
you have to change all of the code calling it. This is NOT refactoring.

http://en.wikipedia.org/wiki/Rename_Method

http://www.refactoring.com/catalog/renameMethod.html

Micha

[Jerry Stuckle]

Michael Fesser wrote:

.oO(Jerry Stuckle)

>But if you change the function name, parameter list and/or return value,
you have to change all of the code calling it. This is NOT refactoring.

http://en.wikipedia.org/wiki/Rename_Method

http://www.refactoring.com/catalog/renameMethod.html

Micha

And that's where I disagree with the author of the refactoring site.
But that's one person's opinion. Other people who have written about
refactoring

Changing the name of a function which is externally available is
changing the behavior. It means changing every piece of code which
calls the function.

For instance, between Apache 1.x and 2.x, the Apache foundation changed
some of the function calls. This causes problems with any modules which
call those functions.

By your argument, ZEND should change the fopen() call to be file_open().
How much code would that affect?

Rather, they might change the code to make it more efficient and not
change the function name. This is refactoring.

But the author is correct - there is very little information available
on refactoring. In some ways the site is good. But in other ways it
contains incorrect information.

As to the Wikipedia page - I have no idea who wrote this page. Was it
the same person? Or someone else without a good idea about it? Anyone
can create a page there. I could create one which says the sun rises in
the west. Does this make it so?

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Sanders Kaufman]

Dikkie Dik wrote:

>No, refactoring is changing the implementation without changing the
interface.

Please read the book before you utter nonsense.

Refactoring is changing the _structure_ of the code without changing the
_behaviour_ of that code. So interface changes can be refactorings.

Actually, refactor is a mathematical principle whose definition doesn't
even *address* the programming world.

I think you confuse with the Open Closed Principle. The Open Closed
Principle and refactoring are perpendicular ways to adapt code in a
_controlled_ fashion: The Open Closed Principle leaves the structure
intact, while refactoring makes sure the code behaviour remains the same
while you are restructuring it.

Perpendicular.. . Open Closed Principle... blecchh.

Might just as well call them the Democrat, Libertarian and Republican
methods - for all the clarity it brings.

[Sanders Kaufman]

Jerry Stuckle wrote:

And that's where I disagree with the author of the refactoring site. But
that's one person's opinion. Other people who have written about
refactoring

That's the way these discussions usually end up.
You get a bunch of folks who take a word like gigglethorpe, and each
assigns to it a meaning comfortable to himself. Then they argue which
one is the "true" meaning.

After digging in, I find that refactor is not an "opinion" word - it s a
mathematical term.

It was hijacked by some MBA's a few years ago, and incorporated into
their political philosophies on programming... like a logo.

[Steve]

"Michael Fesser" <ne*****@gmx.de wrote in message
news:cn******** *************** *********@4ax.c om...
| .oO(Jerry Stuckle)
|
| >But if you change the function name, parameter list and/or return value,
| >you have to change all of the code calling it. This is NOT refactoring.
|
| http://en.wikipedia.org/wiki/Rename_Method
|
| http://www.refactoring.com/catalog/renameMethod.html

apparently, i'm not up on my lingo.

so what if i change an interface with optional parameters? i then don't need
to change *any* calling code, yet i've changed the interface. is this now
refactoring? further, most php is not written in OOP but with proceedural
code. so, the 'interface' would be a browser, in most cases. technically, i
could change any and all code yet not be mucking with the 'interface'. and
so that we're all clear...an 'interface' *only* exists as a communication
point between a caller and an *OBJECT*. functions alone and of themselves
are NOT interfaces.

as far as i'm concerned, when i 'refactor', i'm doing whatever needs to be
done to existing code to make it better for no other reason (new
enhancement, new logical/business requirement, etc.) than to make it better
(easier to maintain, bring it under standards of practice, make it faster,
etc.). imo, it's not worth splitting hairs over. i suppose it is a good
thing that when my boss and i talk about 'refactoring' some code, we
understand each other...which is the whole point of a word.

like i said before, there's no corner on any of this. 'extreme' programming
is an *OLD* construct under a new, stupid name.

but that's just my 0.02 usd and i appologise if i have stepped on someone
else's sacred cow. ;^)

[Jerry Stuckle]

Steve wrote:

"Michael Fesser" <ne*****@gmx.de wrote in message
news:cn******** *************** *********@4ax.c om...
| .oO(Jerry Stuckle)
|
| >But if you change the function name, parameter list and/or return value,
| >you have to change all of the code calling it. This is NOT refactoring.
|
| http://en.wikipedia.org/wiki/Rename_Method
|
| http://www.refactoring.com/catalog/renameMethod.html

apparently, i'm not up on my lingo.

so what if i change an interface with optional parameters? i then don't need
to change *any* calling code, yet i've changed the interface. is this now
refactoring? further, most php is not written in OOP but with proceedural
code. so, the 'interface' would be a browser, in most cases. technically, i
could change any and all code yet not be mucking with the 'interface'. and
so that we're all clear...an 'interface' *only* exists as a communication
point between a caller and an *OBJECT*. functions alone and of themselves
are NOT interfaces.

OK, I should have clarified - you can't change the interface except to
*extend* it. Adding optional parameters would be extending the interface.

In this case, the "interface" wouldn't be the browser - the browser has
nothing to do with PHP. Rather, it would be the common function calls.
Interfaces existed long before OO programming! For instance, fopen()
is an interface to the file system.

as far as i'm concerned, when i 'refactor', i'm doing whatever needs to be
done to existing code to make it better for no other reason (new
enhancement, new logical/business requirement, etc.) than to make it better
(easier to maintain, bring it under standards of practice, make it faster,
etc.). imo, it's not worth splitting hairs over. i suppose it is a good
thing that when my boss and i talk about 'refactoring' some code, we
understand each other...which is the whole point of a word.

Then how do you differ between "refactorin g" and "rewriting" ? There is
a difference!

like i said before, there's no corner on any of this. 'extreme' programming
is an *OLD* construct under a new, stupid name.

but that's just my 0.02 usd and i appologise if i have stepped on someone
else's sacred cow. ;^)

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Steve]

"Jerry Stuckle" <js*******@attg lobal.netwrote in message
news:W5******** *************** *******@comcast .com...
| Steve wrote:
| "Michael Fesser" <ne*****@gmx.de wrote in message
| news:cn******** *************** *********@4ax.c om...
| | .oO(Jerry Stuckle)
| |
| | >But if you change the function name, parameter list and/or return
value,
| | >you have to change all of the code calling it. This is NOT
refactoring.
| |
| | http://en.wikipedia.org/wiki/Rename_Method
| |
| | http://www.refactoring.com/catalog/renameMethod.html
| >
| apparently, i'm not up on my lingo.
| >
| so what if i change an interface with optional parameters? i then don't
need
| to change *any* calling code, yet i've changed the interface. is this
now
| refactoring? further, most php is not written in OOP but with
proceedural
| code. so, the 'interface' would be a browser, in most cases.
technically, i
| could change any and all code yet not be mucking with the 'interface'.
and
| so that we're all clear...an 'interface' *only* exists as a
communication
| point between a caller and an *OBJECT*. functions alone and of
themselves
| are NOT interfaces.
| >
|
| OK, I should have clarified - you can't change the interface except to
| *extend* it. Adding optional parameters would be extending the interface.
|
| In this case, the "interface" wouldn't be the browser - the browser has
| nothing to do with PHP. Rather, it would be the common function calls.
| Interfaces existed long before OO programming! For instance, fopen()
| is an interface to the file system.

well, the op was regarding best programming practices in gereral. either
way, the user interface is very much a part of any language whether it is a
command-line or gui. in general, especially in case of the command-line, it
is equally effected by such changes (think of argument changes or command
name changes). i understand the difference between what we're talking about
and this idea, but the two don't always have a black/white distinction. the
main point i was trying to make is that functions are not interfaces, and if
they are - such as fopen being an 'interface' to the file system - then so
too are the methods a user interacts with in an application - their (caller)
way into accessing a set of features ('interfaces'). such an equation
doesn't help in distinguishing development tasks.
| as far as i'm concerned, when i 'refactor', i'm doing whatever needs to
be
| done to existing code to make it better for no other reason (new
| enhancement, new logical/business requirement, etc.) than to make it
better
| (easier to maintain, bring it under standards of practice, make it
faster,
| etc.). imo, it's not worth splitting hairs over. i suppose it is a good
| thing that when my boss and i talk about 'refactoring' some code, we
| understand each other...which is the whole point of a word.
| >
|
| Then how do you differ between "refactorin g" and "rewriting" ? There is
| a difference!

besides symantics, what is the superior definition and use of 'refactoring'.
anytime you 'refactor' code, you 'rewrite' it. i'm fine, as an employer,
when a developer says, 'i redid/willdo this to do/behave/help with this...it
impacted (will impact) this/these things.' THAT is more meaningful than
EITHER term. moreover, i just don't thing 'redid' and 'willdo' would have
sounded very 'extreme' and hence was not included in the book(s). ;^)

when discussing changes that need to be made in code with a client, i don't
use either term. i talk about things he understands like speed, flexibility,
longevity, scale, and costs (both long and short-term). when discussing
changes with my boss, i talk about strategy and architecture. and with my
employees, i talk about what i need done specific to all of the above...and
if in the course of their changes, they see a pattern, potential problem, or
oportunity that should be addressed, we get down to *specifics*...n ot lingo.

but that's just me. everything is a rewrite...or an origination. what
benefit is it to anyone to split hairs over a term that is itself, already
controvertial and unclear?

don't get me wrong, jerry. i think saunders kaufman has his head squarely up
his ass, which explains why he's 'in the dark' on this topic. however, i've
done all the 'extreme' stuff including paired programming, bidding, etc.. as
i've said, it comes from common practices in other fields all the way back
to the early 1900's. ain't nothn' 'extreme' about it as far as programming
is concerned. as for the lingo associated with it, may it forever be limited
to the context of the book that espoused it. for me, i use specifics when i
need someone else to understand what i'm doing or what they need to do.
'refactoring' is not specific enough.

if it works for someone else, i'm glad.

cheers.

[Sanders Kaufman]

Steve wrote:

"Jerry Stuckle" <js*******@attg lobal.netwrote in message

but that's just me. everything is a rewrite...or an origination. what
benefit is it to anyone to split hairs over a term that is itself, already
controvertial and unclear?

don't get me wrong, jerry. i think saunders kaufman has his head squarely up
his ass, which explains why he's 'in the dark' on this topic. however, i've
done all the 'extreme' stuff including paired programming, bidding, etc.. as
i've said, it comes from common practices in other fields all the way back
to the early 1900's. ain't nothn' 'extreme' about it as far as programming
is concerned. as for the lingo associated with it, may it forever be limited
to the context of the book that espoused it. for me, i use specifics when i
need someone else to understand what i'm doing or what they need to do.
'refactoring' is not specific enough.

It's always so wild when someone STARTS by saying I have my head up my
butt, and then GOES ON to say why they agree with me about stuff.

But I wonder - what is it about the nature of this industry that seems
draw such self-contradictory folks in *droves*.

I mean, if it was just here and there, it would be one thing. But our
industry has become somewhat of a national joke because of this kind of
bad character.

I'm not a very good coder - probably never will be - but I get a lot of
gigs where the client says something like, "Hey, your not as belligerent
as the last 12 web developers I hired" or "Wow, that's pretty
straight-forward. How come the last 8 developers couldn't say it that
plainly?".

The reason is obvious, would you rather hire a genius to belittle you,
your company and your project - or a half-wit who will get the job done.

[Jerry Stuckle]

Steve wrote:

"Jerry Stuckle" <js*******@attg lobal.netwrote in message
news:W5******** *************** *******@comcast .com...
| Steve wrote:
| "Michael Fesser" <ne*****@gmx.de wrote in message
| news:cn******** *************** *********@4ax.c om...
| | .oO(Jerry Stuckle)
| |
| | >But if you change the function name, parameter list and/or return
value,
| | >you have to change all of the code calling it. This is NOT
refactoring.
| |
| | http://en.wikipedia.org/wiki/Rename_Method
| |
| | http://www.refactoring.com/catalog/renameMethod.html
| >
| apparently, i'm not up on my lingo.
| >
| so what if i change an interface with optional parameters? i then don't
need
| to change *any* calling code, yet i've changed the interface. is this
now
| refactoring? further, most php is not written in OOP but with
proceedural
| code. so, the 'interface' would be a browser, in most cases.
technically, i
| could change any and all code yet not be mucking with the 'interface'.
and
| so that we're all clear...an 'interface' *only* exists as a
communication
| point between a caller and an *OBJECT*. functions alone and of
themselves
| are NOT interfaces.
| >
|
| OK, I should have clarified - you can't change the interface except to
| *extend* it. Adding optional parameters would be extending the interface.
|
| In this case, the "interface" wouldn't be the browser - the browser has
| nothing to do with PHP. Rather, it would be the common function calls.
| Interfaces existed long before OO programming! For instance, fopen()
| is an interface to the file system.

well, the op was regarding best programming practices in gereral. either
way, the user interface is very much a part of any language whether it is a
command-line or gui. in general, especially in case of the command-line, it
is equally effected by such changes (think of argument changes or command
name changes). i understand the difference between what we're talking about
and this idea, but the two don't always have a black/white distinction. the
main point i was trying to make is that functions are not interfaces, and if
they are - such as fopen being an 'interface' to the file system - then so
too are the methods a user interacts with in an application - their (caller)
way into accessing a set of features ('interfaces'). such an equation
doesn't help in distinguishing development tasks.

Actually, functions have always been defined as interfaces. Even before
OO programming came along, it was common to build a library of functions
to perform a set of actions - similar to the file calls in PHP and C.

And yes, the methods a user interacts with an application is an
interface - widely known as the "user interface".

>
| as far as i'm concerned, when i 'refactor', i'm doing whatever needs to
be
| done to existing code to make it better for no other reason (new
| enhancement, new logical/business requirement, etc.) than to make it
better
| (easier to maintain, bring it under standards of practice, make it
faster,
| etc.). imo, it's not worth splitting hairs over. i suppose it is a good
| thing that when my boss and i talk about 'refactoring' some code, we
| understand each other...which is the whole point of a word.
| >
|
| Then how do you differ between "refactorin g" and "rewriting" ? There is
| a difference!

besides symantics, what is the superior definition and use of 'refactoring'.
anytime you 'refactor' code, you 'rewrite' it. i'm fine, as an employer,
when a developer says, 'i redid/willdo this to do/behave/help with this...it
impacted (will impact) this/these things.' THAT is more meaningful than
EITHER term. moreover, i just don't thing 'redid' and 'willdo' would have
sounded very 'extreme' and hence was not included in the book(s). ;^)

Yes and no. Refactoring typically is more limited - for instance,
recoding a function, set of functions, class, etc., without having to
change code which calls those functions or class members.

when discussing changes that need to be made in code with a client, i don't
use either term. i talk about things he understands like speed, flexibility,
longevity, scale, and costs (both long and short-term). when discussing
changes with my boss, i talk about strategy and architecture. and with my
employees, i talk about what i need done specific to all of the above...and
if in the course of their changes, they see a pattern, potential problem, or
oportunity that should be addressed, we get down to *specifics*...n ot lingo.

I do the same. I don't even talk about "rewriting" the code. I don't
even talk about architecture, and the only strategy is that which has to
be in place to get the job done. Rather, I talk about the benefits he
will receive from whatever I'm going to do.

but that's just me. everything is a rewrite...or an origination. what
benefit is it to anyone to split hairs over a term that is itself, already
controvertial and unclear?

It's fun? :-) But you're right, it's not really worth splitting hairs over.

don't get me wrong, jerry. i think saunders kaufman has his head squarely up
his ass, which explains why he's 'in the dark' on this topic. however, i've
done all the 'extreme' stuff including paired programming, bidding, etc.. as
i've said, it comes from common practices in other fields all the way back
to the early 1900's. ain't nothn' 'extreme' about it as far as programming
is concerned. as for the lingo associated with it, may it forever be limited
to the context of the book that espoused it. for me, i use specifics when i
need someone else to understand what i'm doing or what they need to do.
'refactoring' is not specific enough.

I think Sanders is just being honest when he says he's in the dark about
it. I think most programmers are.

And I also agree there is no "extreme programming". There are "extreme
sports", which can only be done by someone in excellent physical
condition, lots of practice and a willingness to die. But virtually any
programming can be done by a competent programmer versed in the
language, tools, etc. to be used. It just takes some people longer than
others.

if it works for someone else, i'm glad.

Yep.

cheers.

Caio!

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Steve]

"Sanders Kaufman" <bu***@kaufman. netwrote in message
news:Ff******** *******@newssvr 22.news.prodigy .net...
| Steve wrote:
| "Jerry Stuckle" <js*******@attg lobal.netwrote in message
|
| but that's just me. everything is a rewrite...or an origination. what
| benefit is it to anyone to split hairs over a term that is itself,
already
| controvertial and unclear?
| >
| don't get me wrong, jerry. i think saunders kaufman has his head
squarely up
| his ass, which explains why he's 'in the dark' on this topic. however,
i've
| done all the 'extreme' stuff including paired programming, bidding,
etc.. as
| i've said, it comes from common practices in other fields all the way
back
| to the early 1900's. ain't nothn' 'extreme' about it as far as
programming
| is concerned. as for the lingo associated with it, may it forever be
limited
| to the context of the book that espoused it. for me, i use specifics
when i
| need someone else to understand what i'm doing or what they need to do.
| 'refactoring' is not specific enough.
|
| It's always so wild when someone STARTS by saying I have my head up my
| butt, and then GOES ON to say why they agree with me about stuff.

i agree that to me, it's mostly lingo. HOWEVER UNLIKE YOU, i know BOTH
sides - what refactoring is, how it is used, have experienced the entire
'extreme programming' gammut. i have an INFORMED opinion while you not only
have your head up your ass, you seem quite comfortable in leaving it there
and speaking from it.

see the difference?
| The reason is obvious, would you rather hire a genius to belittle you,
| your company and your project - or a half-wit who will get the job done.

now that would entirely be based on the premise that 1) all geniuses
belittle people and 2) a half-wit can actually get the job done.

i'm glad you get jobs, but your category of 'wittedness' probably only
allows you exposure to those jobs that have little impact on things. if you
up the requirements or up the stakes, so too must you find developers that
can deliver. those would be the ones who learn about their industry
standards, practices, and yes, even lingo so that their expertise will lend
the best solution.

but you go ahead and be happy throwing dispution on things which you know
nothing about.