Here are some bits and pieces of advice that I see many users should follow :

Speaking strictly DM:
When creating names of var's, proc's, verb's, etc. it's a good practice to follow this easy format : var_myVariable. (This part is completely optional and is only for personal preference: )You start with the type (var, verb, proc, obj, etc.) (This part is the major focal point in the format: )and follow it by lower-case and then Upper-Case the first letter of each following word.
So, obj_myFirstObject, verb_mySecondVerb, proc_objectDelete, etc. etc.
Not only does this clear the readability, but also stands as a process for handling things. If you see the word "var_myVariable", you'll know it's a variable to begin with. "obj_firstObject" will obviously be the first /obj.
Also, be sure to use commonly-used words. Don't go off and name a variable "var/x" or "var/as62345f". For example, if you have a variable to hold an X Coordinate, try :
var_xPosition
var_xLocation
var_xPos
var_xLoc

Know the difference between a /client and a /mob.
A /mob is NOT directly the player. The player themself is the /client. Every user of BYOND who joins a game can only have one /client, and each individual /client can control multiple /mob's.
So, if you were to design an "Administration/Moderation" system, don't use /mob whatsoever since /mob's can change at any moment and thus the Administration/Moderation is either lost, or bugged.
Go with /client verb's. Not only will you easily be able to integrate them into buttons via the Interface, but they are more safe and secure.

Don't clutter up your code into as few /proc's and /verb's as possible. Spread them out a bit. Not only does this serve for readability but if a proc calls another proc but then fails, that second proc will still run, if you want it to.
There's also some more reasons why you would do this. Most commonly, the reason is debugging.

Do not spam your hub with large graphics and/or text that is very irrelevant. A prime example is the "Clans" or "Ranks" that most Anime-Games use. These should belong on a separate website, forum, or in-game.
Keep hub-related things as hub-related things, not in-game related things.

Avoid using as many /obj's and /mob's as possible. If you can, combine whatever you want to happen into one bigger /obj. Follow the Rinse'N'Reuse strategy. Don't delete an /atom that you can easily configure via run-time and reuse it. There is a limit on how many atoms you can have, keep in mind. Also, when players or /client's are not in the range of another /mob -- assuming that it is an N.P.C. or a Not Playable Character --, let it sleep. Give it a break, let it relax. It has no function whatsoever if there are no players to function with. Now, this does have it's obvious exceptions like /mob's handling certain things. I once used a system that had NPCs smart enough to carry on conversation with each other and follow a routine/chores list. The conversation part was obviously not called unless a /client was nearby.

Always keep track of what you are doing. Use the // and /* */ comment functions to keep a note of what something specifically does. For example :


mob/var/var_baseHealth = 0;
// The minimum Health of a player without bonuses/boosts/extra.;
mob/var/var_maxHealth = 100;
// The maximum Health a player can reach.;



When actually creating a big-time project or game, keep your resources and files organized. It's much more easier to locate something especially when your project grows. I generally use a sub-category such as :
/my_Project/Sound
/my_Project/Graphics
/my_Project/Code
/my_Project/Maps
etc. etc.
P.S. Sub-Categories : I mean folders within a folder.

Also, strictly speaking on Code... Try to develop your systems to be independent. What I mean by this is try to create your systems as if they were Plug'N'Play or Libraries. This will serve good use if you ever make another project or if you want to add/remove a system in your current project with ease.

It's also generally wise to produce a Design Document before actually developing your project. This includes information such as:
Project Name.
Date.
Purpose of Project.
Required Resources/Information for Project.
Procedure or Guide-Line on developing the Project.

On average, BYOND users will seek the help of pre-made Sources/Demos/Libraries/Code Snippets to use as the "Core" of their project. This is absolutely horrible and should never be done. Using another piece of code should and only should be used as a library and not the copy+paste+edit method most BYOND users use. You will learn little to nothing except how to edit code someone else made. This doesn't help you if you need to know how to make your own code if none are available. Try imagining you have no internet for a whole year and your project needs to be completed in two months. Yeah, sucks to be you. I'm not saying it's bad to use Demo/Libraries/Code Snippets, but don't abuse them. Key word : Abuse.

