The main goal of refactoring is clean code, better code, or whatever you might call it. But what actually constitutes good code? Good code is smelled and tasted. If you've written a lot of code, you understand what I mean; you can easily identify whether code is good or bad with experience. But what if you are new to coding but still want to do things right? We can summarize the aspects of good code with these three guidelines: Readable, Extensible and Efficient

He goes on to explain each of these three guidelines with descriptions of what they are and what they mean to you as a developer. In the next part of the series, he'll take these three ideas and apply them to code, showing some of the most common points where they can be applied to clean things up.

"The Art of Readable Code" was written by Dustin Bowell and Trevor Foucher and basically focuses on concepts and suggestions to make you code not just readable, but comprehendible by other developers, or as the author's suggest, yourself in six months. Code readability is a topic that I truly believe the PHP community does not focus enough on and i really wanted a look at this book to see what kind of ideas it had and what I could do my best to bring to the attention of other developers.

The book is language-agnostic and provides ideas that developers should keep in mind when doing their development - clear variable names, making comments that make sense, refactoring tips and hints for implementing your ideas in code. He recommends the book to any developer (in any language) to help them make code that will stand the test of time and be easier to manage/understand in the future.

His suggestions include:

• Changing the handling to look for multiples by default
• Avoiding inner looping (repeated looping) and try for code reuse
• Transforming a scalar value into an array to make it easier to handle this way (by casting)
• and how to handle objects in the same array-handling kind of code

He also tosses in a little mention of performance, noting that a call with range in the argument to his array-handling method is faster than looping over the same range and calling the method each time.

Code readability is a universal subject in the world of computer programming. It's one of the first things we learn as developers. Readable and maintainable code is something to be proud of in a finished product. We can share it with others, contribute to other projects, and reuse code from applications we wrote months or even years ago.

Tips included in the list cover topics like:

• comments & documentation
• code grouping
• avoiding deep nesting
• using consistent temporary names
• using object-oriented code versus procedural
• effective refactoring

I've had the pleasure of maintaining a legacy application developed by people who were past deadline the second they had their assignment handed to them in the past and it can get really interesting rather quickly when you see how sloppy you can get when you are in such a hurry. Here are some guidelines I've given myself to ensure that the structure is correct at the end of the day.

Some of his suggestions include:

• Breaking larger files apart into smaller, easier to maintain pieces
• Correctly naming functions/variables/etc
• Tabbing/spacing in to indent code blocks
• Input validation and error checking should always be included

This is where the fun begins of course. How many times have you been confronted with someone sending you an indecipherable, thus untrustworthy link? Right, so we agree that for a user, it is important to have a clean URL that is readable and includes the title of the page or (at least) some description related to the content. Slug time!

They explain what slugs are (and how they're useful for users) as well as how to convert a title into a "slugged" string by replacing anything that's not an A-Z or 0-9 character to remove the less URL friendly characters.

I got some interesting comments to my previous post on "beautiful code". Some were pretty strong disagreements. So am I wrong? Did I get carried away? Did my critical faculty go on vacation somewhere nice and sunny? [...] My main point is that it's close to plain English. Not everyone agrees that that's a good thing, but I argue that we're built (genetically wired, in fact) to understand natural languages, not program code.

He reasons that code should be easier to understand than just a bunch of random functions and parameters jumbled together. He thinks that it should read more like a human could understand rather than just the machine. With function names like "assertThat" and "hasSelect", it does make it easier to follow.

This is the first article of a series I will dedicate to tips to write PHP code that is easier to maintain, review, refactor,... These tips may be applied for other languages but are mainly focused on PHP. The first one could be entitled as "return as soon as possible.

He compares a code example - simplifying multiple if/elses, replacing the need for multiple nested evaluations that make the code harder to read. Check out the before and after to see how it helps the flow.

Array notation is fine, but it can look a bit clunky when you're working with complex structures. [...] Casting the array to an object allows us to use object notation (->) and makes the code more readable.

He includes examples of the casting, showing the difference between the array and object notations including a method for creating an object based on a simple array that has basic properties built in. This sort of transformation can be useful if you want consistency through out the application - just passing objects with their properties rather than arrays.

Yes, you know what code you write and you also know how it works. You can find your way around it. But what if you haven't touched a piece of code for months or even years. Or what if someone else needs to work with your code. Prevent a hell: use clearly readable variable names and constants.

He points out an example of what not to do - a specific line from the FUDForum code with multiple variables named with a single letter of the alphabet in a complex if() evaluation. He suggests even using "namespacing" of sorts (PHP6 here we come!) to help compartmentalize your variables to make things even easier.