Learn what you shouldn't do anymore when developing a D7 project.

1. The Drupal 7 Worst
Practices Catalogue

2. Hacking the Core
Don't hack the Core

3. Hacking contributed
modules
Contribute and log any patch on D.O.: then
you have a contributed patch that can be
applied automatically with drush-make
Use limited code getways for Custom
module compatibility
Having only a few lines to modify is not
an acceptable way to justify hacking
contributed code

4. Handmade Features
Use Features Builder
Contribute your approach

5. Versioning
contributed code
Use drush-make or Composer

6. Versioning dumps
& archives
Use a shared file system

7. Using Drupal
as a Php empty shell
Using Drupal module structure is not
enough
Writing code that pass Coder /
Code-Sniffer is not enough
Writing trully Drupal compliant
code

8. Placing files in
Core
Consider Drupal Core as a Vendor

9. Running Php code
out of modules
Adding Php code that can be
directly triggered is a security
threat

10. Using multi-sites
when not necessary
Multi-sites is mainly used for bad
reasons
Manage your code in Git and
deploy

11. Using DB prefix
when not necessary
Make sure your Drupal database is
only used by a given instance

12. Sharing DB tables
Use services

13. Writing functions
that can’t be tested
Even if you don't write test, you
should be able to write simple and
straight tests for your function
If one drupalist can't get it at first
read, refactor

14. Not using Drupal
API
Make sure you don't write code
already available in Drupal
e.g. Mail address format validation

15. Keeping dead code
You might have some disabled
modules, part of needed modules
package
Don't keep unused code

16. Don't keep multiple
versions of a module
Don't keep modules out of the
modules paths
If you don't use multi-sites, you
shouldn't have multiple versions of a
given module (except for overriding
Profiles versions)

17. Not using Views
You might have very targetting needs
and good reasons to write queries
in cutom modules
If you never use Views and believe
your code is always better, you will
be in trouble soon - and meet
maintainability and debugging issues

18. Using ancient best
practices
Multi-sites is an example of these ancient
best practices
Webform is another one: prefer EntityForm
Don't be afraid to move on, reconsider your
best practices once a year
Read blogs, meet others drupalists and don't
believe you know - check again everyday

19. Deploying content
with Features
Use Deploy suite (based on services) or
sync your database and files from Prod
while deploying
First af all: take a little time to define
what is content on each and every project
Design might be content, as much as
taxonomies and nodes

20. Managing
too much templates
When is too much? You actually already know it
If the workflow is driven by the Front (HTML /
CCS / JS) team, having a lot of templates is OK
as it's meant by the project organisation - and
the integrator might even directly work in the
theme repository
Otherwise, you might consider modules like
SemanticFields and SemanticViews to cleanup
Drupal code generation

21. Relying on Drupal
search
Beyong 100 contents, just use a real
search engine

22. Relying on Drupal
cache
Drupal native cache is very limited
and a little stupid
Many modules offer higher quality
solutions

23. Using a single
theme
Use sub-themes
Base theme should be technical and web standards
oriented
Sub-theme bears the design
If you expect to reuse this sub-theme on multiple project:
consider it as a Charte theme, and never enable it
Then use a project dedicated sub-theme that will be
enabled, and override the Charte theme: it might even
override nothing

24. Modifying admin
theme
Obviously, this is a contributed
module - so don't touch it
Create a sub-theme, and override
what is needed
Usually, you will have 5 items in a
custom CSS file

25. Mixing up Features code
& Module code
Acquia Commons is a good example
of this practice
It provides maintainability issues such
as impossibility to override features
Module code needs to be maintained
by humans, while Features is project
driven generated code

26. Keeping Dev tools
in Prod
(no comment)

27. Keeping too much
information in Prod
install.php, .txt and .md files from
Drupal root can be deleted
So is web.config if not using IIS
(or .htaccess if not used by Apache)

28. Storing database
dump in Drupal path
Find some other place