Best Coding Practice

Join Bytes! wrote:

I'd pick choice 1.

Generally I try not to change an existing function's signature unless
necessary. Also, it's more clear as to what it's doing, and there is
only one line of duplicated code (if there were a lot of lines, I'd have
a common function and pass $a or $b to that function).

You could make a case could be made for choice 2, but it adds
complication (and processing time for the if statements).

No way would I ever pick choice 3. It's unnecessarily complicated and
confusing. And what would happen if someone passed 'c' to it?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
Join Bytes!
==================

On Aug 23, 8:41 pm, "burgermeiste...@gmail.com"
<burgermeiste...@gmail.comwrote:

still have redundant logic, as you stated


not very good practice. when you start using conditional statements
within your code, it's a good canidate for refactoring. Seeing this
as a possibility, I probably would have created a abstract base
Products class, which it's child concrete classes would act as
containers for product items. The base class would contain all the
core functionality, and the child classes the specific elements.
Then, come time to add a new sibling class, it simply inherets from
the superclass and your good to go.


I've actually done something similar to this before. Only 2 months
later I was cursing the programmer that came up with this
chaos....damn.

<burgermeister01@gmail.comwrote in message
news:1187916107.291436.304670@q3g2000prf.googlegro ups.com...
| 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.

since this is a general prog. q., let me answer with a formal approach...

i'd get more strict with the array. i'd make them into an object - a class.
i'd either have b extend a, or a and b extend another base/common object, or
have a and b implement a standard inter face. the array that you're holding
$object in should be strong-typed as the 1) base object or 2) the shared
interface. upon processing within your function, you'd simply get the class
type of the object and place it in its appropriate array.

but, that just may be to formal...especially since isp's seem reluctant/slow
in upgrading to more recent and oop compatible versions of php.

and, that could just be me.

cheers.

ELINTPimp wrote:


Refactoring?
What's that?

"Sanders Kaufman" <bucky@kaufman.netwrote in message
news:CMrzi.11327$3x.7315@newssvr25.news.prodigy.ne t...


http://www.google.com.au/search?q=refactoring

Second hit.

--
Richard.

rf wrote:


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. Oddly, my spell-checker sees "refactor" as not-a-word.

I'll have to remember that one - I don't rewrite my code, I
refactor(sp?) it.

I notice they cite Agile and Extreme (but not Waterfall) in that
definition. That's funny. Every time I've been involved in a shop that
prayed from one of those bibles, agony and failure were the
words-of-the-day... for just that reason.

They always come up with convoluted ways of stating the simplest things,
and the most complex ways of performing the simplest functions.

On second thought... maybe I'll just forget that one.

Thx rf

"Sanders Kaufman" <bucky@kaufman.netwrote in message
news:nHszi.4651$LL7.2735@nlpi069.nbdc.sbc.com...
| rf wrote:
| "Sanders Kaufman" <bucky@kaufman.netwrote 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. Oddly, my spell-checker sees "refactor" as not-a-word.
|
| I'll have to remember that one - I don't rewrite my code, I
| refactor(sp?) it.
|
| I notice they cite Agile and Extreme (but not Waterfall) in that
| definition. That's funny. Every time I've been involved in a shop that
| prayed from one of those bibles, agony and failure were the
| words-of-the-day... for just that reason.
|
| They always come up with convoluted ways of stating the simplest things,
| and the most complex ways of performing the simplest functions.
|
| On second thought... maybe I'll just forget that one.

but don't you just love the 'automatic unit testing blah blah blah'. i've
written tests more complex that the code it was performed on. perhaps
'automatic' should be stricken from that def.

however, the 'fundamentally wrong' is not really wrong at all. the
functionality is not broken. it could be that a new enhancement needs to be
added. refactoring old code for the addition may just mean code isolation so
that pertinent portions can be used in multiple places yet maintained in
one. it may mean you hired a consultant to produce quick results that you
were understaffed to complete. *always* go behind your consultants!!! *most*
of the shittiest working code i've ever seen comes from that source. plus
they may just innocently enough, not know your standards and practices...so
you're bringing it back in line. it could be that when reviewing a code
base, patterns emerge that could be consolidated or reduced to a more simple
statement...all of these things are reasons to refactor.

btw, i hate 'extreme programming'. it employs decades old scientific
management models and pawns them off as new and exciting, even
revolutionary...dare i say 'extreme'...methodology not seen until modern
times. but, i digress...

cheers

"Sanders Kaufman" <bucky@kaufman.netwrote in message
news:nHszi.4651$LL7.2735@nlpi069.nbdc.sbc.com...

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.

--
Richard.

rf wrote:


Yeah - so advanced that it leaves the programming world entirely, and
enters that of PC bidness-speak. Bleccchh.

I'm a code-monkey, and I like it.

Join Bytes! wrote:


Frankly I think all the options you outlined expose too much of the inner
workings of your class. What happens when you add a third category of
products (products that cost money, free products & products we have to
pay you to take away!)

A better solution would be something like this:

