Naming your modules to avoid future name space conflicts
Avoid naming your modules with a prefix that is the name of a core module, or an active contrib module that you plan to use. Examples of this error include 'node_foo', 'comment_bar', and 'views_baz.' Better alternatives might be 'nodefoo', 'bar_for_comments', or 'bazify_views.'
Note that very many contrib modules do not conform to this advice. Do not take that as a license to ignore; each module that does so increases the risk for future modules.
For the reasoning behind this suggestion, and some examples of how conflicts could arise, seeand the following comments.
Name your variables correctly
Choosing the proper name for your functions is very important. But you should put the same care into naming your variables, too. Don't just use $i and $j all the time -- the name of the variable should make it immediately obvious what's inside it. If at all possible, look at core for example of variable naming conventions and then use them within your own modules.
Look out for restricted names too, because they exist, and using them when you shouldn't can lead to hidden and impossible-to-debug problems. (A list of these "reserved" variables should probably be compiled underneath this page as comments. Please help.)
Pay attention to singular vs. plural for scalars vs. arrays, too, since that can help you avoid programming errors simply by having the "grammar" of your code make sense.
Class vs Global Variable
You could also use a class rather than global variables. This way you can name the variables without needing to prefix them with the module name because they are contained in the object. Use magic functions __set, __get and __toString to control the variables settings via a private array.