By looking at the id attribute anyone can predict the hooks, because the are named always the same. You know already how the hooks for <div id="header"> and <div id="content"> will be named. There is an interesting Trac ticket you should read and the Theme Hook Alliance @Otto recommended in his answer.

Register all callbacks for your hooks in one place: the start of the functions.php. If everything is bound to a hook you don’t need function_exists(), because a plugin or a child theme can just unregister your function and use its own instead.

The @wp-hook the_title 20 tells the reader exactly when that function will be called and how to remove it. For complex code provide usage examples in the DocBlock.

Avoid code that makes plugin code hard to write:

Never include files, declare functions or create global variables in view files (templates). Child theme authors would have to recreate those again – waste of time.

Never just run code when the functions.php is called. Bind everything to a hook to give plugins a chance to disable the code.

Never use a priority 0.

Never use require, require_once or include and include_once in your theme. Use locate_template() instead. In some cases a plugin might register its own directory as an additional theme directory for a child theme. locate_template() allows such a plugin to replace a complete file.

Interesting, but doesn't take into account the admin panels for a given theme.
–
VolomikeOct 30 '12 at 3:18

Adding hooks to admin panels is naturally going to be more or less completely custom, because admin panels are generally completely custom. If you're using the Settings API, then other plugins can add to your admin panels easily already, no extra hooks needed.
–
OttoOct 30 '12 at 14:06

Although, there are several things which you should make use of in your theme. I cannot list every single thing you should do in such great detail. However, I can provide a short list with a quick explanation why you should be using them.

WordPress Core Functions

register_sidebar(); or register_sidebars(); - Having dynamically created sidebars, allows plugin developers to manipulate the sidebar output by either hiding what's already there, adding more content or removing a sidebar entirely.

wp_register_sidebar_widget(); and
wp_set_sidebars_widgets(); - Widgets really go well with your dynamic sidebars from bullet number two. This again, allows extreme high flexibility with your theme. Allowing developers to add custom widgets, and inject them into your dynamic sidebars for further functionality or content output.

get_header();get_footer();get_sidebar(); or
get_template_part(); - Using WordPress built-in functions for obtaining sections of your theme, allows for plugin developers to again, manipulate your theme output, by either inserting additional code to your theme, removing code from your theme, or changing the effect of your theme, by using hooks, which I will cover next, after this list.

wp_head();wp_footer();wp_title(); and
body_class(); - These functions are excellent for plugin developers. This allows plugin developers to enqueue new scripts or styles or dequeue existing scripts or styles from your theme's header and footer. Using wp_title(); allows plugin developers to manipulate your theme's title tag output. Great for SEO plugins. body_class(); can really be used for quite a bit. I really highly recommend you build support for this in all of your themes.

By default, WordPress already provides support for many events triggered in your theme if you're using those functions posted in the numbered list, above this section.

These "events" are referred to as Hooks, which allow plugin developers to add, modify, or remove code from certain areas within your theme. Or fire a certain event, when another event is triggered in your theme.

Which brings us to the next area you should be thinking about, while creating a "Plugin-Ready" WordPress theme.

Creating your own WordPress Hooks

It would be wise to learn how to create your own WordPress actions and WordPress filters, within your theme. This will allow plugin developers to HIGHLY manipulate your WordPress theme.

Simply just by using more of the default functions provided by WordPress core (Like the ones listed in the first numbered list at the beginning of this answer, or else here for a full function index), a LOT of the hooks that developers would need to use, are already defined by the core.

Do not ever be shy with creating your own WordPress hooks, within your WordPress theme. It's always better to have many many hooks available for developers to tap into and make use of, rather than not enough to do what they need to do.

Just remember to use unique references to your hook names. (They must be unique, so that they do not conflict with either existing WordPress Core hooks, or existing WordPress hooks created by other plugin developers.)

By creating your own hooks, WordPress plugin developers can hook into your custom created WordPress hooks using add_action(); and add_filter(); and configure the output or behavior of your WordPress theme, without actually making changes to your theme's core code.

Which is great, when you release an update for your theme, because their changes to your theme will be persistent and won't be over-written or lost by the theme update.

Step 1: single.php

Step 2: functions.php

In your functions.php we want to let WordPress know about this hook...

function after_post_content(){
do_action('after_post_content');
}

Step 3: In your plugin

As the name suggests, hooking onto after_post_content allows us to inject our own logic/markup right after the_content as shown in single.pgp. In this case, we are just echoing some basic phrases, however you might use it for injecting social media buttons, special adverts, e-mail subscription boxes or any other creative idea you can come up with...

Overall, the above ↑ is only a simplified example of how you can create hookable actions/filters for your themes but provides plugin or even theme developers/users readily accessible means to inject or filter content. Its a more efficient process and easier to manage.

My strategy was to make it kind of brainless and consistent so that one doesn't have to keep thinking up custom events all over the place. Note that my strategy provides a consistent way to handle POST, GET, reaction to $_SERVER variables and get_option() settings strings, and also a consistent way to handle pre and post content display. Now, granted, once this is done, however, if one wants to take it to the next level and add even more custom events as you suggest above, then yes, that's probably going to help, where warranted.
–
VolomikeOct 28 '12 at 19:54

@Volomike What are the inconsistencies you think exist with handling $_POST/$_GET variables etc in WP? Because I don't have a problem working with these responses, especially where existing WP hooks are concerned. Genuinely want to know your thought process on this. Although, I don't recommend your method, if you really had to do it your way you'd be better of using a wrapper function that you can use at the start and end of your template file that output your code which is too verbose to be scattered across template files in its current form.
–
userabuserOct 29 '12 at 13:49

See how easy it is to debug? Plus, because I use ALL CAPS on the variable name, I can find them easy in the HTML portion of the page. And why did I call it $view? Because it's shorter than typing $template, and because people who understand this style of variable injection usually know something called MVC (a computer science term) where V stands for View.

2) Move any library or class file includes to the top of the PHP file such as:

require_once('mailer.php');
require_once('gallery.static.class.php');

3) Following the library includes, set any constants or static pieces of information, or read from get_option() API.

4) Following the "settings" initializing area (step 3), do any $_GET, $_SERVER, or $_POST settings where you read those things and stick them into variables, or may need to do things on them like strip_tags(), stripslashes(), trim(), etc. Basically you should be doing any input processing, not doing any real hardcore programming yet.

5) Following the GET/POST variable processing (step 4), add this snippet of code, and note that I used "mytheme_" as a prefix for the theme name, but you can change "mytheme_" to something else.

Now that this is done, you can code a fresh plugin and when you use add_filter() or add_action(), your callback function will be given all the defined variables of the page (and the content as well if this is add_filter()), and you'll be able to pretty much override anything in the theme.

You can use echo "<h2>$sHook</h2>\n"; on your pages to document what all your event hooks will be.

Don't forget to do this even on the admin panels you create with your theme, not just the frontend of the theme.

Note on the several lines above you can reduce this a little with a couple functions, such as one for finding the hook name. Just don't put the line that has do_action(), apply_filters(), or get_defined_vars() inside a function or things will not act as you expect them to do.

I'm scratching my head alright. You ask a question and answer it within seconds with what appears to be a prepared answer of your own. That makes this question, a tutorial, not a real question. This doesn't seem like a practical way to make your theme "hook" ready. Instead, why don't you define hook locations in your theme files? Then in your theme functions.php file you create the function that relates to the hook and use a call to do_action within this function. Then you (plugins or theme users) can do the traditional add_action('my_hook', 'my_callback');. Same applies for filters.
–
userabuserOct 28 '12 at 9:13