Hmm… You have to be careful talking about something in general terms which you don’t seem to have specific knowledge. Martin Geisler wrote an incendiary post about the WordPress codebase, and while I will admit that the code isn’t perfect, it’s far from the beast that he implies lies behind the label.
Allow me to refute certain points directly:
Global variables are used all over the place! Global variables should be used sparsely, if at all, for they often make the code more difficult to understand. ... There are also lots of other global variables in the code, and they are often used in a much more subtle way than the $wpdb variable. A simple count of the (unique) variables declared global in the wp-includes directory gives no less than 108 variables!
Global variables are used in WordPress in many places to make things simpler for a novice end-user to design. Many of the variables that you’ve found as global in WordPress are reduced from an object instance that is also global. But rather than subject end users and theme developers to learning the nuances of object-oriented syntax and methodology, these object members are abstracted into global terms that simplify their use in the templating system that WordPress employs.
If you removed these globals, you would not only reduce usability for end-users, plugin developers, or theme developers, but I doubt that the nature of PHP would allow you to work with any fewer global variables than what is left already declared and yet still retain a functional program. This isn’t the nature of poor code design in WordPress, but the nature of PHP development.
Lack of comments! The core files such as functions.php contains tons of functions, but no comments. ... The online documentation website, the Codex, is still very incomplete when it comes to information about the internals, and I would much prefer to have the documentation right there where it’s needed: in the code.
Abundant comments are overrated, and many automated comment-gathering tools for PHP are overambitious. Sure, there aren’t as many comments in the WordPress source as there should be. Basic function header comments would go a long way toward facilitating 3rd party development. But let’s not be too ambitious with it - function headers are all that we need. Most developers need only reference the functions to use them in their own development, and have no need to know how they work.
The sad, elitist truth is that if you’re doing core work with the internals of the code, you should know well enough how to read code (in general and in WordPress-specific) that you don’t need a comment on every other line.
Moreover, as many people have suggested, if you don’t like it, you are free to add whatever comments you like and submit it as a patch. It’s even easier to add documentation to Codex, and the documentors would beg you to do so. In addition, I have personally been on the WordPress IRC channel too often over the past two weeks, and have offered plenty of coding advice to the people who have asked for it, as have many others. The project is always evolving, and expecting to have everything you need to write code laid before you is expecting too much.
Duplicated code! Why does the code in post.php not use the wp_insert_post() function declared in functions-post.php? Instead it seems to duplicate the logic in wp_insert_post(), something which will sooner or later lead to problems.
Once again, in regard to duplicated code, you really have to know the code better before you make blanket statements about it. Granted, wp_insert_post() should probably be used by post.php, and slowly these generic functions are starting to take over the core functions.
Over the past year, since before version 1.2, these functions have started to appear, and I’ve noticed that similar functions were used for comments. Some comment types used them, some didn’t. Now they all do. Rather than force the change through, the change has been gradual; The growing pains are less severe. I’m sure that the next major revision will reduce these “duplicates” even more, and that the core devs are aware of them. So it’s not a matter of the code not conforming to your wishes, it’s just a matter of you not having any experience but with a snapshot of something reasonably large and evolving.
Incredibly long lines! It is clear that there has been made no attempt to break the code into lines at a reasonable site (that is, less than 80 characters per line).
If you’re not coding in an IDE, then I don’t know why I’m talking to you about development. Seriously. It’s quaint to site Notepad as a design tool, but serious developers use serious tools.
I’m not sorry to say that emacs is not an editor that a modern programmer should consider for serious development. Taking a quick poll of everyone I know from college who used emacs back in the day on whether they would consider using emacs over their current tools, they all said they would rather leap naked into a boiling vat of frying oil. Or something equally grotesque and fatal.
Not intent to get into a war over what the best editor is, I’ll just suggest the one I use on Windows- PSPad. It’s free, it will open and save files directly over FTP, it syntax highlights PHP, it code-completes PHP, if function maps PHP, and it wraps lines. I’m sure you can find a similarly full-featured editor in the Linux or Apple worlds, or maybe even run PSPad under Wine. Either way, it’s time to upgrade, and if you won’t because you’re just that hard core, then you deserve to suffer.
And having said all that, no, you shouldn’t wrap lines to 80 characters. That’s very 70’s programming. Do it when it helps you figure out the logic, not just because there’s a margin line in your editor commanding you to do so. I hate that CompSci professors will tell you this without giving you a good reason, because the good reason for wrapping lines is always better than “making it fit in emacs” or looking pretty.
I really can’t fathom why, when you see a line longer than 80 characters causing you problems in your editor, you assume it’s the code and not the editor. Astounding.
Similarly, try out a diff application that is visual and will let you see the changes within lines. Araxis Merge is commercial, but it saves you the trouble of looking for the one-character change by highlighting it, no matter how long or short the line is. I love Araxis Merge.
Mixed XHTML and PHP code. ...To defend this choice, then I must say that I’ve never been impressed by template systems like Smarty which claims to separate the application code from the presentation. … Has this bought you anything, except requiring you to learn another language with its possible quirks and limitations?
If that was what the WordPress developers asked themselves, then I can understand why they simply went with normal PHP code mixed with XHTML. But it can be done better than that: PhpWiki uses a cool system where all the XHTML code is generated using a set of classes and functions.
You’re not considering the target audience of WordPress. To better understand this, examine the theme repository.
One of the major problems I’ve seen in the theme development arena is that we’ve got this great tool for keeping revisions of themes – Subversion. WordPress provides a free repository for theme developers to maintain their themes. Many have used it. At least, they tried, since browsing the repository reveals that most of them have failed to understand the basic workings of the SVN system.
The same is true for the core templating functions, which, as I’ve mentioned before, have been “dummied up” so that the theme designers don’t need to learn object-oriented programming to build themes. Requiring this knowlege is a huge hurdle for theme development. Thanks to the way that the theme engine is currently designed, there are hundreds of fantastic themes available for WordPress, made by designers who would not have produced a thing had they been required to learn programming concepts like classes and objects.
Perhaps this explains why phpWiki has such a dearth of themes? The learning curve for building a phpWiki theme seems steep, and designers (whose purview usually doesn’t extend beyond XHTML, CSS, and Photoshop) wouldn’t set foot near that descendant object system unless they were well-trained and possibly coerced with offers of sex and idolatry. (None of which is on offer.)
So what comes of this?
I would like to see improvements in documetnation, and a few more comments added here and there. But the thing for me is, I don’t need them to know what these functions do. This would mostly be for helping others. And since I’ve written a significant part of what scant developer documentation that does exist, I am free to say that more needs to be done.
This is the point in the conversation that I say “put up, or shut up”. A lot of people have put a lot of work into the project, and there is a lot of history here that you need to catch up on before pointing fingers. I highly suggest building onto the community and offering a hand. Criticism is welcome, but please get a little background first. Hopefully this has been edifying in that regard, and you take it as an introduction to a long term of learning and loving and extending the code.
