FooCamp: Questions About the Readme.txt and Performance

This post is really assuming you’ve already read Brad Vincent’s latest post at FooPlugins.com. Read it here, first. Questions About the Readme.txt and Performance This week Brad and I worked on creating the readme.txt and readme.md files, and he explained his approach for refactoring php files to make future development easier. This made me think… Read more FooCamp: Questions About the Readme.txt and Performance

This post is really assuming you’ve already read Brad Vincent’s latest post at FooPlugins.com. Read it here, first.

Questions About the Readme.txt and Performance

This week Brad and I worked on creating the readme.txt and readme.md files, and he explained his approach for refactoring php files to make future development easier. This made me think of several things that front-end developers would relate to but might have immediate questions about.

1. Why “Quasi”- Markdown?

Seriously, there are enough coding languages in the world already, and Markdown’s whole goal is to make basic text html EASIER, and WP has to go and create a “quasi” form of an already gorgeously simplistic language. Ug.

I got the privilege to help out with some archiving at the Journal of Southern Religion. They introduced me to Markdown, and I’ve been really amazed at how intuitive and simple it is, particularly with footnotes (which are a BEAR in plain html). So it’s nice to already be somewhat familiar with it. And really, I don’t want to whine … but:

How in the world can I remember that an h2 needs 3 equal signs on BOTH sides, but an h3 needs 2!?

In Markdown, an h1 needs 1 hashtag, an h2 needs 2… it’s logical. It’s like WP decided to be the US Customary Units to Markdown’s Metric system. Needless to say, I prepared my .md file first and then converted it to the WP feet-n-inches style for the readme.txt file, and I had to refer back and forth to the Smashing Magazine article that Brad linked to. Also, I use MarkDown Pad, which is incredible.

2. Whoot! I love Boilerplates!

Ok, this is not a question. But the front-end developer in me went: “What, there’s a boilerplate for this stuff!? Awesome!” I love the HTML5Boilerplate both by itself and the WordPress version, so seeing this and how it lays everything out really logically and similarly to how WordPress theme authors would layout their themes is great stuff.

3. Will Refactoring Slow Down how quickly the plugin works?

But this is the lingering question and one that I don’t think will be answered anywhere short of eternity. Basically, as a front-end developer, the first thing I look at in a theme code is how many extraneous HTTP requests it makes. Because I know that if I can get them down to 1 or 2 instead of 10 then the template will fly along much more quickly. But is that relevant for using require_once instead of putting all the code in one long php file? Well, it seems some folks think it’s better to avoid require_once if at all possible; which I assume is why some put all the code in one big file. But, like Brad said, that’s not very nice to yourself when you want to make future updates nor to any others who want to learn from your code. Basically, if you want to Be a Developer Friendly Developer, then the boilerplate is spot on. Plus, in scanning through the code there is only one require_once, and one include_once as far as I can see.

Would love your thoughts on all the above or just to hear if some of you are creating stuff and we’re helping out somehow. Let us know in the comments.