How to determine code quality in PHP

[Selkirk]

Someone said that design and code quality were the same thing. Well, I say look at Ookles and face a contradiction. It's more subtle than that.

As technocrats, we like to think that code quality somehow leads to business success. It doesn't. In fact, code quality may be more of a hygienic factor (from two factor theory). Bad code quality can hurt your success. (a big negative factor) Good code quality cannot ensure it. (a small positive factor)

[Fenrir2]

I think that ease of implementation is far more important than the points in the list of been. It might even be more important than correctness. If it is easy to implement, it can be implemented fast, and the code is readable. It is better to offer a 90% solution fast than a 99% solution slow.

[Ryan Wray]

Don't forget security people!

There are so many things to take into account when defining code security. It is really like trying to explain physical attraction among people. There are are scientifical facts behind it (some believe symmetry in the face makes a person more attractive) but at the end of the day we don't really know why. Added to that we all don't find the same person that attractive, so while there are stereotypes of what makes a person pleasing to the eye, it also boils down to personal taste. So code is just like a woman (from the point of a heterosexual male of course), as someone already said!

[beetle]

As technocrats, we like to think that code quality somehow leads to business success. It doesn't.

Reminds me of this

[dagfinn]

Good code is something which tells a story... In most cases this is the domain; If you can grab an understanding of the domain purely from the code and nothing more, then you are onto something, otherwise why bother?

I agree. Simplicity is in the eye of the beholder. My ability to understand code depends on my ability to simplify it in my own mind, to put some names and ideas on it that will help me understand it. And I'm willing to add some extra lines of code to acheive that, if necessary.

[dagfinn]

You see it really identifies the problem it is trying to solve: a startup attempting a rapid breakthrough into a mass market. Ookles has some nice features, such as assuming a replication environment from the start. It assumes sessions and the like are on separate DBs, so it's a multiple connection environment (no Singleton connection objects). They know the GUI is going to change a lot, so they've given free reign to the AJAX guys and other wise kept out of the way. They keep most of the data as blobs (it's for data sharing on the net), and so don't need a flexible storage model. And so on. It's a clever solution, given the problem space.

It seems to me your main point is that Ookles satisfies some user requirements well. I see that as independent of code quality -- until and unless the ability to satisfy changing requirements becomes too much of a problem. You can certainly have very useful software with poor code quality -- the forum packages that have been discussed are good examples.

You also have a point when you say it's "tuned from the ground up to work with MySQL, so you cannot change that". But isn't that a completely general issue that applies to all programs? All code has flexibility in some areas and not in others. The flexible areas are mainly the ones in which changes have already occurred. Attempting to achieve total flexibility is self-defeating. The strong coupling to MySQL is conspicuous only because we tend to expect flexibility in that particular area.

EDIT: Another complication that occurs to me is the question: hard to change -- by whom? I had never understood the significance of the phpBB "mods" system until Edman pointed it out in the "utter disgrace" thread.

[been]

I think that ease of implementation is far more important than the points in the list of been. It might even be more important than correctness.

What do you mean by 'ease of implementation'? For the moment I read that as 'problem complexity', the degree to which it is easy to implement a solution for a given problem. I could very well be misreading you of course.

If it is meant to be something like the complexity of a problem, I'm having a hard time comparing it to things like correctness because in that case, ease of implementation doesn't seem to be a quality factor at all.

If it is easy to implement, it can be implemented fast, and the code is readable.

If something is easy to implement, it might be implemented fast, but fast implementations are no guarantee for readable code.

It is better to offer a 90% solution fast than a 99% solution slow.

I'd argue that that depends on what is in that 9% and the importance of it to the constituent and end users. Furthermore, whether you're offering 90% of a solution or 5%, it has to be correct or it isn't part of a solution to begin with. And if it isn't part of the solution...

[Silverhawk]

From my point of view, good code only needs to satisfy 3 requirements. Anything more is a bonus and makes it "better" code

1. Readable - If i open up and see a mess, i won't feel like reading it at all.
2. Understandable - Reading the code gives you a good idea on what's being done.
3. Does its job - It solves the problem it was written for.

If the code is readable, it will make it easier to understand. If you can understand the code you will know whether it is doing its job. If you can read and understand the code easily then modifying it shouldn't be too difficult.

Sure proper design and all play a part, but to me that is the realm of "better" code not "good" code.

[Clenard]

Off Topic:

How many forum members does it take to change a light bulb?

-1 to change the light bulb and to post that the light bulb has been changed
-14 to share similar experiences of changing light bulbs and how the light bulb could have been changed differently
-7 to caution about the dangers of changing light bulbs
-27 to point out spelling/grammar errors in posts about changing light bulbs
-53 to flame the spell checkers
-41 to correct spelling/grammar flames
-6 to argue over whether it's "lightbulb" or "light bulb" ...
-another 6 to condemn those 6 as anal-retentive
-2 industry professionals to inform the group that the proper term is "lamp"
-15 know-it-alls who claim *they* are in the industry, and that "light bulb" is perfectly correct
-156 to email the participant's ISPs complaining that they are in violation of their "acceptable use policy"
-109 to post that this group is not about light bulbs and to please take this discussion to a lightbulb group
-203 to demand that cross posting to hardware forum, off-topic forum, and lightbulb group about changing light bulbs be stopped
-111 to defend the posting to this group saying that we all use light bulbs and therefore the posts *are* relevant to this group
-306 to debate which method of changing light bulbs is superior, where to buy the best light bulbs, what brand of light bulbs work best for this technique and what brands are faulty
-27 to post URL's where one can see examples of different light bulbs
-14 to post that the URL's were posted incorrectly and then post the corrected URL's
-3 to post about links they found from the URL's that are relevant to this group which makes light bulbs relevant to this group
-33 to link all posts to date, quote them in their entirety including all headers and signatures, and add "Me too"
-12 to post to the group that they will no longer post because they cannot handle the light bulb controversy
-19 to quote the "Me too's" to say "Me three"
-4 to suggest that posters request the light bulb FAQ
-44 to ask what is a "FAQ"
-4 to say "didn't we go through this already a short time ago?"
-143 to say "do a Google search on light bulbs before posting questions about light bulbs"
-1 forum lurker to respond to the original post 6 months from now and start it all over again....

LMAO... it's always good to see someone bring something so heated down a little

[lastcraft]

Hi...

It seems to me your main point is that Ookles satisfies some user requirements well. I see that as independent of code quality

Actually it's a bit more refined. Ookles is of exceptional code quality where it comes to performance and clarity of purpose. It's not bad looking code either, from the small portion I have seen. There were tradeoffs. The lack of unit tests naturally lead to bugs. There is actually very little "flexibility" in the conventional sense. They are obviously going to have maintanence problems down the line, but they hope to have money coming in by then. In some sense they have adopted a certain "style" of coding to match the problem space.

The reason I am pointing this out is not to cloud the issue, but to suggest that we break down the problem a little or we wil end up contradicting ourselves. Here are my three offered categories...

1) The factory. Cranking out web sites, internal intranet reports, etc. In this domain efficiency is king. Frameworks are key, as is having done the job before. It's about saving money.

