In this new post to DZone.com, Giorgio Sironi walks you through a few steps to consider when trying to refactor some of the spaghetti code out of your application.

Sometimes you have to take a step back from discussions on coupling, cohesion, patterns and katas to give some training to the ones of us that have a procedural mindset. With this article I hope to provide some initial tips for the members of the PHP community that are ready to abandon the concept of the OneSingleProcedure(TM) to embrace the object world.

He includes a common procedural example with all of the logic in one file and talks about how the idea of "decomposition" can help to break it up into objects with their own roles and responsibilities.

Timothy Boronczyk has a new post to his blog proposing something that any veteran developer already knows - "spaghetti code" is harmful to the health of your application. He's done a little research, though, and tried to explore what this "bad code" really is.

The phrase "spaghetti code" is an all-too-common pejorative we programmers use to describe horrible code, whether it's difficult to understand, poorly organized, or just plain long-winded. And there-in lays the problem. What really constitutes spaghetti code is subjective; I've yet to hear a concrete definition or standard metric that measures it. [...] Everyone has his or her own opinion as to what aspects would make them label it spaghetti.

Suggested definitions include: quickly written, non-standardized, beginner-level quality and any code that makes use of "goto". He suggests that applying the term to someone's code is less about the real quality of the code and more about social aspects of not wanting to upset the other developer over its quality.

But besides negatively affecting others, our complaining about spaghetti code hurts ourselves too. It's easier to motivate ourselves when tasked with fixing a bug when we're not dreading having to trudge through spaghetti. When we label code as spaghetti code, we are actually creating roadblocks that hamper ourselves and artificially increase the difficulty of the task at hand.

On the PHP::Impact blog Federico Cargnelutti has expressed his opinion about the inclusion of the "GOTO" statement into future builds of PHP:

The GOTO statement has been the target of much continued criticism and debate, with the primary negative claim being that use of GOTO results in unreadable and generally unmaintainable spaghetti code. [...] Well, great news. The GOTO statement has just been added to the PHP language and it’s now in the hands of experienced programmers and inexperienced Web developers.

He references a quote from Jeff Moore stating his dissatisfaction with the inclusion of it too. Comments on the post, however, correct Federico on how the "GOTO" in PHP will work - not quite as global as he'd thought.

The ladies over on PHPWomen.org have opened up a new area in their forums - a place to discuss best practices in PHP.

Just a quick note that the Best Practices forum is now open and already has a couple of fast and easy articles in it for your viewing pleasure. For any aspiring writers - there is also a list of future articles if you want to try your hand at it.

There's already a few articles posted including ones discussing PHPDocumentor, spaghetti code, and variable abuse.

The ladies over on PHPWomen.org have opened up a new area in their forums - a place to discuss best practices in PHP.

Just a quick note that the Best Practices forum is now open and already has a couple of fast and easy articles in it for your viewing pleasure. For any aspiring writers - there is also a list of future articles if you want to try your hand at it.

There's already a few articles posted including ones discussing PHPDocumentor, spaghetti code, and variable abuse.

From PHPEverywhere today, there's a new post from John Lim that asks the question, "Is PHP4 the new Perl?"

Tim Bray, one of authors of XML, voices concern about PHP: "So here's my problem, based on my limited experience with PHP (deploying a couple of free apps to do this and that, and debugging a site for a non-technical friend here and there): all the PHP code I've seen in that experience has been messy, unmaintainable crap. Spaghetti SQL wrapped in spaghetti PHP wrapped in spaghetti HTML, replicated in slightly-varying form in dozens of places.

But in the big picture, it feels vulnerable to me."

John argues that it's not the language's fault if the code that's written is bad (more coders need this). He also suggests that maybe PHP4 is perl for the web - simply because of the one of the reasons it's popular - it's potential for abuse from badly written code.

From PHPEverywhere today, there's a new post from John Lim that asks the question, "Is PHP4 the new Perl?"

Tim Bray, one of authors of XML, voices concern about PHP: "So here's my problem, based on my limited experience with PHP (deploying a couple of free apps to do this and that, and debugging a site for a non-technical friend here and there): all the PHP code I've seen in that experience has been messy, unmaintainable crap. Spaghetti SQL wrapped in spaghetti PHP wrapped in spaghetti HTML, replicated in slightly-varying form in dozens of places.

But in the big picture, it feels vulnerable to me."

John argues that it's not the language's fault if the code that's written is bad (more coders need this). He also suggests that maybe PHP4 is perl for the web - simply because of the one of the reasons it's popular - it's potential for abuse from badly written code.