[wp-hackers] distinguish plugin options?

[Benedict Eastaugh]

> However in hindsight I can see how my generalization could be viewed as offensive and for that I'm truly sorry. I really didn't mean to offend especially for someone like yourself who can appreciate the value of both design and good software architecture. Apology accepted?

Of course. Thank you for the elegant apology. I'm sorry for snapping
at you, but your views are depressingly common on this list and
elsewhere: theme developers are not merely worse programmers, but are
actually incapable of following best practices. This is not a helpful
attitude, and will certainly not result in a rise in the quality of
the code of WordPress themes.

Making such a distinction also misleads in other ways. Obviously
themes and plugins are different in intention and effect, but they
also have much in common. Plugins can use get_option and set_option;
so can themes. Plugins can call the WordPress API, and extend it with
their own actions and filters; so can themes. Where coding standards
are concerned, there must be uniformity. Plugins and themes, and their
developers, must both be held to the same standards. However, raising
standards is better accomplished by encouragement, documentation and
evangelism than by insults.

> I was just explicitly describing the statistical bell curve as I perceive it; some people value good software architecture and not design, others value design and not good software architecture, and then still others value both. My assumption was that it would make sense that those who value good software architecture are more likely to develop plugins and those who value good design are more apt to develop themes.

I assume you mean visual design. I try to keep Frank Lloyd Wright's
maxim in mind when considering software: "Form follows function--that
has been misunderstood. Form and function should be one, joined in a
spiritual union." Obviously someone who knows little or no PHP will
not be able to write a particularly complex WordPress theme by
themselves, and they may commit more or less egregious errors in doing
so. But we should steer away from the assumption that these are very
different endeavours. We are, after all, designing interfaces for
users. It's not so far removed from designing interfaces for
programmers.