Code Style

Home » Project Styles » Code Style

We're not very picky here when it comes to how you write your code - all contributions are welcome! That said, with any project (especially public/open-sourced ones), it's good to establish some rules so that things don't get out of hand.

That's why I decided to write this page describing how I'd prefer all code committed to this repository be formatted, and how I personally have been writing all of my code.

It's important to note that, again, code committed to this repository doesn't have to be formatted exactly as the rules here detail, although reading and attempting to follow these rules in all code committed here would be very much appreciated, and don't be surprised if I make an edit to some code that was committed to have it better follow these guidelines.

With that said and without further ado, here's my personal coding style I'm using for HedgeLib.

Overview

• Code Outline
• Most Important Conventions to Follow
• Code "Blocks"
• Naming Conventions
• Access Modifiers
• Variable/Constant Declaration
  • When to use "var"
• Comments
  • Documentation Comments
  • TODO Comments
  • "Commenting-Out" Code

Code Outline

Here's an example of what a HedgeLib class looks like:

using System;

namespace HedgeLib
{
    public class MyAwesomeClass
    {
        // Variables/Constants
        public Vector3 Position = new Vector3(1, 2, 3);
        public int AwesomeInt = 7;

        public const string Extension = ".awesome";
        private string whatever = "idc man this is an example";

        // Methods
        public static int AddSomeStuff(int a, int b)
        {
            return a + b;
        }

        private void ImportantPrivateMethod()
        {
            Console.WriteLine("Man this does so much.");
        }

        // GUI Events
        private void ImportantButton_Click()
        {
            // TODO: Put something cool here idek.
        }

        // Other
        private class SubClassThingy
        {
            // Variables/Constants
            public uint ImportantUInt = 9;
        }
    }
}

The following sections come in order of importance and elaborate more on the individual styles used by the above example and through-out HedgeLib.

Most Important Conventions to Follow

This is the stuff I really care about, so I figure I should get it out of the way right off the bat. Note that the above example does not contain the following:

• Code that goes over 100 characters per-line.
• Unnecessary "Usings."

There was a time where I REALLY did not care about those things, to the point where if someone told me something like "hey man, I like your code but you really should be putting newlines here and there so that your code doesn't go over 100 characters per-line" I would've thought they were crazy.

But I've come a long way since those days (read this atrocity if you want an idea of just how AWFUL my code used to be) and let's just say I now understand why so many programmers have "pet peeves" over things like that.

PLEASE make sure any code committed to HedgeLib follows the above rules! These are the only ones I'm really picky about. Thanks!

Code "Blocks"

Basically, as you may have noticed from the example above, I like to write classes by separating different types of code into different "blocks."

Each block has a simple one-line comment at it's beginning which simply states the type of code it contains (E.G. "Methods"), provided solely to make the code easier to read and make each block more easily-distinguishable.

They also always come into the following order (excluding blocks not present, of course):

• Variables/Constants
• Constructors
• Methods
• GUI Events
• Other

I'm rather picky about this one as well, haha, but if you find it difficult to follow this convention for whatever reason, don't worry too much about it - it's not too hard for someone else to tidy it up just by re-arranging code and plopping down some comments.

Naming Conventions

Ah yes, the famous "CamelCase" vs. "camelCase" argument that's plagued programming message boards for years.

Let's just get right to it:

• For methods/classes/structures/namespaces, ALWAYS use "CamelCase" (even to the extent of disregarding the other rules in this list).
• For publicly-accessible data, use "CamelCase."
• For private/local data, use "camelCase".

Access Modifiers

This one's fairly simple. Basically all data (variables/constants, methods, classes, etc.) that uses access modifiers must be declared/defined in the order of their accessibility, from greatest to least.

For example:

public static bool IsStaticBool = true;
public int AnInteger = 7;
private string aString = "whatever";
private int anotherInteger = 5;

Note how the data goes from greatest to least in terms of accessibility (E.G. public static, public, then private).

Variable/Constant Declaration

I know this is probably a really weird preference of mine but uh... basically for whatever reason I've decided it's best to declare my variables in order of which type takes up the most space in memory to which type takes up the least space in memory.

For example:

public Vector3 Position = new Vector3(1, 2, 3);
public string Text = "text";
public float Money = 99.5f;
public int CatLives = 9;

Note how the data goes from greatest to least in terms of how many bytes each type typically takes up in memory.

I'm really not picky when it comes to this one, since even I realize it's an odd preference of mine. If unsure which type takes up more space in memory, just organize it in the way that looks best to you. :P

When to use "var"

Honestly this one doesn't really matter much to me either, although I've generally decided it's best to use var as detailed.

Use var if the type of data is not a primitive system type (byte, int, uint, float, string, etc.). Arrays, lists, etc. of said types don't fall under this category - use var for those!

For example:

uint data = reader.ReadUInt32();
var vect = new Vector3(1, 2, 3);
var offsets = new List<uint>();

foreach (uint offset in offsets)
{
    // TODO: Put some cool code here.
}

In other cases, try to avoid the use of "var" as it may cause confusion, etc.

Comments

Comments have a wide-variety of uses, each of which I have my own opinions on.

Documentation Comments

Personally, I believe good code speaks for itself. By that what I mean is, quite simply, if you wrote your code well, there's no need to write a comment explaining what it does - it's purpose is instead apparent simply by glancing at it.

I used to be all for documentation comments - but over time you find they just add a ton of unnecessary stress (and code lines), particularly when you want to re-factor something and end up having to re-write all the documentation for a class.

Because of this, I try to avoid comments detailing how my code functions whenever possible. Instead of primarily using comments to describe how something works, I instead primarily use comments to describe why something is done in a certain way.

That said, there are definitely cases where something complex is being done and the code's function simply cannot be made more apparent without some text explaining what the heck it's doing. So, in these cases, using a comment to describe how something works is fine.

TODO Comments

A "TODO Comment" is basically a comment like this:

public void SomeMethod()
{
    // TODO: Finish this method.
}

If you want to remind yourself of something you still have to work on, or just make it apparent that what you're working on isn't yet complete for when others look at your code, these can be incredibly useful - it's to the point where Visual Studio actually features a "Task List" option that actually lists all TODO comments it finds in your code!

Feel free to slap these guys anywhere, I personally use them all the time. If the thing that has yet to be done is plainly-obvious, you don't even need to bother adding a description to your TODO comment, just write "// TODO" in the spot that has work left to be done.

"Commenting-Out" Code

This is a common practice among-st programmers. Basically if you have some code you decide you don't want anymore, but might need again in the future, we just slap two slashes at the front of the line and make it a comment! It's such a common practice that Visual Studio even has a keyboard shortcut to make this easier (ctrl + k followed by ctrl + c)!

Personally, while I can't say that it's good practice, and it can definitely make a lovely looking code file an absolute mess if done excessively, I'd be lying if I said I didn't do this all the time, haha.

So the basic rule of thumb I use when it comes to commenting-out code is this:

• Only comment-out code if you're almost positive you'll need it again sometime in the future! If you don't think you'll need it again, just delete it instead.
• Whenever you see commented-out code, make it a priority of yours to either un-comment the code and use it again, or delete it. Try not to leave blobs of commented-out code hanging around for a while!