Mfrhtyj

Here is what I usually do:

1. Always develop with error_reporting on.


2. Always develop with isDeveloperMode set to true. Just add SetEnv MAGE_IS_DEVELOPER_MODE 1 to your httpd.conf file (or corresponding file for Nginx or something else)


3. If the extension is linked to a core functionality add the
   dependency in the declaration file <depends><Mage_Catalog /></depend>
   


4. If the module is for community use, use community as codepool to
   give the developers the chance to override some classes without
   modifying the code directly


5. Put your frontend design files in app/design/frontend/base/default
   to make them available for all themes.


6. Put your admin design files in
   app/design/adminhtml/default/default and do not change the admin
   theme. I may want to change it in one of my modules.


7. Prefix your layout file names and template folder name with the
   company name to make it easier to isolate them.
   easylife_articles.xml and app/design/.../easylife_articles
   


8. Put your static resources (JavaScript, CSS, and images) in a similar folder as
   the template files easylife_articles/images/doh.png
   


9. Attach a simple text file with how to uninstall the extension: What
   files need to be removed, what tables need to be dropped, what
   config settings need to be removed from core_config_data table.


10. Do not write queries directly in models, blocks or helpers, use a
    resource model for that.


11. Do not write queries using the table names directly Select * from
sales_flat_order where .... Use a Zend_Select and transform the
    table names using ->getTable('sales/order').


12. Use the base url to include js files in template. Wrong
    <script type="text/javascript" src="../js/some.js"></script>.
    Right <script type="text/javascript" src="<?php echo Mage::getBaseUrl('js').'some.js'?>"></script>
    


13. Do not rewrite classes unless is necessary. Use observers and if
    it's not possible to use helper methods that receive as parameter and
    instance of a class that you wanted to override. Wrong:
    Override Mage_Catalog_Model_Product to add the method
    getProductArticles(). Right. In your helper add
    getProductArticles(Mage_Catalog_Model_Product $product)
    


14. If you override classes put a list of them in a readme.txt file


15. Use the default admin path for the admin section of your module.
    Wrong admin URL articles/adminhtml_articles/index. Right admin URL admin/articles/index
    


16. Add ACL for your admin sections. I may want to restrict access to
    some of the administrators.


17. Do not add another JavaScript framework (jQuery, MooTools, etc.) if it's not
    necessary. Write you code in the prototype.


18. Make you template HTML W3C valid (this is for OCD developers like myself).


19. Do not put images in the media folder. Use skin. The media
    folder usually is not versioned and this makes it harder to move the
    website to different environments.


20. Test your extension with flat catalog on and off. In order not to double the development time, use Chaos Monkey.


21. Test your extension with cache on and cache off.


22. Avoid using uppercase letter in the module and class names. If not
    properly tested this may cause issues on different OS. This is more a recommendation, not a 'must'.


23. Dispatch events in your code to make it easier for developers to
    alter the functionality.


24. Follow the same coding standards that Magento uses and comment your code.


25. Do not use PHP short tags (<? $this->doSomething() ?>). Use full tags (<?php $this->doSomething()?>). Also don't use short echo tags, yet. (<?="D'oh";?>). Use (<?php echo "D'oh";?>)


26. Translate your texts using $this->__ and add the locale translation file with your texts (app/local/en_US/Easylife_Articles.csv) at least for en_US language. Not all websites are built in English and the identification of texts to translate is time consuming.


27. If you sell an extension offer at least basic support. Or at least
    answer the support e-mails you receive.


28. Do not make constant calls to your servers through your extension for licence validation. Once, at installation is more than enough (I don't like this approach either, but it's better than to make calls all the time).
    (Inspired by this question)


29. Develop with the log activated and from time to time take a look at
    the var/log/system.log file. The errors listed here are not shown
    even with developer mode on. If there is at least one error you end
    up with a large log file after a few months of running the extension.


30. If your extension affects the checkout process or the orders in
    some way, make sure it works with multi-shipping, or if it
    shouldn't work with multi-shipping, make sure it doesn't affect it.


31. Do not replace the default Admin Notification bar (or feed URL). If
    I'm interested in what you have to offer I will subscribe to your
    newsletter. Let me see what Magento has to say. It's more important
    to me.


32. If you encrypt your code files with Ioncube (or something
    else)...well...I just hate you and I hope your business goes bankrupt

That's what have so far. I will add more as soon as I think of something else.

I am a big fan of using modman so that I can develop and source control just my extension and leave the core files and folder structure unchanged. It is also makes testing across different installations run smoother.

Oh and one massive tip always try to install your packaged extension locally on a clean install of magento before uploading it to Magento Connect, I have missed out files so many times in the package manager.

