Unity Week #8: Some Thoughts on Variable Names

By Shamus Posted Thursday May 24, 2018

Filed under: Programming 86 comments

Like I said over the weekend, my series on Grand Theft Auto 5 has been delayed. But I can’t bear to leave the Thursday spot blank, so here are some meandering, dashed-off thoughts on the problem of variable naming in C#. To be clear, the problems are mostly with me and not C#. Specifically, switching languages is forcing me to shift my coding standards a little.

For years I worked for a company with a mature (meaning large and resistant to sweeping changes) codebase. In 1993 or so it began as a pure vanilla C project, but sometime around the turn of the century we began migrating to C++ while disrupting the existing code and coding style as little as possible. C and C++ are different languages and the practitioners of each language often have very different ideas about how code should be formatted. Since our codebase was a hybrid, our formatting standards were a slightly strange and anachronistic blend of old and new. Since I used these standards for years, they eventually became part of my personal style. I wasn’t even really a fan of the standards, but after you look at one particular style of formatting for a decade or so, everything else starts to look a little strange.

Let’s look at an example. Earlier in the week I created a SpaceMarine class. Here is how that class might look in C++:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class SpaceMarine: public Meathead
{
  char* m_name;
  char* m_profane_nickname;
  const bool m_is_dude = true;
  float m_beard_stubble;
  double m_burlyness;
  int m_bullets;
  int m_genades;
  int m_hitpoints;
  int m_armor;
  long m_aliens_killed_with_firearms;
  long m_aliens_killed_with_melee_weapons;
  long m_aliens_killed_with_bare_hands;
  long m_aliens_killed_with_shouting;
  int m_dead_wives;
  bool m_cigar;
};

Each variable starts with m_. This is so you can quickly tell member variable (stuff that belongs to the marine) from other variables. For example, say you’re scrolling through a great big block of code, looking for something. You come to this section:

1
2
3
if (damage_reduction > 0)
  hitpoints = hitpoints / damage_reduction; 
total_damage += hitpoints;

Here we’ve got three variables bouncing around: damage_reduction, hitpoints, and total_damage. At a glance we can see none of these start with m_, which means none of them belong to the space marine, which means this section of code is not making any changes to the state of our poor meathead. I think the variable “hitpoints” should probably be renamed to make it clear what is being calculated here (incoming damage would be my guess) but hopefully you get the idea. We can use variable names to give the coder more information about the code they’re reading.

Note that these standards are all self-imposed! There’s no external force obliging you to adhere to these. If you wanted, you could make the variable names more verbose:

1
2
3
4
5
6
class SpaceMarine: public Meathead
{
  int m_belongs_to_space_marine_no_touchy_hitpoints;
  int m_belongs_to_space_marine_no_touchy_bullets;
  int m_belongs_to_space_marine_no_touchy_armor;
}

That’s fine. If anyone else goes to work on your code they might start to hate you a bit on account of all the typing and wasted screen space, but this is just as valid as far as the compiler is concerned. Likewise, you can adopt a super terse style:

1
2
3
4
5
6
class SpaceMarine: public Meathead
{
  int hp;
  int bull;
  int armr;
}

This is functionally the same as the previous code, except it’s all abbreviations and there aren’t any style markers to make these variables stand out from variables that exist outside of the space marine.

Who Cares?

So if the compiler doesn’t care, why should the programmer?

A lot of programmers will answer this question by pointing to this post on making wrong code look wrong. We try to design coding standards so that:

1) The standards force you to code in ways that make the code better. (Safer, more secure, more stable, more readable, etc.)
2) Code that does not conform to standards will be really obvious.

The thing is, imposing coding standards will always give you the second thing, even if they don’t give you the first. Once you spend a few days staring at a particular style of code, things written in a different style will stand out. It will feel “wrong”, even if there’s nothing wrong with it. Imagine if you’re reading a book and it suddenly switches from single spacing to double spacing, and from justified to flush-left alignment. This will probably grab the reader’s attention. “What? Why did the style change? Is this passage a quote? An aside? What’s going on here?”

Since you’re probably going to notice coding style no matter what the style is, you might as well come up with a style that has some utility to whatever sort of problem you’re working on.

Like I said, my coding style is a bit odd. I dislike some of it but sort of follow it out of habit because changing styles (particularly after being stuck with one style for half your career) is hard.

Having said that, I’ve always hated the m_ thing. It’s an annoying and awkward prefix. On an English keyboard, both m and underscore are typed with the right hand, but one is at the bottom of the keyboard and the other is at the top, one is typed holding down the shift key and the other isn’t. So once I left my day job I began omitting the m and just start member variables with the underscore:

1
2
3
4
5
6
class SpaceMarine: public Meathead
{
  int _hitpoints;
  int _bullets;
  int _armor;
}

So when I’m scrolling through code later and I see _hitpoints -= damage I’ll know that _hitpoints belongs to the SpaceMarine while damage does not, and that this code is making a change to the state of the space marine.

Shrug. It’s not a big deal. Aside from this discrepancy, I’m still using this odd blend of 90s C and turn-of-the-century C++ style. That’s not bad or anything, but when I made the jump to Unity I figured it was time to change things and adopt something more in line with popular standards.

And then everything went to hell.

The problem was that I was trying to develop a coding style before I understood the language. For example:

In Unity, the editor will generate dialog boxes for you. Let’s say you’ve got this code:

1
2
3
4
5
6
7
8
public int                  AtlasSize = 1024;
public float                PixelDensity = 16;
[Range(0,1)]
public float                NormalDepth;
public Material             AtlasMaterial;
public Material             AtlasFoliage;
//Visible here just for debugging purposes.
public AtlasEntry[]         _library_array;

If you make all your variables public like this, then Unity will generate a dialog box for you:

