[support] Ten Commandments

[Ms. Nancy Wichmann]

Calling them the "Ten Commandments" was a bit of a joke because I am starting on the road to ministry. The only one that might really be a commandment is "Thou shalt not hack core." And if I have a really serious need for that, I will discuss it with the team and get their blessing before proceeding - and I will also submit a patch to core (same with contribs). However, given that the vast majority of our sites live in multisite environments, hacking core is close to impossible.


Otherwise, these are guidelines, not hard and fast rules, and the official title of the document reflects that. Yes, there are cases where, for example, a bit of PHP in Views is not only expedient, but the only way to go. What we want is for these cases to be discussed - and documented - when they arise.

"PHP filter is part of core" - true, but if you used Drupal before 6, perhaps 
you noticed a change. It is now optional where it used to be standard. 
This is because so many security holes were exposed by using PHP. When I started out (4.7.8 I think), another helpful Drupaller hacked my site just to show me how easy that was. After that I learned how to write modules, where PHP belongs.

Modifying theme functions is awfully close to modifying contribs. Updates may wipe them out without warning. Modifying SUB-theme functions is slightly better. But of all the sites I have built, I find it uncommon that I need to do this. CCK's (and now core) "manage display" is great and often avoids the need to do much of that. And hook_preprocess_HOOK is another great boon to avoiding such mods.


We have upwards of seven Drupal developers working on several projects. If each follows their own style, then it gets harder for someone else to work on it later. Following the style to which core and contribs are held just makes life easier for everyone. As a contrib developer myself, I now find it impossible to not follow those standards. I even install Coder on my development sites to make sure I didn't inadvertently miss something (and rarely do). Call me anal if you want, but few people who know me will agree with you.

As I said elsewhere, I agree, this is not going to make a bad developer good, but it helps find reasons to get rid of them. I am equally convinced that some guidelines, like these, help good developers be better.

 
Nancy 

Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.



>________________________________
> From: Patrick Avella
>I think what it really boils down to, is that there are good
>developers, and lousy developers. No amount of guidelines, style
>guides, conferences, or annual reviews is ever going to "fix" a bad
>programmer.
>
>A good programmer has their own unique development style and can both
>understand and replicate another programmer's unique development style
>(in this case, drupal coding standards for example).
>
>A bad programmer just makes spaghetti out of everything no matter how
>much hand holding you do, and these are the people that need to be
>shifted out to less technical support type positions (AND NOT ELEVATED
>to management).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20120920/93784bfb/attachment.html