Comments on: How Readable is Your PHP?

By: Fred

Fred — Sun, 02 Oct 2005 08:05:55 +0000

You could make some functions to make your code more readable. Could also make some classes to make your code more structured, and use low coupling and high cohesion program design. I recommend to use low coupling because it can make a good structured program design, good maintainability, information hiding and encapsulation.

By: Canglan’s Blog 沧蓝品味 » 代码标准 (Coding Standards)

Canglan’s Blog 沧蓝品味 » 代码标准 (Coding Standards) — Wed, 07 Sep 2005 08:43:16 +0000

[...] 在我开始写论坛程序之前，就稍微地研究了一下PEAR的Coding标准和PHPDoc的Comment标准。今天在网上看资料的时候又看到一些关于代码和注释标准的讨论。还有这篇。 [...]

By: Fred

Fred — Wed, 07 Sep 2005 08:19:51 +0000

and make entity names such as function, class and variable names obvious and precise

This can be debatable, one may find a piece of code to be clean and clear whilst the others might not. People tend to have different logic and solution on a same problem.

So I reckon appropriate comments is necessary.

By: Navin

Navin — Mon, 29 Aug 2005 11:41:46 +0000

I would recommend to all beginning php-programmers to make familiar with PEAR php coding standards (pear.php.net). There you will find far more tips on how a good code must be organized and developed then in this article.

By: daholygoat

daholygoat — Mon, 29 Aug 2005 09:58:24 +0000

In some software engineering methodologies (Agile Software Development for example), instructors encourage you to reduce comments, and make entity names such as function, class and variable names obvious and precise. In the book “Refactoring – Improving existing designs”, Martin Fowler explains his view on comments as being a “smell” (read about Refactoring smells) that implies a code structure or naming that is not concise. He encourages to only comment algorithms that are so complex that they can only be made obvious by commenting them. So in short his lesson is: try to improve your code before you comment. It might be better to stress on well structured, obvious code than on commenting, especially (no offense) in the PHP world.

By: gmilner

gmilner — Fri, 26 Aug 2005 17:28:23 +0000

Of course, the best way to make your PHP code seem immediately more readable is to learn Perl. It’s subjective, but it really works.

By: BDKR

BDKR — Fri, 26 Aug 2005 13:01:59 +0000

Well, all I can say is “preach it brother”! Being in the position of having to manage and extend a code base that is the stuff of nightmares, I feel this very topic should be one of the most loudly ballyhooed on the net today.

By far, the most difficult challenge with my present employment is in extending portions of existing functionality that was never clearly abstracted or defined in the first place. So as a result of this hastily jumbled together moras of spaghetti, the vast majority of my time is dedicated to merely “grokking” what I see before me. And we all know you should only attempt to extend what you understand.

By: Sky

Sky — Fri, 26 Aug 2005 07:36:23 +0000

Just to say that i liked reading that article and all your comments are very interesting.
Thx Thomas.

By: vinyl-junkie

vinyl-junkie — Fri, 26 Aug 2005 03:01:40 +0000

Unfortunately a lot of hard-to-understand code is, understandably, a result of laziness or unrealistic deadlines.

You can also add incompetence and incomplete requirements to your list. In my opinion, unrealistic deadlines and incomplete requirements are the biggest reasons for poorly written code.

As a developer, I am often asked to start writing code before the requirements are fully defined. What started out as well-written code rapidly degenerates when requirements are constantly being changed in the middle of coding. That has occasionally resulted in other developers questioning my competence when they look at my code. They have no idea what caused my code to turn out like it did because they weren’t involved in the initial project to see these problems.

Conventional wisdom states that if one adheres to established project management methodology (analysis, then design, then construction), problems such as I have stated can be avoided. However, unrealistic deadlines and incomplete requirements definition force us to shortcut the development process, which often results in poorly written code.

By: Etnu

Etnu — Thu, 25 Aug 2005 19:28:23 +0000

Etnu, do you actually know what you’re talking about? Every single variable in vBulletin is sanitized before output or input. It’s one of the most secure pieces of software available.

I’ve worked with vBulletin since it first came out, and continue to recommend it as the best forum software out there today to all of my clients / employers.

However –

I’ve installed it on 8 major websites and dozens of smaller ones. I’ve integrated it with everything under the sun, and constantly had to deal with its shortcomings. If you think it’s one of the most secure pieces of software available, you’ve never used anything but the latest version (which has no known security holes that I’m aware of), and likely never dealt with any other piece of code in your life. Even versions as recent as 3.0.5 had major flaws (question: why should turning on COMMENTS IN OUTPUT be exposing me to a security risk?)

vBulletin is awful, awful software. If it weren’t for the fact that ALL forum software out there is pretty much crap (the forums with good code tends to be feature-poor), it’d never gotten where it is today. Well, the fact that phpBB and IPB suck worse probably helps a bit, too.

Lets not even get started on the developers practice of encouraging “hacks” to accomodate their poor design. Things are improved quite a bit in 3.5, but it’s still sorely lacking. That’s what you get when you have a company more concerned with making sure that every installation is legit than with making sure their software won’t expose the users to potentially major security risks.