Note that the labels in the right-side box match the variable names from the previous code.
Note that the labels in the right-side box match the variable names from the previous code.

You can fiddle with those controls to change the values in your variables. You can even do this while the game is running. As someone coming from C++, this is basically sorcery.

The thing is, that dialog is sort of designed around the assumption that you’re going to use CamelCase for your variables. So if you’ve got a variable used to store your favorite pasta, you’d call it “FavoritePasta”. Unity will see the capital letters, realize this is two words, and place a space between them in the dialog for readability. On the other hand if you call it “_favorite_pasta”, then Unity will try to clean it up for the dialog, but it doesn’t quite work. You end up with “Favorite_pasta”.

This offended me on an aesthetic level and made it feel like I was doing it wrong. So I adopted a style of using CamelCase for stuff that was supposed to show up in the dialog and _old_school for everything else. But then I learned (through people here in the comments) how to properly use the set / get features of C#, and that made me change my variable naming a little.

Also, the underscore doesn’t play well with the autocomplete features of Visual Studio. This wasn’t a problem in C++ since my classes weren’t very complex. But now I’m using Unity classes with literally dozens of built-in Unity-specific variables. My SpaceMarineTo be clear, I’m not actually doing anything with space marines. has _hitpoints and _armor, but also a huge list of things that aren’t really relevant to what I’m doing. Starting variables with an underscore screws up the autocomplete and shoves all of my variables to the bottom of the little autocomplete popup.

I've only given this class four or five variables, but it's inherited a few dozen from Unity, and they all show up inm this popup.
I've only given this class four or five variables, but it's inherited a few dozen from Unity, and they all show up inm this popup.

So halfway through this adventure I started using a new style that dropped all underscores:

1
int favoritepasta;

My thinking was:

“Okay, I’ll use CamelCase for stuff that shows up in dialogs, all lowercase for variables that are visible outside the class, and _under_score style for stuff that’s ONLY used internally.”

But all lowercase is hard to read and occasionally ambiguous. I’ll see “marinestop” and I don’t remember if it’s supposed to be “marines top” or “marine stop”, or “marines to p” (whatever p might stand for) and so I’ll have to stop and go read other code before I understand what this variable is and how its usedTurns out it actually stands for “mari nest op”.. So then I start putting underscores back into variables.

It would be one thing if I began the project with this style in mind, but since this mess evolved over time it’s a complete patchwork. I’ll go back to a bit of code from two weeks ago and get confused because my style has changed completely since the last time I looked at it. I keep thinking I need to do a project-wide refactoring to clean things up, but then I think, “Bah. This is just a skunkworks. I’ll throw this code away next week anyhow.”

This is all normal growing pains of course. I’ve been looking at bits of code to see what other people use, but nothing has really jumped out at me as “Oh, this is clearly the best way to do things.” As before, when I finally settle on a style it will probably be based more on habit than merit.

I am curious how people handle it when they have to use multiple coding styles at the same time. If you’re involved with two different companies – or perhaps two different projects at the same company – then how do you deal with it? Do management types still care about coding style? What styles do you hate but are forced to use?

 

Footnotes:

[1] To be clear, I’m not actually doing anything with space marines.

[2] Turns out it actually stands for “mari nest op”.



From The Archives:
 

