Your personal coding conventions?

So I've come up with a couple of simple coding conventions that I like to use that my friend seems to like and I thought I'd share them, and I'm interested in hearing other peoples' as well.

I tend to use a lower-case first letter for public variables (or getters/setters), like myVariable. I'll also use an underscore for private and protected variables; _myVariable;

When trying to keep my temporary variables named in a way that make sense, I'd often run into redundancies with my public variable names, so I started using a lower-case 'o' to demonstrate temporary variables; oVariable. I chose that because it's kind of like the Japanese "respectful" prefix; I am respectfully using this temporary data. It also lets my variables be more compact, and kinda looks like the variable is on a little keychain or something. oHeight, oHit, oRange.

The small, readable variable names also let me more easily script in blocky chunks rather than tons of separated lines. This is so that each "idea" that I try to do in a function can take up just a single line, like a sentence rather than separate words.

What are some unique things you've come up with for your own personal use?

 

Public, private, protected, function names = myVariable. I just tend to keep the first word lower case and the rest uppercase. Also, to determine which one is private, I just look at the variable declaration. I really don't have any writing conventions. Maybe one..... I like to keep each variable private as much as I can. Some things (like speed variables for example) have to be public. Other than that, I wrote my own pathfinding algorithm using only private variables. This system had to determine which node was next in the path. That way, I saved time setting up node neighbors and I saved a lot of processing power by not adding a script to each pathfinding node.
That's just me.... cause I like to code and I like to have everything done for me through code haha

 

I'm curious how many people here do same-line braces or next-line braces. I can't stand same-line braces. Putting your braces on the next line is so much more neat.

 

Next line braces for me, and variable names with the first word initial letter lower case, and subsequent words with upper case initial letter. Super important variable names start with an underscore.

 

I do same-line because I like my code to be in neat chunks that are I can glance at in their position near other chunks and understand the flow of the whole script.

Next-line braces make the function as a whole look kinda disjointed to me.

 

Next line braces for the win!

 