When generating/designing an interface, I notice many people are having a very difficult time create a One-Interface-Fits-All. Why? Because they aren't being creative. There shouldn't be a limit on your interface size. Remember that the default screen-resolution on just about every computer is 800x600. So stop basing your interface on greater resolutions and start basing them on the average default. Not everyone uses your computer, so think that way. Try not to clutter an interface with lots of output's and input's. The Statpanel is old and very out-dated to today's time. Start looking into grid's, label's, button's and etc. A small view or map-size is also a big no-no unless your game specifically requires it. Screen-Resolutions are becoming a big trend as newer monitors, GPUs and etc. are hitting the market with more performance and less limitations. So a small 8x8 view is going to hurt your players' eyes if they have a huge screen-resolution.

"Downloading Resources" versus "Actual Content".
If you for some odd reason have an abnormal download size to your game and yet it has very basic to boring game-play, you have a serious problem that needs attention. Your game should be as good as the download size. Avoid using huge audio files. The largest .mid I regularly listen to is 58KB. That's pretty good considering the song is quite long -- roughly 6minutes and some odd seconds. The .mid loads perfectly and plays perfectly without any choppy game-play or latency (lag).
The same should go for your Graphic files too. A large size for an image is very messy and I would recommend searching for Audio Compressors and Image Compressors.

Everybody does enjoy beautiful looking games. Well, that's nice and all but if the game has ugly game-play, it's only good for it's graphic quality. What tends to happen if a game is only visually-appealing? The visuals get ripped.

"A book cover can rock your world, but the cover should only compliment the quality within the story on the pages."

Okay so enough of DM Language and Programs.
Let's say you decide to make a blog post:

A) Do not go into detail about some tragic break-up between you and your lover. It is sad to hear and some people might feel bad or pay attention to you but that's just it. You make yourself appear to be an attention-loving freak.

B) Do not single an individual/group out and insult them. By law -- in many areas of the US and some of the world -- harassment over the phone/internet is considered a crime. It's name is Telecommunications Harassment a.k.a. Aggravated Harassment and you can be sued and have charges against you. Also, you plain out make yourself appear jealous and shows us you have a very weak mentality.

C) We LOVE development news. It doesn't matter if you added just one icon or changed something around, we love hearing the changes/additions/removal of things on your project/game. This is a game-developing community after all. Also, this improves your self-motivation as you'll most likely receive criticism. Speaking of criticism, take negative and positive equally. They show you the opinions of potential players/followers.

D) Do not just instantly post something. Do research. If you haven't noticed by now -- and you better know by now -- there are MANY search boxes located all around the BYOND website. If for some strange reason you cannot comprehend this, you shouldn't be asking questions or making posts. Do your research first.

E) Do NOT reply to the wrong person. There is a HUGE difference between clicking Person A's reply button and Person B's reply button. Replying to the wrong person instantly brings your post off-topic since it's not directed in the proper way. This is just one of the very basic things of group-conversation.

F) Do not review a game and leave out the actual review. Grade fairly and "Overall" actually means OVERALL. As in A + B + C / 3.
Do not review your own game, this instantly shows us there will be a lot of biased opinions.

Do NOT give away rewards for Donations. Donations are DONATIONS. They are GIFTS. Gifts have no "set-in-stone" that the giver should receive something back. This mainly applies to Fan-Based games -- yes, Anime is included in this as well as games like Bomberman Clones or Pacman Clones for example. You are NOT to profit from another individual/group's work. This includes Audio, Graphics, Code, Names, etc. etc.
You CAN however take in donations and leave it as that. You just cannot give ANYTHING in return. No special verbs, no special font color, etc. etc. The reason why I say this is because you never know what could happen, and it's been proven on multiple accounts that lawsuits and charges have been pressed for theft.

If by some absolutely unforgivable reason your ripped-game's source is leaked, you are out of luck. Or as they say "Shi- Out Of Luck." Because you just are. Don't complain about it, don't argue about it. There's nothing you can do because you don't own the rights to the original source in the first place.
Also, if you send out your source to someone else, be prepared that they will distribute it to others. It's common sense, don't trust people you don't perfectly know. There is NO good excuse as to why someone would need your source, icons, etc. etc. They should be able to produce what you require without anything to start with.

Also, please don't forget to become a Member today! Or, simply donate to BYOND -- Or me, if you really want to --, if you can to keep this glorious community thriving!