Mine little quirks are:
-I use a folder system, 'Icons', 'Programming'-'A-M','N-Z'
-I generally have one system per programming file
-Ontop of that I generally make my programming incredibly modular, believing in the great power of reusing code
-I leave an example of how to use my programming at the top of the file
-I don't always comment, but when I do, I find myself being hilarious
-I like to keep procs simple, generally having a 'master' proc that will do a long string of procs in a row. Again for modularity
Small example of programming that I just did:
/*
mob/verb/Make_Name(var/T as text)
var/message = ewnh_checkName(T)
if(message == 0)
ewnh_characterNames += T
world<<"Name added to registry!"
else
world<<"[message]"
*/
var
list
ewnh_characterNames = new/list()
ewnh_disallowedCharacters = list("<",">","/","\\",{"
"})
ewnh_disallowedWords = list("tallywhacker","bottom")
proc
ewnh_checkName(var/name)
if(!name)return "No Name"
if(ewnh_checkLongName(name))return "Name Too Long"
if(ewnh_checkDisallowedCharacter(name))return "Disallowed Character"
if(ewnh_checkDisallowedWord(name))return "Profain Langauge"
if(ewnh_checkDuplicateName(name))return "Name Already In Use"
return 0
Since my stuff is so descriptive (I like to think), I don't have the need to comment as much. Obviously I haven't included the actual procs in this, but do I really need to? You should be able to tell what each one does exactly.
Edit:
Oh incase you're wondering what all the ewnh_ stuff is, it's so that everything's very specific to that file. I can reuse variable names, for example I might have a disallowedWords variable within a spam filter, so that would be ewsf_disallowedWords.
Some might argue this is a bad way of handling it and I should just reuse the same variables (What are the chances of me allowing certain words in names but not the spam filter?) but I say phooey to you!
-Wookie
1. You have to remember that "ewsf" means "spam filter". This isn't a problem when you're in the spam filter file looking at tons of vars and procs that have the ewsf- prefix, but when you're in another file trying to refer to spam filter functionality it won't be as clear.
2. Trying to define the disallowedWords var twice (once for the spam filter and once for character naming) could mean that the variable names need to be more specific or that both systems should use the same var.
I'd also change the proc names. By looking at the code I can tell that ewnh_checkLongName returns true if the name is too long, but from the proc name alone you wouldn't know that. If it was called ewnh_isNameTooLong it'd be more obvious. It's one less thing you have to remember.
I'm not sure what that means exactly but I don't write a lot of comments either. I only comment heavily when it's code that other people might be reading. The Sidescroller library has ~5800 lines in .dm files but ~1300 are comments (21%). Tiny Heroes has ~7000 lines but ~670 are comments (9%). Both have about the same amount of whitespace (20% for SS, 18% for TH).
Being modular doesn't just help because you can reuse code
It also helps because you can change how the code works without needing to change all code that references it. In your example you can easily change how ewnh_checkName() works and you don't need to change how it's called.
It also helps to limit how much you need to remember to use the code elsewhere. Suppose you wrote ewnh_checkName like this instead:
Because you wrote it as a self-contained module, you just have a proc that takes a name and returns an indication of whether or not it's an acceptable name. It's very easy to use. If you had done things this way, you'd need to remember all of those arguments and it'd be a hassle to use this proc elsewhere - you'd probably have to flip back and forth between .dm files to double check the order of the arguments every time you wanted to call it.