2) The craft of lone application. A single web application is the main source of revenue. Here maintanence and novel features are key. Agile/XP is a good fit here, as you have only one instance of the application and it's probably updated weekly. Several programmers will have come and gone over the apps. lifetime, but they will have handed over to each other. The app. will also morph considerably over it's life.

3) The start up. Speed, low cost and a clear vision are crucial. This makes the back end fairly small and defined, but the front end must be very responsive to user requests. It's got to be cool, both to attract a buzz and also initial investment. All sorts of later maintanence crimes may be committed. High risk, because if there is a fundamental flaw in the business you will be better off with a rewrite than trying to refactor a mess. Bugs will be fixed later.

A lot of the code qualities that people have listed so far, I think are specific to a particular domain.

yours, Marcus

[Etnu]

And sometimes the most straightforward solution to a problem can still be very complex.

Only if it's a complex problem.

Most problems aren't complex...people just make them that way.

Programming isn't hard until someone goes out of their way to make it that way.

[dagfinn]

There is actually very little "flexibility" in the conventional sense.

There are at least two conventional senses by now. One is engineered flexibility, giving the code a specific kind of flexibility by building it in specifically. The other is agile flexibility, keeping the code as ready as possible to accept any conceivable requirement by keeping it simple and readable and adhering to some general principles.

Agile flexibility is probably the closest we can get to a general definition of good code.

The reason I am pointing this out is not to cloud the issue, but to suggest that we break down the problem a little or we wil end up contradicting ourselves.

You often cloud the issue, and it's always useful.

Seriously, you're challenging an idea that seems crystal clear but is really too superficial.

Here are my three offered categories...

I'm still trying to wrap my mind around what you're really doing. It's fascinating, and I'm still entertaining the hypothesis that you're (primarily) on the subject of user requirements.
Performance, for one thing, is just another requirement.

