Dumb code ideas from a dumb coder. For dummies.

This is a list of dumb softcode ideas from a softcode dummy.

Basically I'm not going to put any 'real' code up here just a set of guidelines that have worked out for me in learning how to softcode. And to any and all reading this - I SUCK at softcode. These are just a list of basics, tips and tricks that have helped me as I've begun learning how to seriously code systems in.

First: If you have an idea for an object, system, or mush - write it down!
When I say write it down, I mean that you need to write out exactly what you want the widget to do. If you want to be able to type in command +foo and have it output GAME: Bar, and set attribute &baz on the enactor....write it down. Write all the commands down that you think he object should have. Make an outline of what the thing does, and how the people interact with it. This seems like a lot of extra work, and upfront it is a lot of extra work; however, you're putting your ideas down to first give them some concrete form that will sit there and mock you until you actually get off your arse and code the smelly old thing. Secondly and most important - it will give you a list of goals to meet, easy goals, things that you can look at and work towards. When you acheive goals in your code, it will spur you on to code more, and instead of having the goal 'get the whole thing written' you'll feel much better about yourself by acheiving more goals, and more often. Less chance of getting discouraged.

Second: Start small. This kind of ties in to the first point. Start with a small system or object and figure out how to make it do what you want. Run lots of tests, figure out what the various commands and functions actually /do/. Run the examples in the help files (you DID read the help files, didn't you???). This will help you break off a chunk of knowledge and digest it slowly. Code is best digested in small chunks.

Third: Find a text editor you're comfortable with. I personally like Vim (http://vim.org). I like it because it natively handles syntax highlighting and indentation for mush code. If all of this is greek to you, look it up on google. Syntax highlighting can really help you out when you're starting to learn. Putting extant code in a text editor and breaking it up down to the function level will help you process what you're seeing in small chunks. Don't believe me? Look at Python. Or C. Or lisp, or Perl, or, or, or....you get the idea. These folks that use these languages have long known the value of breaking up data into small bits of understandable code.

Fourth: Practice 'modular' programming. Use u() in your code. If you don't know what u() is and why you should use it, go look at the help file. I'll wait for you....Good. Now that you're completely confused, ask about it on M*U*S*H, or another helpful social mu* out there. u() is likely one of the most important and most under-utilized functions out there by new coders. What u() allows you to do is write a command out that fits on (almost) a single line and calls in seperate functionality from other smaller bits of code that do a specific task. This makes your code modular...it also makes it so that you can re-use code over and over again in the object or system...heck, even in the game - call the ufunction from other objects!It'll save you lots of time and headache later. Trust me on this.

Fifth: I can't stress this enough. I CAN'T STRESS THIS ENOUGH. No puedo tensionar este bastante. (blame poor translation on babelfish) Comment your code. For the love of all that you hold sacred and holy. Comment. Your. Code. I don't care about whether you're going to share your code with someone else later, or whether you're going to pack it all up and throw it into the ocean. Before you do either of those, some indeterminable amount of time is going to pass and you're going to have to come back to this code to fix something, see how you did something so you can redo it in a similar fashion, or to add something to it. I find it's easiest to use comment attributes. If I write a command, c.action, the function it calls might be f.actionfunction, then each attribute gets a comment attribute. &#-c.action explains everything going on in c.action. &#-f.actionfunction explains everything going on in f.actionfunction. This will save you much time later on pondering 'what the hell was I thinking?!?'. Plus, later on if you /do/ share your code with someone else, they'll know what you were intending for a particular bit of code. It only takes a few minutes (especially if you modularize your code as in step four) and you'll be saving yourself time, effort, and energy in the future.

Sixth: Ask questions. Lots and lots of questions. However, the real step here is: Shut up and listen. When you're on M*U*S*H and you ask how to do something...listen to the people that answer. Ask clarifying questions. Don't be afraid of looking or sounding stupid. The only way people will think you're stupid is if you ask a question, then totally ignore everything people are telling you. Remember - there's always more than one way to do something. People will try to give you the best way to accomplish the goal you're trying to reach in the easiest manner they know how. They may not know the easiest way, but they are still trying to help you, so if nothing else, give them the courtesy and respect they are giving you.

Seventh: Learn how to use the quote file functionality in your client. If you're using Tinyfuge, type /help quote. If you're using something else, find out if it has a quoting functionality. If it doesn't, use a client that does. This will save you lots and lots of pain, strife, and headache. If you're using your text editor, don't copy/paste it from one to the other - especially if it's lots of code. This is tedious and prone to errors in buffer input limits. This way you write it once, easily with as little heartache as possible, and then quote the file in, letting the client and the mush handle the work of actually getting the attributes to the object (this is also a good way to build - you can always come back to a project this way if you're interrupted in the middle of it and you have everything that has gone on before right there in front of you.)

Eighth: If you're learning to code, remember - you're not going to get this stuff overnight. It's just not going to happen. Don't get discouraged when you can't get something to work. Put it down and go do something else for a little while. Roleplay, or talk about something entirely different that will get your mind off of it. After some down time, go back to it, look over what you did, check it against your outline/list of goals, then re-work it so that it'll work, or patch the niggling little error that you missed the last 300 times you looked at it.

That's it for now. I don't have anything else rattling around in my brain that I can think of that may help someone. If anyone else can think of anything that I've missed, please feel free to add it in the comments.

Also, as an addendum and a word of warning/full disclosure: These are the things that work for me. They work well because I stick to them and use them for everything that I do. In all things have a set of standards you adhere to (even in attribute naming conventions!) and that will help lighten the burden of how to acheive the 'how' of your code project. Invariably there are other ways to do this crazy thing we call code, but this is a method that works for me. If it works for you, great! If it doesn't, take what works for you and apply it, throw the rest away and develop your own methodology of working.

Tal