0
Many years ago, a bright-eyed young modder named FuSoYa compiled a list of the most common mistakes modders make in their products. Over time, this list was lost in some forgotten corner of the internet. Today this list was found again, I am publishing it here because this list will be the basis of another future project of this site, and I don't want to lose this info again. 
******************************
Here is a list I just threw together of some bad habits I have seen on how some mods are being written. Each of these items is something that, as a mod maker, you should always try to avoid doing. There are probably others, but I think this list is a good place to start. Oh, and these are all IPB 2.x specific, a couple of these are OK to get away with in IPB 1.x.
Never edit a skin file directly
In IPB 2.x, you should never be editing a skin file directly, there is big text at the top of these files that says this. You should always give instructions to edit the skins via the ACP if they are just edits, or make an installer that will add template bits if some needed added. The reason for this is that if you edit a skin file, then later go back and edit this same skin file via the ACP, your first edit will be overwritten.
Never just include a skin file to upload
Like above, all skin edits should be done via the ACP. If you just give the skin file, then people won't be able to edit it via the ACP, they'll have to edit the file. While you can technically get away with this, it is sloppy. Make an installer that will create this skin file, there are plenty of mod makers out there already that do this that you can base your installer's code on.
Never hard-code text
You should never hard code text (actual words that would be seen on the screen) in the skin templates or source files. Text should always be stored in the language files. Not everyone runs an English language board, or even a board that just uses a single language, they have to be able to localize whatever text your mod is going to produce into whatever language they are using.
Never hard-code HTML
Kind of like above, you should never have sections of your mod's source code that does something like return a string that is HTML code in order to get something to print out on the screen. Have it return a skin template that they can edit via the ACP. Not everyone uses as skin that will look good using the HTML structure that the IPB Default Skin uses (which is what most mod makers use to base their own mods HTML on), and most places aren't using just one skin. People have to be able to use your mod on whatever skin they have, and be able to customize any HTML elements via their skin templates.
Never make your mods 'obvious', code/file-wise
It's good practice to make your code flow with the rest of the code, don't make your sections stick out like a sore thumb. Likewise, use the default file structure that IPB has instead of making your own folders and such to put files in. Doing it otherwise is sloppy and disorganized. If you continue with mod making into some sort of professional development-type job, you'll find companies can be sticklers for keeping stuff organized.
Never make the people installing have to edit files when they don't need to
The fewer edits people have to make, the better. If you have to edit a file, try to keep all of the code together into one block. If it's a huge block, put it in an external file and call it that way. Try to use the module/component system so that people don't have to edit as many files. If a mod just has people upload files and run an installer, people will love it.
Never make the people installing have to run queries manually
Making an installer that will run a couple of queries is easy, don't tell people to run manual queries in their MySQL Toolbox. There are plenty of installer files in our database to look at that will give you the basic code to connect to the database to run queries, people are a lot more willing to upload and run files than they are to log in to their ACP and run a query.
Never use variables that people can't understand
If you're going to use variables, make them easy enough to understand. People may want to build upon your mod, and if you are using an $ipsclass->vars called something like 'o_n_t', people are not going to readily understand what that stands for.
Never make an installer that gives no feedback
If you have to make an installer to do some database work, at least make sure it spits out something understandable to the end user when it is done. Don't make an installer that just sits there on a white screen when it is done. People aren't sure what the white screen means, and they may try to re-run it.
Never add to conf_global.php or ipb_templates.xml
These files never need to be edited for any reason. conf_global.php now only stores a very select set of settings, you can edit what is in there in case you move servers or something, but there is really no reason why you'd want to add a setting to there. Same with ipb_templates.xml, it is an XML holding the master skin templates, but that stuff is in the database too. You can make an installer that will add to the database copy of the master skin set, and then recache the children skins to get these changes, you should leave this ipb_templates.xml file intact because you never know when you'll need to determine which skin templates are 'really' the default.
******************************
Years later, much of this list is still valid, and many of those mod making problems are still being committed. Expect at some point to see this list updated with fresh new IPB3 information and actually put to a good use.
******************************
Here is a list I just threw together of some bad habits I have seen on how some mods are being written. Each of these items is something that, as a mod maker, you should always try to avoid doing. There are probably others, but I think this list is a good place to start. Oh, and these are all IPB 2.x specific, a couple of these are OK to get away with in IPB 1.x.
Never edit a skin file directly
In IPB 2.x, you should never be editing a skin file directly, there is big text at the top of these files that says this. You should always give instructions to edit the skins via the ACP if they are just edits, or make an installer that will add template bits if some needed added. The reason for this is that if you edit a skin file, then later go back and edit this same skin file via the ACP, your first edit will be overwritten.
Never just include a skin file to upload
Like above, all skin edits should be done via the ACP. If you just give the skin file, then people won't be able to edit it via the ACP, they'll have to edit the file. While you can technically get away with this, it is sloppy. Make an installer that will create this skin file, there are plenty of mod makers out there already that do this that you can base your installer's code on.
Never hard-code text
You should never hard code text (actual words that would be seen on the screen) in the skin templates or source files. Text should always be stored in the language files. Not everyone runs an English language board, or even a board that just uses a single language, they have to be able to localize whatever text your mod is going to produce into whatever language they are using.
Never hard-code HTML
Kind of like above, you should never have sections of your mod's source code that does something like return a string that is HTML code in order to get something to print out on the screen. Have it return a skin template that they can edit via the ACP. Not everyone uses as skin that will look good using the HTML structure that the IPB Default Skin uses (which is what most mod makers use to base their own mods HTML on), and most places aren't using just one skin. People have to be able to use your mod on whatever skin they have, and be able to customize any HTML elements via their skin templates.
Never make your mods 'obvious', code/file-wise
It's good practice to make your code flow with the rest of the code, don't make your sections stick out like a sore thumb. Likewise, use the default file structure that IPB has instead of making your own folders and such to put files in. Doing it otherwise is sloppy and disorganized. If you continue with mod making into some sort of professional development-type job, you'll find companies can be sticklers for keeping stuff organized.
Never make the people installing have to edit files when they don't need to
The fewer edits people have to make, the better. If you have to edit a file, try to keep all of the code together into one block. If it's a huge block, put it in an external file and call it that way. Try to use the module/component system so that people don't have to edit as many files. If a mod just has people upload files and run an installer, people will love it.
Never make the people installing have to run queries manually
Making an installer that will run a couple of queries is easy, don't tell people to run manual queries in their MySQL Toolbox. There are plenty of installer files in our database to look at that will give you the basic code to connect to the database to run queries, people are a lot more willing to upload and run files than they are to log in to their ACP and run a query.
Never use variables that people can't understand
If you're going to use variables, make them easy enough to understand. People may want to build upon your mod, and if you are using an $ipsclass->vars called something like 'o_n_t', people are not going to readily understand what that stands for.
Never make an installer that gives no feedback
If you have to make an installer to do some database work, at least make sure it spits out something understandable to the end user when it is done. Don't make an installer that just sits there on a white screen when it is done. People aren't sure what the white screen means, and they may try to re-run it.
Never add to conf_global.php or ipb_templates.xml
These files never need to be edited for any reason. conf_global.php now only stores a very select set of settings, you can edit what is in there in case you move servers or something, but there is really no reason why you'd want to add a setting to there. Same with ipb_templates.xml, it is an XML holding the master skin templates, but that stuff is in the database too. You can make an installer that will add to the database copy of the master skin set, and then recache the children skins to get these changes, you should leave this ipb_templates.xml file intact because you never know when you'll need to determine which skin templates are 'really' the default.
******************************
Years later, much of this list is still valid, and many of those mod making problems are still being committed. Expect at some point to see this list updated with fresh new IPB3 information and actually put to a good use.
I was aware of it back in the IPS Beyond days and have just rediscovered it on IPSR