I was looking at TheCProject website thinking "all these professionals will have some great examples of how to set up a project in the most efficient and organized manner". I was wrong.

With this kind of code all over the net, it's obvious why people learn so many bad habits. Even the advanced open sourced projects were riddled with poor code architecture, and I know on BYOND I've only seen a few people design their codes well.

I'm as guilty as any of these people, but this year I learned of the repercussions of designing your code poorly, and now I'm even embarrassed by my old codes. The only way I was able to learn good habits was by working with a professional team on a pricey project.



So, I give these tips to anybody reading this:


1. Design your code assuming professionals will be judging it.

Make your code something to be proud of. You may need to show it to people in the future.


2. Keep your code clean, readable, and partially commented.

If it's a library or demo, people need to be able to understand it, and if it's a private code, you need to be able to understand it even after a hiatus. Also, white space is your friend.


3. Design your code modularly.

Modularity is making a set of objects mainly work within themselves (i.e. a library). It will make your code fully extensible. Most of my old codes are near impossible to edit because the modules are intertwined with each other so badly. It will also allow you to reuse your codes later on without needing to recode.


4. Separate definition from implementation.

I'm not sure how doable this is in BYOND, but when you design a contract for other objects and other versions of your program (on your computer or someone else's computer) to work with and don't change that contract later, your code is always compatible and easier to maintain. This is called writing a Schema, and it's a fundamental part of languages such as C# and XML, which are known for their great architectures.


5. Encapsulate all of your objects and consider indirect ways of accessing an object's fields/vars.

In other words, your objects should mainly only work within themselves, and only work outside of the object when fully necessary. This creates modularity within your larger modules. This is one of the reasons general programming languages use access modifiers, such as private and public.


6. Keep your fellow programmers informed on the way the code should work using access modifiers.

Access modifiers in general programming languages also tell other programmers (or yourself after a hiatus) how your code should be organized so they don't break it. For example, an abstract object is an object that can be inherited but does not contain a direct way of accessing implimentation or it does not contain an implementation. This forces programmers to inherit it instead of using it directly. Another example is making a field/var private so another programmer won't accidentally intertwine your code, making it less extensible.


7. Give small sets of fields/vars and methods/procs their own objects.

General programming languages call this a struct or structure, which have some performance perks since they are placed on the stack and not the heap. BYOND would probably take up more processing this way, but depending on the context, the organization benifits will be worth it. One great perk of doing this is the ability to pass many variables using only one parameter, and to be able to add more vars as a parameter later on without changing all the methods that use those vars. Examples of structs: A Size object with a Width var, Height var, and a Parameter() proc. A Vertex object with an X var, Y var, Z var, and a Translate() proc. As a lower-level example, a String object containing a list of Chars, a Length var, and an IndexOf() proc.


8. Program like you're trying to defeat Internet Global Warming.

This is called Green Programming; well, at least it should be. Some wankers have coined the term for hippie TV programming and open-sourced development, but I think it is a much better fit for designing your codes to use as little resources as possible. Don't keep objects in memory when they don't need to be, don't let processor-heavy algorithms run when they don't need to, and use the best methods of performing a gratuitous task (like hard deletion vs. soft deletion). Lummox JR has a great artical on this for use in BYOND, found here. I also mention this many times in my BYONDscape tutorials.


9. Program using standards.

Programming standards are a set of rules to keep your code designed strictly. They are a way of keeping everybody's codes happy amongst themselves and amongst other codes. You will see this as fundimental in web languages, but it is also important in any programming language. Sure, you could design a code in multiple ways in many languages, and it's nice to have a choice, but once your code interects with others' codes, you will wish you used only standards instead. This is the biggest reason the World Wide Web Consortium (W3C) exists.


10. Balance performance and organization.

When performance is a big issue, consider not using some of these organizational designs, but only when absolutely necessary; i.e. when it would create too much network traffic, or would use much more processing in an algorithm that already uses most of your processing. Knowing when to use these methods and when not to can be important in designing your code well. Overall, your code should mostly contain good architecture except in some small areas where performance is a major issue.



Now, great code architecture takes some time to plan out well and takes more time to write your code, but the benifits are well worth it in the end. Maybe you will spend less time coding by designing poorly in the beginning, but remember: 50% of your time or more will go towards debugging.

Good code architecture will cut down that time debugging enormously, so designing your code well will most likely save you a lot of time in the end, will save you lots of time if you want to extend your project, and will even save you a lot of time in future projects through modularity.