Standard coding standards (not mine - err well, they are but they're just general accepted standard)

PublicVariable
FunctionName
privateVariable
parameterVariable

use what-ever-the-f***-you-like-tbh, but above is pretty standard.

I prefer no braces if I can get away with it, but generally all braces should be on a new line. Ive heard JS (not UnityScript) can have some weird behaviour if your braces are in the wrong place, but never confirmed that... I think thats where the brace on EOL has come from.

 

^^ This and _memberVariable;

I hate it when people put braces on the same line, braces should always be on their own line, it makes the code a lot more readable.

And to make variables that are private to the class, but to them make visible in the inspector

[SerializeField] GameObject _myGameObject;

Please stop making variables public just so they are visible in the editor!

 

void Thing()
{
}

4EVA

 

When in Rome...

...do as the Romans do.

My conventions for this kind of stylistic thing change depending on the project I'm working on at the time. I don't really have preferences any more 'cause I literally don't care, and rarely make the decision for myself any more because there's almost always a convention already in place with whatever you're doing.

 

I spend most of my time in C++ rather than C# but follow mostly generalized rules based on the various standards out there so e.g. for me variables and naming tends to be like this :

Code (csharp):

1. g_globaVariable
2. _classVariable
3. localVariable
4. ClassName
5. ClassMember()
6. ENUMERATION_OR_MACRO

I also go verbose on naming to make it clear and humanly readable rather than using acronyms or concatenations, this would however be a total pain in the ass if it weren't for auto complete and tools like Visual Assist and Resharper, but I find it pays off to name with clarity of purpose, so rather than _oc I'll explicitly spell it out because _oc could be _objectColor or _overCharge or any number of other things, and while that example is specious it's quite common in more complex functions to end up with similar acronyms which just obfuscate your code.

Then There are lots of other small guidelines that I use:

Code (csharp):

1. #ifndef __FILENAME_H_
2. #define __FILENAME_H_
3.  
4. ...
5.  
6. #endif

Rather than

Code (csharp):

1. #pragma once

And I like to lay out if's like this :

Code (csharp):

1. if
2.   then
3. else
4.   this

Or (what I tend to prefer because it can be too easy to accidentally nest an if statement that's open line and then of course the compiler has no way of knowing which statement the else belongs to).

Code (csharp):

1. if
2. {
3.   then
4. }
5. else
6. {
7.   this
8. }

But I don't like to mix open single line and braced like this.

Code (csharp):

1. if
2.   then
3. else
4. {
5.   this
6. }

However it's OK in a switch as the whole block is braced so there's little chance of accidentally integrating or refactoring a break or poor branch in there when not paying attention.

Code (csharp):

1. switch(x)
2. {
3.   case a:
4.   //PASSTHROUGH
5.   case b:
6.   {
7.     ...
8.     break;
9.   }
10.   case c:
11.     ...
12.     break;
13.   default:
14.     break;
15. }

I prefer to have a vertical code layout to a horizontal one where possible so e.g. I avoid

Code (csharp):

1. a = 0, b = 0, c = 0;

and even

Code (csharp):

1. a = b = c = 0;

and instead prefer to do

Code (csharp):

1. a = 0;
2. b = 0;
3. c = 0;

And even though there are core advantages to

Code (csharp):

1. Constructor():_internalValue1(0),_internalValue2(0)... {}

I generaly find it's much easier to maintain code that uses

Code (csharp):

1. Constructor()
2. {
3.   _internalValue1 = 0;
4.   _internalValue2 = 0;
5. ...
6. }

Simply due to maintenance, debugging and readability where sometimes you have to balance verbosity against concision for the purposes of clarity.

With whitespace I like to use it quite a bit, but keep it to a single character, so just one new line inbetween elements rather than two empty lines, and a single spaces between elements of formula or assignments eg..g

Code (csharp):

1. a = (b * c + d) * 23.0f;

rather than

Code (csharp):

1. a=(b*c+d)*23.0f;

And spacing similar to written English when dealing with punctuation (commas, semicolons).

Code (csharp):

1. for (i = 0; i < 10; i++)

rather than

Code (csharp):

1. for(i=0;i<10;i++)

Code (csharp):

1. for (i = 0;i < 10;i++)

or

Code (csharp):

1. for (i = 0 ; i < 10 ; i++)

Same deal in function arguments

Code (csharp):

1. void MyFunction(int a, int b, int c)

And when it comes to variable declarations I prefer to keep them separate rather than bundled so

Code (csharp):

1. int a = 0;
2. int b = 0;
3. int c = 0;

Rather than

Code (csharp):

1. int a = 0, b = 0, c = 0;

or

Code (csharp):

1. int a = 0,
2.     b = 0,
3.     c = 0;

And going back to for loops I much prefer to avoid declaration within the arguments so

Code (csharp):

1. int i = 0;
2. ...
3. for (i = 0; i < 10; i++)
4. {
5.   ...
6. }

rather than

Code (csharp):

1. for (int i = 0; i < 10; i++)
2. {
3.   ...
4. }

Then there's things like defensive programming practice and so on.

At simplest is stuff like knowing to zero out atomics and use constructors to do so for member variables, placing your variable declarations at the start of your functions and so on.

So do

Code (csharp):

1. void MyFunction()
2. {
3.   int i = 0;
4.   int o = 0;
5.   int u = 0;
6.   ...
7.   use i for something
8. }

rather than

Code (csharp):

1. void MyFunction()
2. {
3.   ...
4.   int o;
5.   user o for something
6.   ...
7.   int i;
8.   use i for something
9.   ...
10. }

This is really just the coding style for my own personal projects currently though, when you work on a larger project you just don't have the luxury because the most important thing is just that everyone has the same coding style, and given most styles are minor variations of the standards then there's no excuse not to.

Provided you spend a little time setting up your environment, the various tools you use such as visual assist, resharper, atomineer or ghostdoc and of course the IDE's own settings then you really shouldn't need to think too much about this stuff anyway as they'll automatically format most of this stuff as you go.

 

Guilty

 

http://www.imdb.com/title/tt0050083/

I have reasonable doubt that same-line braces are any good. I'm not saying they're bad, I'm just saying I have a reasonable doubt that same-line braces are good.

 

I am saying they're bad.

 

Likewise. Although I did look up what attribute actually makes a variable visible... which I have since forgotten.

Chalk me into the same line camp. Things just look tighter and less disjointed. Next line hardly looks like it operates under an if statement, like it's just random code not related to the if statement.

 

I was in the "next line" camp, but all of the other coders I work with didn't like it. Now I'm completely cool with either, though I still do appreciate the neatness of having the { and } pairs lined up vertically.

 

I personally think it's a shortcoming of the available learning materials that this isn't taught as the first and foremost way to get something in the Inspector. Telling people "make stuff show up in the Editor by putting [SerializeField]" before it is literally no harder than telling people to put "public" before it, but has the advantage of not getting them into terrible habits when it comes to scope management.

Plus, there's the benefit of getting them one step closer to understanding the difference between the code interface of a class and the Inspector interface. When I was first using Unity I was constantly compromising one of those for the benefit of the other, but there's simply no reason to do that. You can make explicit choices about what to include in each. And usually you'll include the same in each, but not always, and sometimes you'll want to / have to present it differently.

 

you should watch that film

 

Mine are a bit odd then:

public int name;
protected int _name;
private int __name;

void Name{
}

Yes the last one is because of javascript. In js for example:
function A(){
return
{ }
}

is the same as

function A(){
return;
{ }
}

 

Because I'm weird, I use next line indented braces like:

Code (csharp):

1. void Thingy()
2.     {
3.  
4.     if (blah == blah)
5.         {
6.         ...
7.         }
8.     }
9.  

 

Code (csharp):

1.  
2. public class Foo: MonoBehaviour
3. {
4.   private int _someInt;
5.   public int someInt;
6.   public int SomeInt { get; set; }
7.  
8.   public void Bar(int someOtherInt)
9.   {
10.   }
11. }
12.  

 

[HideInInspector] saves the day!

 

I do whatever the hell it takes to get the game running well.

 

I'm a fan of the same-line braces. Next-line braces feel like a waste of vertical space to me. It's also odd to me that the beginning of the block is marked by two lines. I also think it's still very easy to tell where blocks stop and start as long as your indent levels are decent (4 spaces). It's just as easy for the eye to follow from a close brace up to an opening statement at the same indent level.

I also think next-line braces get difficult to read once you have a few nested ifs and elses:

Code (CSharp):

1. if ( someBool )
2. {
3.    if ( someBool2 )
4.    {
5.       if ( someBool3 )
6.       {
7.          doStuff( );
8.       }
9.    }
10.    else
11.    {
12.       if ( someBool4 )
13.       {
14.          dontDoStuff( );
15.       }
16.    }
17. }

I'm also a fan of always enclosing blocks of code in braces even if it's a single line. So, even though this is legal (and promoted by some people):

Code (CSharp):

1. if ( someBool )
2.     doThing( );

I prefer this:

Code (CSharp):

1. if ( someBool ) {
2.     doThing( );
3. }

I like how that makes things explicit and can save you some headache in the future if you decide you need another line of code in that if statement.

But that's another reason I like same-line braces. Since I use braces even for single line blocks, same-line braces let me only bloat the code out by one line instead of two.

 

Ah, that's nice to know!

Also, I like those standards also for formatting but would define them as such:

PropertyMemberVariable
privateMemberVariable
FunctionName
parameterVariable

Just to add that in C# you use 'this.' on your member variables to distinguish them from parameters with the same name. Typically you should make your public member variables properties, but unfortunately Unity doesn't show those in the inspector; which also makes using interfaces a pain in Unity.

I'd also agree that braces on the same line is bad. I'm kind of a code formatting Nazi at work. I find ready poorly formatted code takes me twice as long to grok than when it follows a convention.

 

Wow! Most of you would hate trying to work with my code bases.

"His programs are more machine like now, twisted and evil." quote -> OB1-Assembly

I do follow the standards, but make strong use of operators where appropriate, loops where it is needed; I use ternary instead of If...Else blocks when I need to only know if it is Zig or Zag, variables are 80% within classes with accessors
(some with strong/complex logic in the set or get on top of that) and I make good use of abstract classes and interfaces in the base design of all complex functionality. Some of my 13 years experience has caused me to implement some optimizations from the start without realizing it.

It is not uncommon for someone else trying to trace through my code like bread crumbs on base class method calls, with the RIGHT-CLICK and Go To Definition only to end at an interface class and not the proper class where the method is implemented, or my favorite, seeing so many overloaded or virtual methods from abstract classes just make a junior programmer's head explode!

BUWAHAHAHAHA!


At least I comment the snot out of my code, so even if you cannot understand the architecture of the program, you will know what each and every method does and what variables are used and how they are used by the program.

This includes not just game programming but all forms of code I write (web applications, desktop applications, windows services, etc.).

 

Oh, also for identifiers...

consts like this: HERE_IS_A_LONG_NAME

instances, fields, properties like this: hereIsALongName

classes, methods like this: HereIsALongName

I think it's important to know at a glance whether thisThing.DoStuff( ) is calling a static method of the thisThing class or an instance method on the thisThing instance.

This also matches the conventions used by Unity's own scripting API.

 

My head just exploded. That is a confusing format, no offense.

 

We use that one at my work (though it is a different language)

Code (csharp):

1. procedure DoSomething;
2.   begin
3.   if Something <> '' then
4.     begin
5.     //....
6.     end;
7.   end;

 

Oh Gawd I can't stand next-line braces. I put all my opening braces on the same line... as casimps1 said it just saves so much more space. Of course I have an indent within any braced function/loop/conditional etc... that's all the formatting I need and it makes perfect visual sense.

 

My reaction when I see a same-line brace:

[Insert swear word here] [Insert swear word here] [Insert swear word here] this [Insert swear word here].

PS I have a bad OCD. .-.

 

Programming Conventions are overrated.

At least IMO they are. I'm not you, so I don't know what life is like for you. Even when coding complex things, I have no use for them. The names I give variables are whatever makes sense, even if it's a long definition. Most conventions are unnecessary. Why use a convention to mask the code, when you can simply type out whatever the hell you want in the first place.

Granted, I don't work with teams (and if I do, my commenting explains everything to the last unnecessary detail).

What isn't overrated is commenting everything. Literally everything. Even the stuff you'd think is common sense.

Code (csharp):

1.  
2. //This is a comment about how conventions are stupid, but commenting things is awesome.
3. PostStatement("It doesn't matter how you code or if you use underscores _ or capital/lower casing. That is just a fool's errand for people who don't comment everything.");
4.  

In the end, as long as you understand your own code, or the people who need to work with it understand your code, then it doesn't matter. Still, you should comment everything anyway. Even things as silly as "//This is a variable for hit points. int HitPoints;"

I could care less, as long as it's commented in a way to understand it simply by reading plain english explanations.

 

Not when you're working with a lot of code, or code that others will be reading/using.

 

You obviously didn't even read my post, and just stopped after that first line.
If you want other people to read your code, don't use some idiotic personal convention they have to learn. Just comment your code thoroughly in plain english.

Also, conventions vary from place to place, from boss to boss.

A common complaint among programmers who are employed by others is that every new boss wants things a completely different way. At every job, you have to learn new conventions or have bosses who ask for idiotic requests.

One example in particular, I remember someone talking about how their boss demanded they use less static variables, yet the community responding to the question collectively agreed that they were using them appropriately and the boss was an idiot who apparently "feared static variables".

You could debate that isn't a convention, but it falls under the same blanket complaint and is just one example of many common complaints professionals have when going from job to job.

Conventions are not standard. Even standard conventions are debated among professionals. Everyone seems to want things done their way, instead of in a way that others can actually understand. I see no reason that conventions like myVariable vs MyVariable vs My_Variable, matter when you could merely take a few seconds to comment in a clear and concise manner. Not to mention you have to be an idiot to not know what the variable does that you're working with, unless the programmer named multiple variables something like myVariable1 myVariable2 myVariable3. But you don't need a convention to name your variables appropriately, in a way that makes sense.


Hell, I'm surprised no IDE has used color coding to help programmers more easily see nested loops. That is something that should be standard. If you are aware of any such thing, please tell me about it.

Companies and individual programmers shouldn't dictate what is standard. They'll never agree. It would make much more sense if the convention standards were created by the major IDE developers or someone like Apple. One standard to rule them all, otherwise in the darkness **** them.

Hmm, that makes me think of some "Convention War" where the tech industry goes all south-park medieval-war (where people actually die) so that only the winning convention is declared standard.

 

Your style is similar to mine, I tend to take spacing a bit further too and also like to align the ( )'s with my statements because often the content inside is the focus not the parenthesis. I'll also prefer shallow logic flow and will use short circuit logic in place of nesting if conditions.

For example:

Code (CSharp):

1.  
2. if( !someBool )
3. {
4.     return;
5. }
6.  
7. if( someBool2 && someBool3 )
8. {
9.    doStuff( );
10. }
11. else
12. if( !someBool2 && someBool4 )
13. {
14.    dontDoStuff( );
15. }
16.  

 

As long as indents are proper, I prefer sameline braces. Its extremely easy to match closing braces with whatever matches the indent amount above it. And it certainly eliminates some vertical bloat to your code. But to each their own I suppose.

 

Same line braces. I see them like punctuation such as quotes or periods. I often reformat next line braces to same line braces so I can read through the code quicker and as well I am not a big fan of a separate doc for each class but keep all related functions and vars on the same doc. This can lead to long scripts for complex subsystems and next line braces make the scripts that much longer.

 

Actually I did read the whole post. I'm just disagreeing with it. (Except for the part about comments. Comments are important.)

 

I do this when developing and tweaking vars to get the behavior I am looking for. Watching the numbers or stings or game object change whilst running the game or app assists in the tweaking decision. Then at the end I make all vars private except those needing exposing to other devs or the user.

 

To save time writing braces, keep opening and closing braces in order I start with a quick code stab which is built into my muscle memory

Code (JavaScript):

1. if () {
2.  
3. }

then I go back and fill it in like..

Code (JavaScript):

1. if (devilID == 666) {
2.      Instantiate(crucifix, devil.position, devil.rotation);
3. }

Also.. this is not same line bracing all the way.just the first line.. The last brace is next line.

 

So you're basically agreeing with the most important aspect I talked about (commenting). Got it.

Hard to disagree with that. Commenting dominates everything. Especially conventions.


I don't really understand why some conventions are even in place. You can simply right click a variable to see when it is declared. It's pretty much common sense to understand if what is being used is a string or integer. You pretty much need to understand it all anyway if you're working with it and don't know yourself (someone else's code, or you forgot). Do people really need to be reminded if the integer they created is an int or a float? Silly things.


No one has yet proved the usefulness of most conventions. Even in practical application they aren't proven very useful, seeing as how no one seems to agree on them. If they were useful, they'd naturally become standard instead of people trying to force their standards on employees or demand sticking to 'standard' (opinionated) conventions on sites like stackexchange.

 

Does it break the game? Is there an extreme downside to doing so?

I say this to everyone, as long as it's performance efficient and works do whatever makes you happy. Just please be courteous and leave some comments as to what the poop is going on.

 

The whole idea of not making every variable public is just to keep it from being too complex, such as when a public variable is changed and it takes longer to find where it is inappropriately changed at, because it wasn't private.

I honestly don't see this happening very often, and I honestly do not understand any cases (in video game development) where the problem would be harder to track down because of public vs private declaration.


In the end, it sounds like some people doing very specific (complex) work, do some really stupid things, and because of it cause themselves a few extra minutes to hours finding the problem. Then these dumb people go overboard screaming at their students
"OMG OMG OMG YOU HAVE TO MAKE SURE EVERYTHING IS ALWAYS PRIVATE BC IM STUPID OMG OMG OMG ITS SO IMPORTANT OMG"


It honestly makes little sense to me, because if the public variable is altered...it is altered just like it would be altered if using a Get/Set method. In the end, you're still altering the same way (Set vs no Set) and the problem will be the same area. You can also find the problem by simply Ctrl-F and looking at all instances where the variable is altered. Maybe I'm "special" and can wrap my head around complex things, or game dev isn't complex like some coding is (more likely), but I don't see myself scratching my head wondering why my player's health goes to -40 anytime they drink a healing potion.


Games are complex, but Unity simplifies a lot of this stuff for us. In the end, it is irrelevant if the variable is public or private. If the game works, it works. If the game has a bug, it has a bug. More than likely declaring your variables public/private won't really effect that.

Unless I'm somehow missing some common mistake most people make, that I am lucky enough to not make.


Hiding variables in the editor though, is important when working with teams. People advise to hide variables you don't want other people messing with, because apparently some team members in game dev will break your code by tweaking variables which they don't know anything about. Weird I know, but apparently it's a thing?

"A variable I don't understand? I should adjust it for no reason! Weeeeeeeeeee!!! WTF IT BROKE MAN HELP ME PROGRAMMER TEAMMATE!"



edit: Some will argue that later when you go back to a project, it is extremely complex (true) and you dont remember anything (true). So you might alter your own variable without realizing how that variable is linked with other variables (changing variable N, messes up variable Z) However, commenting everything in detail will make it much easier for you to both remember and understand your old code or the code of others. Commenting is the solution, not convention.

 

I love you.

This post and your last.

You actually seem intelligent. You actually seem like you program things successfully. You actually seem to have the (uncommon) strength to say to people "Why? WTF are you talking about? That doesn't make sense."

Then you back up exactly what I said. So we are basically identical in belief. Screw convention. Just get the game done, and done right. Commenting > Convention.

Hi-5 bro.

 

Since I primarily work on developing assets and tools that integrate with Unity, my coding conventions tend to mirror Unity's style (using SerializeField for private inspector fields and exposing them through properties, similar capitalization rules and naming styles, etc). Definitely newline brackets as well.

I think what's more important than a coding convention is just to stick with something consistent - it helps a lot to go and define all of this stuff in MonoDevelop/Visual Studio/vim or whatever, so that auto-formatting tools help keep the consistency of everything without having to spend time thinking about it.

 

Don't get me wrong, it's alway nice to keep things nice and easy to read. Like using paragraphs instead of blocks of words, but I never get this whole OMG it HAS TO BE DONE THIS WAY!.. Let's say you have a public variable and it relies on positive values and some muppet screws it from a far and can't fix it, you have far bigger issues on your hands than code convention (like an engineer you need to fire). You can use getters and setters, you can make them private there's a million ways you can skin this cat.

It matters even less when you're one person doing the coding. The beauty of coding is that you can do it whatever way you want, if it works you're fine and if you can come back to it in a couple of weeks and still know what's going on you're on a winner. If it causes a bug you change it, if you're telling people how to do code convention then you should know what would cause the issue in the first place.

We talk about scalability, but in large teams we do code reviews. We map out in visio's and supply to all our team members for quick reference.. What we don't do is procrastinate on slightly out of place brackets.

 

HERESY!!!!!


AHHHHHHHHHHHHHHH!!!!!!!!!

OMG IT HAS TO BE DONE THIS WAY!!!!!!!!!!!!!!!



UNACCEPTABLE!!!!!!!!!

 

This is what I was talking about.

I don't even understand how "that is a thing" to worry about. I understand people can be incompetent at their jobs or fake it (and when they cant fake it, reveal their stupidity) but seriously... the issue isn't with your lack of convention if you have an engineer doing stupid things like that. I find it so crazy that people like that even exist, and even crazier that so many people overcompensate in all fields because of those types of people. (Every field makes people go crazy like that, screaming about extreme (exaggerated) solutions to rare or simple problems).

Everyone prefers basic common sense conventions, like readable code. I figure that is implied though, regardless if you follow a convention or not. Just like proper grammar is implied.


otherwise...itslaljustahumbledmessandpeoplecantreaditbecausetheresnoparagraphinitandallthatstuffyouknow?liketotallyman.typingawalloftextwithoutspacingorwithoutusingparagraphsisjustimpliedcommonsensestuffsoiassumeyoudonthavetoremindpeopleyoualwaysliketokeepthingslookinggoodbecausewhatkindofprogrammerkeepsitmessy?thekindthatneedstobefired.thatswho.lololololol

 

Conventions and public vs. private variables are important when you are working in a team environment, especially when your team will include junior developers. They help promote readability and maintainability.

We had one contractor get annoyed and tell us that he wouldn't work in a shop that forced two space indents (and save as space) like we did. This was quite awhile ago and we had that standard due to some older editor programs we used that couldn't auto format, so if you had a mix of spaces and tab characters it looked horrible. Suffice to say we added an interview question after that pertaining to how they deal with following rules/guides/conventions/etc. that they didn't agree with.

FYI, if you use visual studio you can use ctrl-k ctrl-d to auto format your code based on the rules setup in options. Be forewarned the default for braces is for them to be on their own line, so if you like JavaScript style you will need to change the rule. This is for C#.

 

I don't agree, that might be because we have a team of experience and don't have to worry about the new kid on the block whose a self appointed god of coding (or just were old I'm not sure yet) . It's rare that I've ever had to deal with Junior coders even in the AAA workspace my duties were specialised. So maybe formating practice for juniors could be a good idea? Then again it begs the question why would a person hire someone who can't do basic formatting?

Sure we didn't go out of our way to make dirty unpresentable code, but neither was it ever a key consideration in any format. All you're going to do is piss experienced people off who are used to spacing it out their own way, adding restrictions that serve no real purpose and for all people know the engineer / dev of higher caliber may of been doing it the right way all along. I've been at it 15 years, our senior dev has been doing it 20 and no matter the formatting we can read each others code without any difficulty. So can anyone else on this team and previous teams..

I've yet to run into a problem that hasn't been caused by a person with inexperience at the throttle which is usually a case of sitting down with them and mentoring, finding out where they went wrong and on the whole helping them understand coding concepts as a whole.

Wrapping your head around a problem is usually the main concern, not how pretty you can make your code. Don't get me wrong, if you need or like pretty code then me or anyone else can't say it's wrong. As said do whatever works..

I wish I had time to care about all this stuff, when Enlighten makes it debut and I don't have to wait for beast to do whatever the hell it likes then I'll be even busier with my crappy looking very functional and efficient code.