Let me take that a little further. If a piece of software satifies user requirements (in other words, if it's useful), the reason can be:

• luck, or
• foresight, or
• adaptation (in other words, it didn't fit the requirements at first, but it was modified to fit).

Luck is luck, foresight is impossible according to agile dogma, adaptation is a function of agile flexibility.

So I'm wondering if what you're really doing is to suggest that some foresight is possible after all. Your three categories are different in what requirements are likely to appear.

[lastcraft]

Hi...

There are at least two conventional senses by now.

How about a third . You invest so little effort in the development that you can throw the whole thing away with a clear conscience. This is the spike, or prototype.

Now suppose we go to the business, presumeably a start up, and say...

"We can build you a business spike. You get enough application that works enough of the time to get you some initial customers and investement. If the business takes off, we'll rewrite it. If it doesn't, at least it hasn't cost you much."

At least if we stated this up front, we wouldn't be lying. The business would know that it would suffer a rewrite and could build it into the business plan. Rather than waiting until competition arrives. At that point the feature freeze that the rewrite inflicts comes at the worst time. The Netscape effect if you like.

This strategy seems to be what Ookles is aiming at. It's significant that Ookles evolved from Feedster. Of course Feedster has just done a rewrite and is now run on partly Agile methods .

I'm still trying to wrap my mind around what you're really doing. It's fascinating, and I'm still entertaining the hypothesis that you're (primarily) on the subject of user requirements.

I don't know what I'm doing . I just get a feeling of unease at the big tick lists presented so far. I guess I am broadening the question from what makes good code, to what makes a good programmer. As programmers write code, these two questions should be related, right? Yet "What makes a good programmer?" is terribly multi faceted, whilst "What makes good code?" seems like it can be answered one dimensionally. This makes me uneasy.

Performance, for one thing, is just another requirement.

I think there is a different between requirements and just features then. If I describe a feature, it's something a user can do. It's an isolated part of the code. If I have a requirement such as performance, security, flexibility, etc. It cuts across the whole code base.

...foresight is impossible according to agile dogma, ...

Kind of. It increases risk because the early investment is more likely to come to nothing. The idea is that lot's of small low risk steps makes better progress than slightly larger, but often wasted, larger steps.

Suppose though, that we are ina low risk environment. Say, an area where we have solved identical problems before. I had to do this recently with a recruitment project. It's a totally known problem, and a profession that is run by profit margins. There was nothing to discover, and so near zero risk. Did I do a full XP? It would have been more expensive (and boring - I wanted to get it ove with quickly).

I did the following:

1) Used Postgres stored procs/triggers for the underlying functionality. I had some PHP acceptance tests to exercise these. About 80 procs in all.
2) Used views to simplify the front end code.
3) Built a good front end table widget with plug-in column formatters to make the display of the lists as flexible as possible. This is design ahead. I built a toolkit that could be played with later. I didn't have much contact with the client due to remote working.
4) A simpler backend table widget handled the admin interfaces and reporting.

I lost out on one area, the authorisation model. For some reason, that one is really hard to design ahead. Everything else went smoothly. Apart from the front end, where I effectively built a mini-framework, it was all BDUF. There is some testing (the acceptance tests for the procs and the display widget), but not much.

So I'm wondering if what you're really doing is to suggest that some foresight is possible after all. Your three categories are different in what requirements are likely to appear.

Yes. I think agile is a good fit for most small web companies, but I don't think it's universal. At the beginning of a company lifecycle it seems too slow, and at the end of the lifecycle there is too little innovation to justify a cautious evolutionary approach.

Now what makes a good agile code base is pretty clear to me. I can spot it even if I cannot articulate what makes it good. In the other two zones, I haven't a clue.

yours, Marcus

[Fenrir2]

What do you mean by 'ease of implementation'? For the moment I read that as 'problem complexity', the degree to which it is easy to implement a solution for a given problem. I could very well be misreading you of course.

If it is meant to be something like the complexity of a problem, I'm having a hard time comparing it to things like correctness because in that case, ease of implementation doesn't seem to be a quality factor at all.

I meant that I think it is better to choose for an easy implementation, rather than a complex but flexible/compatible/reusable/... one.

If you are implementing a shipping system for your application, and you want to compute the shipping cost, do you want a 100% correct solution, or 90% correct? The 100% correct solution will check all shipping companies for every possible country, and compute the price. The 90% correct solution will only compute the shipping for countries like the US/england/etc. The shipping cost in other countries will be computed with weight_of_product * 6 or something. This isn't correct, but it is much easier, and can be done much faster.

Also, in some languages, 5/0 is infinity. That is not correct, but it is again easy to implement.

If something is easy to implement, it might be implemented fast, but fast implementations are no guarantee for readable code.

No, but if the code is easier to write, it is probably easier to read.

I'd argue that that depends on what is in that 9% and the importance of it to the constituent and end users. Furthermore, whether you're offering 90% of a solution or 5%, it has to be correct or it isn't part of a solution to begin with. And if it isn't part of the solution...

Something isn't just correct or incorrect, as with the shipping, it can be partially correct. You need at least n% correctness, of course.

[REMIYA]

except for php5 which as language is quite nice and fast but lacks thousands of packages and classes that make Java and .NET languages so usefull for programmers

In the beginning, I really missed the Java packages.
Since then I haven't missed a single Java package, but I surely miss plenty PHP extensions in Java.