public function add_product (Product $p)
{
if ($p->price==0)
$this->free_products[] = $p;
else
$this->products[] = $p;
}

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.12-12mdksmp, up 64 days, 11:44.]

TrivialEncoder/0.2
http://tobyinkster.co.uk/blog/2007/...rivial-encoder/

On Aug 24, 12:59 am, Sanders Kaufman <bu...@kaufman.netwrote:

Sanders, I respect where you are coming from as wanting to be a "code-
monkey" and remove yourself from the "PC bidness-speak", as I've been
that way (and continue to be that way to some extent). There is a big
difference, however, in adopting sound best practices in software
engineering and "running with the crowd", as it were, using terms we
all love to hate like Web 2.0 and the like.

Refactoring your code doesn't always mean you screwed up in the design
or within the actual logic of the code. Most of the time, it has to
deal with improving your code to meet new business requirements. A
good (and dramatic) example is if you started with a very small
project that used OO, but not an MVC or similar framework. Later,
your customer tells you that their business has expanded and their
presence on the Internet must grow accordingly and now the customer is
needing something that is well beyond the original specifications of
the web application you created. Then starts the refactoring
process. Refactoring could also deal not just with your business
logic, but also database schema and aspects therein.

I recommend to all that hasn't already read them, to check out books
by Martin Fowler as a starter into this subject.

The term "refactoring" can be considered a label, really, similar to
giving a design pattern a name. It gives technical people a common
language so they can work together. Just because your PHB may pickup
on the term, and use it (probably incorrectly), doesn't mean it's
garbage and does not relate to a software engineer.

Extreme programming uses the term refactoring, but even though it may
be in the index of the book, doesn't mean they are strictly related.

| Agreed, please see my post above. I'll be sure to focus on the
| problem rather than the approach of the person in the future. Thanks
| for pointing this out, Jerry.

you always have to consider BOTH. that 'person in the future' is probably
going to be you. either way, it is the structure and pattern of what you
code that makes a project manageable and expandable. just looking at the
current problem is amatuer practice at best. that's called putting out fires
and is too short-sighted to do anyone much good.

ELINTPimp wrote:


I understand all that... and how "refactor" doesn't necessarily mean
that everything's a mess.

In fact, I just "refactored" some code in which I was passing CSV
strings, but needed to change that to an array.

But I just told my payer that I did something fundamentally wrong, and
had to fix it before I went on. Had I said I need to "refactor" my code
, it wouldn't have been clear to her what happened. Worse, I think it
would have scared her into thinking that I was another one of many
coders she's hired before who bend over backwards to avoid admitting
that they made a mistake... while charging her for it.

I realize that in some circles, that kind of biz-speak is acceptable -
but those aren't my circles.

Sanders Kaufman wrote:

But that's not refactoring. You changed the interface. Refactoring
does not change the interface - just the internal workings.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
Join Bytes!
==================

Jerry Stuckle wrote:



What happened was that I had that Database->Baseclass->Implementation
structure going on, but I oopsed and put some features in the baseclass
that belonged in the database class.

Since the whole project relied on that wrong way of doing things, I had
to go to every page that extended the baseclass and modify it to reflect
the array way instead of the csv way.

That's refactoring, right?

btw - I just finished fixing up a working implementation and it's at
"http://www.kaufman.net/bvckvs/bvckvs_publication.php".

Except for a lot of cosmetology to do, I think it's what I wanted.

Sanders Kaufman 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.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
Join Bytes!
==================

Jerry Stuckle wrote:


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.

No, refactoring is changing the implementation without changing the

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.

<snipped more incorrect stuff>


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.

Dikkie Dik wrote:

I have read the book - many times. And I've been involved in
"refactoring" since long before the term ever came up. The interface IS
the behavior - and changing the interface changes the behavior.

Refactoring means you don't have to chance code outside that which you
are changing. For instance, you can change the body of the function
without changing the function name, parameter list and return value.
This requires no change outside of the function, and is refactoring.

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.

Pull your head out of your ass and learn what you're talking about
before showing what an idiot you are.


Not at all. But you have no idea what you're talking about.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
Join Bytes!
==================

..oO(Jerry Stuckle)


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

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

Micha

Michael Fesser 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

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.
Join Bytes!
==================

Dikkie Dik wrote:

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



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

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

Jerry Stuckle wrote:



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.

"Michael Fesser" <netizen@gmx.dewrote in message
news:cng0d3dhkhm507nvjtg590i1gs1bl605ta@4ax.com...
| .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. ;^)

Steve wrote:

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.



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



--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
Join Bytes!
==================

"Jerry Stuckle" <jstucklex@attglobal.netwrote in message
news:W5idncnku_TD10nbnZ2dnUVZ_g6dnZ2d@comcast.com. ..
| Steve wrote:
| "Michael Fesser" <netizen@gmx.dewrote in message
| news:cng0d3dhkhm507nvjtg590i1gs1bl605ta@4ax.com...
| | .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 "refactoring" 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*...not 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.

Steve wrote:


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.

Steve wrote:

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".


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.


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.


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