Andreas von Studnitz and Dr. Nikolai Krambrock gave a good presentation on code quality on the Meet Magento DE 2014. They distinguish between general code quality and Magento-specific code quality. In short there are following general rules:

• The use of structure elements - just like classes and methods - should be arranged in middle seizes classes. These elements of structure only make sense when they are used for structuring. Therefore they have to be of medium size. It is regarded to use 100-200 Lines of Code for classes and 3-20 Lines of Code for methods.


• Because of the use of "if" or "while" the code is indented. If there are more than 3 indentations it is better to revise them. Too many indentations are an evidence for the code's complexity and should therefore be avoided.


• Dead Code should be avoided and deleted. Static analyses help finding it if one exists.

Even more important are the Magento-specific rules:

• Modules should work independently. They should only have little dependency on other modules and no dependency on templates. A solution is to use layout-updates (base/default) instead of adaption to template files and a module that covers additional functions of the template.


• To maintain the ability of updates in Magento core-hacks and hacks of external modules should be avoided. A better way is the use rewriters or observer instead.


• For changes it is better to use setup scripts instead of direct changes of the database or of the admin. Thanks to them changes have to be done only onetime.

Here are some more details and a video of the presentation:
http://www.code4business.de/code-qualitaet-magento/

If you sell your extension or share it with others, think about writing code that is human readable.

1. don't make method too complex


2. add DOC blocks to your methods


3. use proper variable names, like $productIds instead of $ids
   


4. same for methods, public function myOnProductSaveMethod() {...} says ... nothing , but tryDisableInternetOnProductSave() will give a hint want's planned


5. use type hints where it makes sense someMethod(Varien_Data_Db_Collection $collection)
   


6. avoid magic numbers and strings ^*


7. if you use models set $_eventPrefix property (and $_eventObject) to make them better accessible to observers


8. if you add system config fields
   
   
   
   
   • set default values in config.xml
     
   
   
   • add <validate> nodes to fields in system.xml
     
   
   
   • add ACL resources to adminhtml.xml
     
   
   
   
   


9. do not add useless/advertising first-level menu entries in admin backend - neither in topbar nor in config sections


10. add ACL resources for all controller actions (massactions too!)


11. ensure your queries work with DB table prefixes
    


12. think about (no) backward comptibility (this is really opinion based)
    
    
    
    
    • do not support Mysql4 classes
    
    
    • do not use deprecated methods
    
    
    
    


13. ensure your extionsion works as expected in every case - add UnitTests (PhpUnit for example)


14. in addition to David Manners ... add a composer.json too to make deployment easier

^{* Often used:}

• admin store ID
  
  
  
  
  • 
    0 > Mage_Core_Model_App::ADMIN_STORE_ID
    
  
  
  
  


• product status
  
  
  
  
  • 
    1 > Mage_Catalog_Model_Product_Status::STATUS_ENABLED
    
  
  
  • 
    2 > Mage_Catalog_Model_Product_Status::STATUS_DISABLED (not 0 as maybe expected)
    
  
  
  
  


• product type
  
  
  
  
  • 
    simple > Mage_Catalog_Model_Product_Type::TYPE_SIMPLE
    
  
  
  • 
    bundle > Mage_Catalog_Model_Product_Type::TYPE_BUNDLE
    
  
  
  • 
    configurable > Mage_Catalog_Model_Product_Type::TYPE_CONFIGURABLE
    
  
  
  • 
    grouped > Mage_Catalog_Model_Product_Type::TYPE_GROUPED
    
  
  
  • 
    virtual > Mage_Catalog_Model_Product_Type::TYPE_VIRTUAL
    
  
  
  
  


• product visibity
  
  
  
  
  • 
    1 > Mage_Catalog_Model_Product_Visibility::VISIBILITY_NOT_VISIBLE
    
  
  
  • 
    2 > Mage_Catalog_Model_Product_Visibility::VISIBILITY_IN_CATALOG
    
  
  
  • 
    3 > Mage_Catalog_Model_Product_Visibility::VISIBILITY_IN_SEARCH
    
  
  
  • 
    4 > Mage_Catalog_Model_Product_Visibility::VISIBILITY_BOTH
    
  
  
  
  

Same for SQL order ASC vs Zend_Db_Select::SQL_ASC (for example).

Saying "it's not nessessary cause it will never ever change"? For example entity ID for catalog_product attributes changed somewhere between Magento 1.5 and 1.9 from 10 to 4, so this could break your extension:

$collection->addFieldToFilter('entity_type_id', 10)

Using this instead adds one query, but you'll be safe ...

$entityTypeId = Mage::getModel('eav/config')

    ->getEntityType(Mage_Catalog_Model_Product::ENTITY)

    ->getEntityTypeId();



$collection->addFieldToFilter('entity_type_id', $entityTypeId)