86 thoughts on “Unity Week #8: Some Thoughts on Variable Names

  1. Paul Spooner says:

    All my coding projects are small enough and spaced far enough apart that I’ve never really developed a coding style. It’s just whatever random nonsense I come up with that seems clear at the time. I suppose this has the disadvantage of not incorporating style markers. Not sure how bad that is in comparison to the advantage of never getting hung up on the style of code written by other people.

  2. Shpelley says:

    Hey Shamus, I’m still learning all this stuff myself (coming from mostly web technologies) but over the past ~6m – 1y I’ve come up with my own coding style that seems to work and doesn’t offend:

    Private Variables use _ prefix
    All Variables use pascalCasing
    Methods use CamelCasing

    Examples:
    private bool _lockedOn = false;
    public int hitPoints = 2;
    public void TestFunction() {}

    The editor picks up pascalCasing just as well as CamelCasing (still capitalizes properly in the UI for instance) and knows to ignore the underscore if you decide to use [SerializeField] to expose a private variable to the editor. I don’t usually bother differentiating between local fields and variables being passed in.

    1. Shpelley says:

      Whoops. Clearly meant camelCasing for variables, PascalCasing for functions. Pretty similar to this style guide to be honest.

    2. Piflik says:

      That is pretty much exactly how I format my code. Some might use PascalCase for properties (get set stuff for non-C#-ers), since internally they are functions, but to me they function like a field for the caller, so I also use camelCase.

    3. Niriel says:

      I stopped differentiating functions and variables. A variable is just a function that returns its value, except you write it without parentheses. And because of actions and delegates you can have variables that are actually functions. In Python, you really don’t want to try separating the two (hell, even classes can be seen as functions in Python).

  3. Ian says:

    I typically these days use StyleCop in visual studio for C# projects.

    It can be really nagging when you start as it will not compile if you break the rules which makes hacking a quick test harder but by the same time it’s great because it wont compile if you break the rules.

    You can also customise the rules to your personal taste.

    I had this forced on my at work but I’ve since come to appreciate it especially when working with remote teams.

    1. Mike says:

      Yeah, 100% this. Style enforcement tools make it something that is enforced on check-in and not susceptible to argument or careless sloppiness.

  4. Onodera says:

    Microsoft’s own guidelines say “DO NOT provide instance fields that are public or protected. You should provide properties for accessing fields instead of making them public or protected” and say the naming of private fields is your own problem.

    1. Shpelley says:

      Unfortunately, Unity doesn’t provide the handy dandy serialization/UI editors for properties. Currently, the best way around it that I’ve found is using something like:

      [SerializeField]
      private string _myPrivateField = “Default Value here that can be overwritten by editor”;
      public string myPrivateField { get { return _myPrivateField; } private set { _myPrivateField = value; } }

      This way you get the nice editor fields, a way to set a default value and you just don’t touch the “_” version, only the camelCased version.

      1. Edward Lu says:

        That does seem like a good idea. I run into situations all the time where I don’t want to expose a variable to other classes, but I do want it to be serialized. That being said – gosh, that style is really verbose! Even just adding [SerializeField] to private variables adds two more lines (one newline ahead of the attribute for cleanliness).

        These days, in my scripts, a public field in a MonoBehaviour actually means “Expose this to the inspector”, and I’m disciplined about modifying it in other scripts unless it’s got a getter. A bad habit for working with others, I know, but it’s been okay so far.

        1. Shpelley says:

          I make copious use of #region blocks to keep my code nice and reasonable for glancing at but yeah, it definitely is kind of annoying that you can’t just do [SerializeField] private string foo {get; private set;} and have it work nicely.

          1. Onodera says:

            You can in C#7.3

            1. Canthros says:

              Which might make it to Unity in a few years.

  5. Ander says:

    I am made to use newlines for opening and closing brackets, such as
    if (check)
    {
    //TheCodes
    }

    And I do not like what I see as wasted lines of space.

    Oddly enough, my boss has also gotten it into his mind that “Less code means less bugs,” and has started indiscriminately getting rid of return variables. So,

    var result = //the maths
    return result

    is now getting refactored by him to

    return //the maths

    And, even though the former has an extra line, I like my return variables. They help with debugging.
    Anyway. In general I have a lot of freedom, but there are a few things the project lead is very opinionated about.

    1. Ivan says:

      I’m curious about his policy when you need multiple statements to fully calculate the return? And, yes, for a watch list it’s a lot easier to use a variable name than an entire statement block or some such. Though I sometimes still do that if I get desperate.

      Also, I personally prefer braces as in your example, this style

      if (check){
      //TheCodes
      }

      or (gods help us all) this

      if (check){
      //TheCodes }

      are just so hard to read by comparison.

      1. Ander says:

        Return variables are allowed, but if they at all can be removed, then they will be.

        What bothers me about the bracket thing is we write C# and JS. JS can’t have new line brackets because of auto line ending. C# can, so we use them there. The thing is, C# obviously could do same-line open bracketing as well; we just don’t use it. Obviously the two code bases look largely different anyway, but the chosen inconsistency doesn’t sit well with me.

        Personal taste:
        if (check){
        //TheCodes
        }

        is my favorite, and

        if (check){
        //TheCodes }

        is death warmed up.

        1. Olivier FAURE says:

          Ew ew ew ew!

          Put a space between your bracket and your parenthesis, you swine! Did you learn to code in a barn?

          EDIT: No wait, you were copying the other guy’s code. Still. Both of you will go in linting hell for this.

          1. Felblood says:

            Maybe it was a goat shed?

      2. TSi says:

        My vertical space is more valuable than my horizontal space, especially since we moved most screens to 16:9. Hopefully I can rotate my second one but laptops are cursed objects for me now …

    2. Olivier FAURE says:

      Personally, I think whether or not you should store the return value in a variable before the return statement depends on readability on a case-by-case basis.

      First off, if you’re going to name your value “returnValue” or “functionResult”, you’re probably better off with a return statement.

      Otherwise, it’s all about how easy it is for a reader to understand the semantic behind your function. For instance:

      return characterList.filter(where character.isStillAlive);

      is self-explanatory and doesn’t really need an additional variable. However:

      int hitpointsLost = (damage – armor) * damageReduction;
      return hitpointsLost;

      In this case, having a named variable may be helpful, as it helps explain what’s the semantic of the above calculation, and what value is returned by the function (though ideally that should be self-explanatory by the function’s name and parameters).

  6. kikito says:

    I program in several languages, and each one has different standards for variable names, indentation and whatnot.

    After a while, you don’t care about which one of these decisions are used. What you care about is that they are used *consistently*. While I was reading your blogpost I was with you all the way until you changed your policy halfway (introducing favoritepasta). That is something I would have never done – unless I was willing to go through all my code and re-adapt all names to that new policy.

    When possible, I really like using a linter: a program which parses my code and detects inconsistencies. Ideally it is integrated into my editor/IDE and runs every time I save.

    Some modern languages (go, rust) come with a standard formatter. I have set my editor so that every time I save files for those languages, the formatter is run automatically and the source code is formatted as it’s supposed to. Not having to think about indentation at all is liberating.

    1. Draklaw says:

      I agree. And even if the language doesn’t come with a formatter, it often have a standard (pep7 for python, …). I would expect C# to have one and that Unity follows it. Otherwise, I would expect Unity to have its own coding standard.

      In any case, I would try to follow Unity standard as much as possible for consistency. Also, it maximizes the chances that other developers are at least familiar with it, if one day the code is shared.

      1. Droid says:

        PEP8 is for Python, PEP7, funnily enough, is a Python Enhancement Proposal entry for C style. C in Python. But still…

    2. Echo Tango says:

      I work in Golang, Python, JavaScript, Typescript, HTML, CSS, SCSS, …
      As the commenter above, the biggest thing that helps is an automated tool to check your code for style. The command line tools, and the IDEs we use both show us style problems. Plus, Golang has a tool in the standard tool chain, to format your code as per the official styles. There’s ones for the other languages too, but to varying degrees of working-ness / having bugs.

    3. Retsam says:

      To me, a linter is basically necessary in an interpreted language like Javascript or Python: it always feels like driving without a seatbelt. Too many easy typos can go uncaught if there’s not a tool to catch them, and there’s no compiler to do that for you.

      I’m not a huge fan of the auto-formatter approach, though. I like the idea, in concept, but in practice I like having “an escape hatch” too much: being able to disable a linter for a particular bit of code. There are just cases where I just don’t like how auto-formatted code looks, or where violating a linter rule can make for better looking code.

      1. Echo Tango says:

        If you have to override the automated tool, it’s not smart enough! :)

        1. Olivier FAURE says:

          That’s great and all, but in practice there’s no linting tool for JS that doesn’t have to be overridden every so often, both because they’re all pretty young, and because the language is kinda crappy in the first place and hard to design around.

          You still need to use it.

        2. Retsam says:

          Part of it’s just language limitations as Olivier says… but also , there’s just no accounting for subjective taste. Whitespacing in particular is frequently the biggest issue. I don’t generally like spurious spaces, but sometimes it’s really nice to cheat a bit to get statements to horizontally align (making it easy to visually spot differences or see that they’re identical). And what’s normal and good whitespace in one circumstance might be excessive in another.

    4. Matt Downie says:

      Presumably he was planning to go through the project and rename all variables to the new standard – it wasn’t that big and it’s easy to globally rename a variable in Unity / Visual Studio (Control-R twice).

      Personally I’m fairly comfortable with inconsistent styles within a project. It helps me to know who wrote what.

  7. bubba0077 says:

    I’ve long used Java-style naming (Pascal case classes/methods, camel case variables) probably since that was my first programming course), but recently I’ve started using underscores instead for multi-word entities.

  8. Inwoods says:

    Nobody else going to comment that the CamelCase link is https://en.wikipedia.org/wiki/Camel_case?

  9. Scourge says:

    Its been such a long time since I have been programming, but my teacher, who taught me how to Programm in Delphi 5, always told me to name your variables properly.

    And I did. And that was around 15 years ago. And the last project I worked on privately… lets say, my variables are named properly and you know exactly what they refer, but if anyone picks it up they will hate me for naming strings like:

    string CSVJumpjetBattleTechID = JumpJetUniqueIDTextBox.Text;

    At least it is easy to read, until you get to combining it. Which just hurts because its a combination of 11 different strings named like that, all seperated by a “,”.

    1. Misamoto says:

      No they won’t(hate you). It’s a lot better then trying to understand what kind of “ID” is this variable among hundreds that are around the program. As for long typing… If your IDE doesn’t have autocomplete throw it away and write your code in notepad++
      Oh, and for long function calls or string concatenation just put some line breaks there, your language probably supports it.
      Concatenate (reallyLongStringName1,
      reallyLongStringName2,
      reallyLongStringName3)

    2. The Rocketeer says:

      Uh, sorry, this might be a silly question, but… did you work on BATTLETECH?

      1. Scourge says:

        Not exactly on Battletech, but I programmed a tool for it to make weapon creation easier.

        1. The Rocketeer says:

          Sweet!

          1. Scourge says:

            Its also on the Nexusmod website. Not sure if linking here to it is in good taste and what not, and self praise stinks and all that.

    3. Noumenon72 says:

      “UniqueId” seems like something that could be inferred from the variable type. Does the “CSV” variable hold comma-separated values?

      1. Scourge says:

        Not even that. As I mentioned above is it to create a weapon, all weapons have a Unique ID to identify them, which can be entered in a textbox in my programm.

        CSV was merely because if you want to add stuff to the Battletech game you need to put that stuff in the manifest.csv and I fill all the required info with that string.

  10. Gordon D Wrigley says:

    It’s weird to me that this is even a thing anymore, the standard style in the Python community is so standard that I’d basically forgotten that other communities don’t have such widely adopted standards.

    1. Paul Spooner says:

      I read through PEP 8 at one point, but not working with anyone else, my coding follows the path of least resistance, which doesn’t involve looking up code style guides in the middle of writing code.

      1. Droid says:

        Spyder (the Scientific PYthon Development EnviRonment – *sigh*) can highlight code that does not conform to PEP8, even though that setting is usually disabled. Didn’t stop most people at our uni to enable it on their own.

        1. Philadelphus says:

          I’m checking for this functionality as soon as I get back from lunch break. I’ve been using it for ~5-6 months now and never knew that.

  11. KarmaTheAlligator says:

    While not a coder, I do work with Unity for testing purposes, and since I try to report problems as accurately as possible for the coders, I end up using CamelCase a lot, and it drives me bonkers to not have a space in between the words.

    1. Paul Spooner says:

      Says the person who entered their name in CamelCase

      1. KarmaTheAlligator says:

        It still drives me bonkers when I do it, and it’s because the name is usually too long for most websites when I include spaces.

  12. A rule of thumb is, use the same style in the entire project. If you can’t use the same style in the entire project then use the same style within the same source file.

    Over the years as I recycle old code or rewrite it I make sure to “migrate” the styling to whatever I’m currently used to.

    These days when it comes to javascript I make sure to start all variables with v_ (short for variable) that way they’ll never clash with language naming of functions and so on, present or future.
    I also make sure to use “strict”; at the start of scripts or functions, and I try to put all variables under a single global (with sub variables), or put it all within a enclosure functions. I use f_ (for function) as a prefix for functions so you can’t mix up a variable or function.

    When it comes to PureBasic or C stuff I do similar things but I use namespaces as well as prefixes for variables or functions.

    If you use a IDE this may or may not mess wit autocompletion. On one hand typing v_ and using autocomplete will list all variables ad likewise with f_ for functions, but it’s also two extra characters to type.

    Regardless of what you do, keep things consistent within the source file and if possible within the project. If things are consistent then it’s relatively easy to “translate” the styling to whatever else using plain search and replace text processing.

    1. King Marth says:

      so you can’t mix up a variable or function.

      What do you do with variables storing functions?

      1. Shpelley says:

        I still format it as a variable (camelCasing) but Events all start with “on” (so “onWeaponFired” or “onDrawCard”) and UnityActions/delegates are stored as/with “Callback” as a suffix (so weaponFiredCallback or phaseCompleteCallback)

      2. Depends. What Shpelley says is a good idea.
        Personally I treat it as a variable if it is a variable holding multiple functions as the functions still have function names.

        But:
        f_sha512.hmac()

        Or:
        v_sha512.f_hmac()

        Would both make sense if it was consistent.
        v_sha512 would make more sense if there was non-functions as well there.
        f_sha512 makes more sense if it’s only functions under it.

        If it is a variable referencing a single function then that variable “is” the function name.

        f_sha512hmac = function () {//code here} for example.

        Sure you can also do v_sha512hmac = function f_sha512hmac() {//code here}
        but I’m not sure of he point of that. Practically v_sha512hmac and f_sha512hmac would be the same thing.

        Now this is just javascript and in other languages the behaviour may be different.

        But as I said, just be consistent, even if you are consistently wrong, at least it’ll be easier to fix/change later.

        Older coders like me (and Shamus too I guess) end up with a coding style guide in our head.
        Younger coders end up adopting something like jshint (and I’ve adopted that to some extent as well) and a style guide by Google or Microsoft or wherever they happen to work.

        @Shamus, maybe dust off those old urls to the Doom 3 source code and the legacy of Carmak, Google C++ styleguide seems to have a lot of the same practices.
        http://fabiensanglard.net/doom3/index.php

  13. Blake says:

    Main engine at work has some mostly adhered to standards:

    m_ – Member variable
    s_ – Static variable
    g_ Global variable

    lowerCamel – Variable
    UpperCamel() – Function
    ALL_CAPS – Macro

    if (true)
    {
    // Always add the braces
    }

    It’s not rigidly enforced though, lots of method-free structs skip the m_, sometimes people inline if (!blah) { return; }, and so on.
    Basically they’re guidelines not rules.

    I’m actually just starting on my first Unity project at work too, and apparently our Unity codebase uses _member instead of m_member too, haven’t decided if I’ll be adpoting that yet.

  14. Methermeneus says:

    Mostly, my programming style changes from language to language. You’d think my Python, Bash, HTML, and C were all written by different people. And then there’s the sloppy crap that happens when I have to do something in a language I don’t use much, like altering a Perl or Lisp script to do what I want, or if I’m using LaTeX to make a PDF. I don’t even know how you’re supposed to indent Lisp; that stuff’s ridiculous.

    Also, typo in that last caption: “inm” should probably not have that m.

    1. Methermeneus says:

      Now you’ve got me thinking about the details of how I write code. If anyone’s interested:

      I’ve recently gotten used to braces on their own lines; I always preferred (I’ve been told it’s a popular style in Java?) opening brace at the end of the line, closing brace on its own line, else (or while, for a do/while loop) on the same line as the closing brace. I also tend to prefer (spaces outside (parens)) , except for
      (static)casts , and no spaces inside parens or before square[brackets] at all. I tend to treat in HTML like parens in C, and block tags go on their own lines, while non-block tags are within the text, spaces around the whole thing, but not separating the tags from the text they affect. (Single tags like img get spaces around them, and I let the CSS sort them out.) My Python is pretty bog-standard, from what I’ve seen, and my Bash is kind of like my C except without most of the various kinds of brackets, if that makes sense?

      For naming conventions, I tend toward PascalCase for Functions, Macros, and Class/StructTypedefs; camelCase for mostVariables; old_fashioned_underscores for structs_and_classes and file_names, CAPITAL CONSTANTS and DEFINES, and prefix any GlobalUnavoidableGlobals (which I guess makes them PascalCase by default?) I don’t tend to name member variables differently; instead, I prefix anything _passed into a class member function with an underscore, and it’s usually obvious when you access class->member from the outside. I do sometimes prefix ClassMemberFunctions with the class name, however, along with functions that act mostly on a class (since they’re candidates to become class members, depending on what they do and how).

      EDIT: Oh, and I use longDescriptiveNames with /*plenty of comments*/, and I put the asterisk with the pointer type *variableName (or, more properly, away from the type name, since that also applies to (static *)casts).

      And, of course, I begin every function pointer name with a number. :P

  15. King Marth says:

    I think that having the leading underscore break autocomplete is a feature, at least Python uses the underscore for “private” variables to indicate that they shouldn’t be used by anyone importing the file.

    IDEs should make variable renaming easy, especially member variables which are all defined in the same place. Just go down the list, hit F2 or whatever the key binding is, and make something consistent which you like. It makes for an awkward commit, but doing those all at once isolates that from any other changes in your history.

    …You are using version control, aren’t you?

    1. Valthek says:

      Version control for unity is kind of a pain to set up, especially if you’re not super familiar with it. Unity tends to generate a lot (and I do mean A LOT) of extraneous files that have no business being in version control and unless it’s gotten better in recent versions, it tends to rename the folders those files hide in on rebuilds.

      They’re not a lot in terms of data size, but I recall several thousand small files being generated by the engine itself. I mean, a couple of lines of git black magic sorts that out, but maybe learni g git on top of a new language isn’t the best idea.

      1. Shamus says:

        I’m happy to say that it’s not this bad, although it’s still a little… strange. It’s really screwy to have your art all mixed in with the code like this, and the line gets pretty blurry sometimes. I’m still not 100% sure on what items I should be putting into VC and which I should leave unversioned. I started out with a pretty wide net, but as I’ve learned Unity I’ve pulled more and more stuff out of VC.

        What I’m versioning now:

        * All *.cs source files. (Obviously.)
        * Shaders.
        * The unity scene itself.
        * The stuff under /ProjectSettings, which are small YAML text files and which store important info about the project.

        I’ve been omitting Materials, but on further reflection I think I ought to be including them.

        I still don’t know if I should be paying attention to the hundreds of *.meta files, and if they’re important then I REALLY wish Unity would stick all that info into a single file.

        For the record, I’m not using version control through Unity, I’m using a standalone system. (Mercurial-based, if anyone cares.)

        1. Piflik says:

          For version control with Unity, you need to include the Assets and ProjectSettings folders. Omit all the rest, like temp or library. The latter will lead to problems if you checkout the project on a different machine.

          Also add everything in the Assets folder, including .meta files. These hold important information, like texture import settings, and are used by Unity to cross-reference assets. If you leave out a .meta file, Unity will create a new one for the respective asset, but it will have a new GUID and every other asset that had a reference to the asset in question will loose that reference and your Project will be broken. You might not ever run into this situation as long as you work only on one machine and use the version control just for backup/trying new features and rolling back if they fail, but as soon as you add a second machine to the mix, you need to know which files to version.

          There are som .gitignore files floating around on the internet that should be easy to find, with useful rules on what folders/file-extensions to ignore, like this one, which you can use as a pointer to how to configure Mercurial.

  16. Retsam says:

    I only used it for one class in college (and I think it’s largely been supplanted by Swift), but Objective-C was a bit of crazy language, and especially for it’s code style. Unlike most languages where a function has a name, followed by arguments, in Objective-C, the arguments go in the middle of the function name. For example, here’s the signature of a function pulled from an “simple iPhone app” tutorial:


    - (id)initWithTitle:(NSString*)title rating:(float)rating thumbImage:(UIImage *)thumbImage fullImage:(UIImage *)fullImage;

    I think as a result, the overall naming convention of Objective-C tended towards variables that were practically full sentences. It’s the sort of language convention that only exists in the age of good auto-complete, but even then it wasn’t my favorite thing.

  17. Retsam says:

    A nice thing about the domination of C as a language is that even though I don’t use C or C++, and I do use multiple languages on a regular basis for work and hobby stuff, virtually all of them are C-family and so it’s pretty easy to switch between them, at least in terms of syntax.

    Sometimes I use dramatically different languages like LISP or Haskell (I’ve got a bit of a soft spot for the idea of functional programming), and I understand why their syntax is so different.

    My slight pet peeve is a language like Python, which easily could have C-style syntax – it’s virtually identical semantics to a C-family language – but has its own uncanny-valley-of-C-family syntax. if not foo == 5: instead of if(!foo == 5), try..except instead of try..catch. No semi-colons, semantically significant whitespace, etc.

    IMO, it’s not better or worse than C-family syntax, (though I find semantically significant whitespace to be sketchy) it’s just different. Enough so that it’s taken some practice to switch between the two, and I often find myself messing up my variable conventions, though thankfully linters help with that, a lot.

    (Another point of annoyance is that since JSON is the standard API data format that we use, our python code ends up with a combination of snake_case and camelCase anyway, depending on whether you’re directly dealing with API data or not.)

    1. Groboclown says:

      our python code ends up with a combination of snake_case and camelCase anyway

      This irks me, too. Python itself was filled with this, as the Java naming convention snuck into the standard libraries.

      I found that this usually happens with languages like JavaScript that allow for dynamic construction of object members based on an external source. This leads to weird looking code that, mid-statement, switches between different styles.

  18. Dreadjaws says:

    You should have called this “Week 7.5”, because I slept so hard last night that when I woke up and saw this I was legitimately scared that I had slept a whole week.

  19. Mephane says:

    I kind of expected that link to a blog post by Joel Spolsky, and was not disappointed. I have read that very post in the past already, and while I very much agree with his take on Hungarian notation (to the point that I still now despise the Systems Hungarian style), I have in the meantime reached a different conclusion regarding an example like his: if you have two incompatible categories of strings that go through the same pipeline, it might often be better to have dedicated classes for these strings that don’t silently auto-convert to unrelated data types.

    You could then, as in his examples, create the function Write with two overloads, one for the class SafeString and the other for the class UnsafeString. These two strings could be made to auto-convert between each other, always performing the necessary encode/decode step, but to convert a raw string into either (and vice versa) would require an explicit function call (which is what the C++ keyword explicit was literally made for).

    It is a lot more up-front work, but can pay off in the long run, as the compiler itself can then enforce the correct use and conversion steps between these classes.

    1. Groboclown says:

      I was expecting the link to be to Cedric’s blog about why he chose to make the Android coding standard.

      One thing that’s changed the need for this notational styling is much better IDEs. With a good IDE, it’s able to understand the scope and type of variables, and give you font style changes to the variable name to tell you more information about it. This usually removes the need to add names for scope, and leaves the use of naming conventions to describing how it’s used.

  20. default_ex says:

    My coding style has certainly evolved over time and grown to encompass more things.

    Variable:
    const Type c_nameOfPrivateConst;
    public const Type c_NameOfPublicConst;

    static Type s_nameOfPrivateStaticVar;
    public static Type NameOfPublicStaticVar;

    Type m_nameOfVar;
    public Type NameOfVar;

    Type nameOfLocalVar;

    void NameOfFunc(args) <- same casing for public or private.

    void OnSomeEventHandler(args) {
    };

    The ones I can’t reliably denote in a comment.
    * If a parameter in a function that requires multiple arguments needs to be put on a new line, then all parameters are placed on their own lines except where logical groupings exist (x, y, z or r, g, b for example).
    * Large amounts of variables in a class or structure are spaced according to guides for easy identification of access level, type and name. The only exception being the rare too long to fit the guide cases. I set my guides to fit within 800 pixels of width for splitting on a 1680 wide monitor cleanly.
    * If any variable name takes more than 3 characters after the m_ for intellisence to detect, the variable names need to be adjusted accordingly. This is not an arbitrary choice, it’s based on an article posted a long time ago that analyzed hundreds of projects and their commit logs for weird statistics.
    * If an object contains value types, it is a struct, if it contains instantiation or references then it is a class. This began with my C++ programming but has turned out to be massively helpful in C# with how it handles the difference between stack and heap allocation.
    * State changes must have intermediary states (loading between initialized and loaded for example) and their indicators set accordingly via atomic operations. This has helped tremendously with avoiding costly locks in multi-threaded code.

    It’s gotten pretty complex at this point. Long gone are the days where style is just naming strategy and formatting. So many factors at play now that it boggles the mind when you stop to think about how much your actually doing out of habit and muscle memory that is stylistic but not necessarily required to write good code.

    1. Mephane says:

      except where logical groupings exist (x, y, z or r, g, b for example).

      I have found that in almost all cases where stuff like this occurs, the better option is to create a struct or class for the grouping, and pass that around as a whole.

  21. GargamelLeNoir says:

    Of all the coding styles I’ve tried my favorite comes from the Java best practices :
    ClassToInstanciate/objectInstanciated/methodOfTheClass
    But now that I’m on C# it’s a pure mess that I’ve taken to call “Worst Practices”, I’m still struggling against it.

  22. blue_painted says:

    I’ve been a Pascal programmer (eating quiche, not cheese-flan) for the last thirty-mumble years, and in that time I adopted Borland/Inprise/Embarcardero name style … camel caps for everything but with types prefixed T so TSpaceMarine and fields (members) with F so TSpaceMarine.FHitPoints … but properties exposed with no prefix, so MeatHead:= TSpaceMarine; MeatHead.HitPoints:= 100;

    Recently I’ve moved (been moved) to C# and TypeScript (Yay, Anders!) and there I use much the same for both … I’ve reluctantly given in to underscore for private members, but now I use CamelCase for types, all lowers for properties and “WTF case” (which some people call PascalCase) for method names.

    (this is turning into a rant)
    Long identifer names … nope. HitPointsFromIncomeMissles vs HitPointsFromInwardMissiles – both valid, both too hard to spot. And something like HitPointsTakenFromIncomingMissilesThatHitTheSpaceMarine (not the longest I have seen in real code) is just mad!

    Case sensitive identifiers. I know i’m pushing water up hill here, but no. no. no. no. no. and thrice no. People will read SpaceMarine and Spacemarine as the same, a case-sensitive compiler won’t … but a compiler is just as good at differentiating 08AF4400 from 08AF4480 …. and people aren’t, which is why we have identifier names in the first place.

    Indenting and blocks. I follow Vs on this …
    if(expr) {
    … code…
    }
    else {
    … other code ..
    }

    because i like to have the expression and the alternate code easy to spot.

    One last whinge: switch(){ case “blah”: code; break } …. What the HFD is that all about? When do you EVER see the individual cases fall through? That break; is just bad bad bad. Make it stop.

  23. Rymdsmurfen says:

    I try to follow Microsoft’s code style when coding C#, using PascalCase for all identifiers except variables, parameters and private fields, which use camelCase.

    Instead of prefixing class fields with “m_” or “_” I prefix them with “this.”, which makes it explicitly clear, not only to the reader but also to the compiler, that I’m referencing a class member. Resharper can be set up to helf you enforce this rule (although this might not be an option in Unity).

    I haven’t used Unity, and I don’t have the full context, but it feels wrong to let a tool dictate how you name you class members. Attributes were made to allow adding meta-data on program elements, and this seems to be a case were that would be the proper solution.

  24. tmtvl says:

    I’m a Perl dev, so I’m more used to self_documenting_names_with_underscores and using comments for anything I won’t remember in 6 months time. Ever since Perl6 was released my style is changing slightly to amend for the differences between the two languages, so I can switch back and forth without too many headaches.

    my @list = qw<a b c >; for example.

    I don’t really like camelCase and PascalCase very much, but when I’m working in Java I adapt to the standard style.

  25. kdansky says:

    This is why one should always adopt the generally used style by the language in question instead of sticking to a style that was used for a different piece of tech.

    And after changing styles a few times it has the nice benefit that one stops being such a dickbag about different styles.

    I sometimes write python, lua, D and C++ and I use a different style for each, with only minor personal touches such as relatively short variable names (because I write short functions).

  26. Nick Johnson says:

    I work at Google. We have *rigorously* enforced style guides for every language we use. We require full code review before submission, and I you can’t even send code in most languages for review if the linter sees anything it doesn’t like. In the case of Dart and Go it has to exactly match the output of the built in code formatter.

    The primary rationale is that we keep all of our codebase in a single repository with many billion lines of code. The next engineer who looks at your code without any knowledge of it or additional context should be able to just read it, without having to adjust to the style. You’re encouraged to consider the possibility that this engineer might be you.

    For side projects (which are mostly in Swift at the moment), I always use UpperCamelCase for classes and lowerCamelCase for everything else. Except python where I usually use snake_case (or occasionally fuckiticantbebotheredwithspacescase). I tend to always use self. or this. (as appropriate) for accessing members.

    Side note: Go has an interesting rule for variable names: the length of the name in characters should be directly proportional to number of lines between creation and use.

  27. Josh says:

    I use pascalCase exclusively, in Typescript we use this.variableName to refer to members of an object internally and objectName.variableName to refer to member of another object. Constants are ALL_CAPS and inputs on components(essentially a way to pass values to a component from code or from the markup) are done like _inputName

  28. Duffy says:

    Been tooling around in C# and Unity myself and have been trying to get myself into more of “common” standard practice as my C# habits have been fairly rusty.

    The standard I’ve been following for this is:
    Everything is a some form of Camel Case

    Public – CapitalizedCamelCase
    Private – _underscoreLowerCamelCase
    Private Constants – CapitalizedCamelCase (honestly not sure why but it was a distinct point in the standard primer I was working off)

    Method names also follow capital leading letter Camel Case in the form of ActionObject and parameters are lower case leading letter Camel Case such as lowerCamelCase so they can never be confused with class properties.

  29. Anachronist says:

    I’m just glad this post didn’t mention the age-old debate about indenting with tabs vs spaces!

    1. Daemian Lucifer says:

      That’s because it’s a long time solved problem. You use neither of those, but rather >>

      1. tmtvl says:

        What kind of scrub uses line breaks anyway? Just put everything on one line.

        $_ = "wftedskaebjgdpjgidbsmnjgc"; tr/a-z/oh, turtleneck Phrase Jar!/; print;

        1. Chris D says:

          Still too readable.

          You have to use the preprocessor to turn every file in the codebase in to an ASCII art picture of a raised middle finger. (oh, and all the preprocessor defines should be done on the compiler command line, just for extra brutality.)

    2. Piflik says:

      There is no debate. Spaces are wrong. If you use tabs, everybody can configurate how wide their indentation should be and every file will always have the right look for the user looking at it. Spaces break this, and if you use spaces in my code, you’re fired.

      And to make sure there is no disagreement to my post: it is Gif, as in “graphics”, not Jif, as in “I am an idiot who cannot pronounce a simple letter because of peanut butter that doesn’t even exist outside of my home country”.

  30. Piflik says:

    If you make fields public for the sole purpose of viewing/editing them in the Inspector, please make them private and add the [SerializeField] attribute instead. The code will look a bit uglier, but you have proper encapsulation.

    Also, be advised that when you expose a field to the Inspector and change that variable through it (sometimes even without changing it), Unity will save this changed value in its Scene or Prefab file (which are also YAML, if you enable text serialization for Version Control, which you should, since it makes merging scenes/prefabs only completely annoying as opposed to impossible). If you then try to change the start-value by initializing the field with a different value in your code, this change will not take effect. I regularly run into the problem that I try to test different start values for a field and it doesn’t work, because I forgot that the field is public/serialized and Unity ignores the changes in the code.

  31. Abnaxis says:

    I don’t think I’ve ever used the same languages for more than a couple months running. I work with a lot of hardware, and a lot of that hardware has its own language conventions and programming tools, including ones that seem like they actively try to make your code unreadable like (eeeueuuuuugh) Matlab*.

    I just kind of muddle through and try to stick to whatever convention everybody else is using in context

    *Seriously, if you see ‘f(2)’ in a line of code, you don’t know if that’s indexing the second item of array f, or whether it’s calling function f with an argument of 2, or whether it’s taking the symbolic expression f and substituting 2 in for its independent variable….WHAT THE FUCK IS WRONG WITH YOU PEOPLE GOD I HATE THE DESIGNERS OF THIS LANGUAGE AND THE MATHEMATICIANS AND ENGINEERS WHO CLING TO IT.

  32. Zak McKracken says:

    2) Code that does not conform to standards will be really obvious.

    Not so sure of this. If you forget to put the “m_” in front of some variable that should have it, or don’t follow a naming convention strictly, that’s not necessarily easy to spot.

    I’ve got some large-ish programming project going on in Python, and I’m frequently violating my own conventions because I didn’t write them down properly, and because I keep making some of them up as I go. But I’ve had a few times when I went through some part of the code trying to make it consistent and wasn’t really able to tell if it already was without chasing some variables’ trajectories through the code.

  33. saj14saj says:

    I won’t say what conventions I follow, because they are boring, and I don’t think anyone cares, really: the only important thing about conventions is that they are *consistent*.

    That is unless the convention is in some way harmful to life, the universe and everything.

    In these days of modern IDEs, the m_ (and s_ and so on) practices are harmful conventions, because they sort all your identifiers in essentially one mass, and the m_ simply becomes noise that is irritating to type, and that peoples’ eyes must be trained (well, technically brains must be trained) to skip over in order to find the semantically interesting part.

    I like many things about Go, and the fact that it has a standard and uniform style is one of those things.

    Also, the quality of code is inversely proportional to the square of the average number of underscores per file. I am looking at you, modern C++…. when did you become so hideously ugly? :-)

  34. Grumble says:

    To answer your questions, because it’s fun:

    I usually use different styles for different languages, but within a language at a company, style is either pretty consistent or entirely undefined.

    Also, you forgot the most important reason to have a coding style: people write code in high level programming languages (like C, C++, C#, …you know what? I’m leaving it there) for humans. All programming languages that are not sequences of binary opcodes are designed for humans to read.

  35. Tom says:

    Those variables are hilarious. Double for burlyness, float for beard stubble? Comedy gold. I was snickering before I even got to int m_dead_wives!

    1. Droid says:

      Ikr! All those long ints before that and then they make dead_wives merely an int! How are you supposed to roleplay with that???

      1. Tom says:

        Is it wrong that I now really want to play this hypothetical game, just from reading the variable names?

Thanks for joining the discussion. Be nice, don't post angry, and enjoy yourself. This is supposed to be fun. Your email address will not be published. Required fields are marked*

You can enclose spoilers in <strike> tags like so:
<strike>Darth Vader is Luke's father!</strike>

You can make things italics like this:
Can you imagine having Darth Vader as your <i>father</i>?

You can make things bold like this:
I'm <b>very</b> glad Darth Vader isn't my father.

You can make links like this:
I'm reading about <a href="http://en.wikipedia.org/wiki/Darth_Vader">Darth Vader</a> on Wikipedia!

You can quote someone like this:
Darth Vader said <blockquote>Luke, I am your father.</blockquote>

Leave a Reply

Your email address will not be published. Required fields are marked *