So I use JavaScript right now but everyone’s telling me to use C# instead because it’s better. So I took a look at it and the only thing I found that was better was how confusing it was:face_with_spiral_eyes:. I really didn’t see any reason to use it, but people say you have more control and performance is better and you can do things with C# that you can’t do with unity. I’ll use C#, but only if there’s a reason to, I’d rather use JavaScript because it’s simple. So what are the advantages/disadvantages of C#?
-
Performance is NOT better. They both compile to the same stuff when you publish.
-
There are a few things you can do ‘properly’ with C# that I feel are a little rough in JS.
-
Most users of JS probably don’t use #pragma strict, which is probably why it feels easier. In a bigger project, that convenience can potentially become a big problem.
-
C# has significantly better tools (VC# Express) than monodevelop and the like.
but…
If it JS works for you, stick with it 
Uh, Java != JavaScript. Actually, Unity’s JavaScript doesn’t even conform to JS standards; theres a good argument to be made that it should be called UnityScript.
hmm I think I might use C#
Also, an additional positive point about C# is that a tremendous body of cross-platform work exists.
Want Box2D? Theres a port for that. Want LibNoise? Ditto. Networking? Lidgren. So much cross-platform, unity-compatible work has already been done and freely (or low cost) available on the net!
Furthermore, should you stick with Unity and in the process become an excellent C# programmer – let me tell you, thats a skill that pays the bills. 
Javascript (and Boo) has a custom compile system that allows you to extend the language and create your own language constructs. It has more automatic features where for smaller classes you have to write less code. This can also mean you may not understand what’s going on in some situations when debugging because critical things are done behind the scenes (looking at you class creation and coroutines). Also without #pragma strict, some seemingly innocuous assignations can take significantly longer than expected, and this will be hard to debug without #pragma strict (which I suggest is always used). It’s not real Javascript though, and tutorials are basic, and restricted to Unity, as it’s a somewhat proprietary language. This limits your learning resources.
C# has more features and abilities than JS/Boo. To name a few: Using Alias, Using Statement, Lock, Delegate creation, Multi-cast delegate assignation, Linq, Properties (that are documented), Custom Generics, Extension Methods, try-catch-finally (specifically the finally part). These are generally more advanced, although some of them are magnificent work savers and safety nets to make life easier. It is also unbelievably documented and I’ve yet to find a language with more examples, source, learning resources and overall library documentation. If you use C#, bookmark the MSDN. There are also myriads of resources such as Threading in C# - Free E-book that are just well made and useful for all skill levels. I think C# is a fantastic language, it’s syntax is clean, it’s strict and very easy to read and understand other people’s code or your own old code.
All that said I suggest C# to those that are unsure. The reason being that while making games, you will inevitably have to look outside of Unity for how to do things, such as using threading, reading/writing files, serialization, reflection, zip libraries and tools, etc… And if you only know JS, these resources are NEVER going to be in your language. C# may look more intimidating, but once you dive in you’ll find so many more places to look for help that very rapidly offsets and overtakes the early-on ease of use JS provides. In general you don’t miss what you don’t have, and while not having Delegates and Properties really sucks, you’ll find alternatives. The customized compiler extensability of JS and Boo is an unbelievably cool feature, but is really only likely going to be taken advantage of by the most advanced of users in larger teams working with Unity on multiple projects, or for little find and replace type jobs that save a few minutes.
As far as .NET APIs (System.IO, System.Collections, etc…), all languages have access to them, with the exception that JS/Boo don’t know Extension methods, delegates and keyword helpers. They all compile to the same stuff and are fully interoperable otherwise.
@Andorov, those libraries are also readable by JS/Boo, as a DLL is in CIL and not the original language. The only problem would be playing with the source, if you don’t understand C#.
Edit: Also echoing that C# has better IDEs (environment you program in, VisualStudio/MonoDevelop). This means that in C# you are much more likely to have code completion and Intellisense, which in my opinion saves much more time in a much safer way than JS’s auto class creation and type inference (or any syntax time savers JS happens to have).
Except for the part where it’s not Unity specific. It’s a .NET/Mono thing, and as far as I’m aware it’s full name is something like “JavaScript.NET”.
On the performance thing, while both languages will compile equivalent code to the same CLI, that’s kind of beside he point because the languages encourage you to do things differently, thus you probably won’t end up writing equivalent code unless you go out of your way to do so and have a fairly in depth knowledge of how both actually work under the hood. In my opinion, that defeats the purpose of using JavaScript for its simplicity.
JScript.NET is not Unity’s Javascript.
Unity’s Javascript is an open-source extension of Boo, made by the creator of Boo, now employed by Unity. It’s only current application use is within Unity, but you can go and download the source and implement it in personal projects if you really wanted to.
Nor is it IronJS, or any other existing .NET Javascript implementation. If you are interested in seeing it’s source: bamboo (Rodrigo Bamboo) · GitHub
It’s important to note that JScript.NET and IronJS both use the .NET DLR(Dynamic Language Runtime), and Unity’s Javascript does not. Languages using the DLR will get severely limited when compiling using the Ahead of Time compiler (required for iOS). This makes DLR languages not suitable for Unity as a whole.
Now I really want to learn C#, where should I start I’m an awesome programmer with JavaScript, also is C# more clean than JavaScript? I feel like whenever I get into a long JavaScript code it becomes very complicated to edit or debug or change, and I usually just restart the whole script. Is C# more straightforward? What do the big game developing company’s that use unity program with?
Keeping large files maintainable is a skill you need to learn for yourself moreso than a property of the language you use.
Any tips?
Err… that’s a huge question. People spend years studying it and still don’t agree.
Keep functions as small as possible and as self explanatory as possible.
Use consistent formatting.
Use consistent naming conventions.
When a function becomes too big, break it down into smaller functions.
When you design and write a class, it should be responsible for one task and only one task. When you add something new, ask yourself whether it’s aligned with the existing purpose of the class and, if it isn’t, do some redesign.
Following on from that, a class or function should be no bigger than it needs to be.
For longer classes, break them up into sections and put related functions together. C# has #region and #endregion, other languages give you other ways to “tuck away” bits you’re not currently working on, and there’s always “code folding” features of editors.
When designing a new class or piece of functionality, think not only about what it does but also how it will be used.
When commenting/documenting your code, imagine that you’re giving it to another coder who is exactly as competent as you but who has never seen the code before. Don’t tell them what[/]b] the code does, they can figure that out by reading it, instead tell them why it does it - because that’s what you’ll be scratching your head about when you come back later and have to change it!
Solve similar types of problems in similar ways throughout a project as much as is possible. Don’t use a timer variable in one place and timestamp checks in another - pick one and stick to it.
Don’t optimise prematurely. Note that “prematurely” doesn’t mean what most people think. It most certainly doesn’t mean that you shouldn’t optimise until the end of a project, where a lot of it is too late. It means that you need to make sure you know what you’re optimising before you do it, you need to make sure the optimisation will matter, and you need to make sure it won’t slow other things down later. So don’t “optimise” in a way that makes the code execute faster but which gives unmaintainable code and/or a painful development pipeline, for instance.
I could go on, but I’m running out of lunch break…
What AngryPenguin said, plus:
Code in MonoDevelop/Visual Studio. Having a nice, clean IDE helps managing files and structure immensely easier, from colour coding of syntax, to Intellisense and code completion, to Document Outlines and Solution Explorers, to Assembly Browsers, to being able to find usages of specific variables, rather than just ones that have the same name, it just makes life easier.
When using MonoDevelop make sure to go to Views->Pads->DocumentOutline. This is a fantastic little window that shows the current file’s classes/methods/variables/properties/etc… in a clear, concise hierarchy. Clicking any of these elements, focusses your coding view to that element. This doesn’t so much make more maintainable code, but makes it much easier to understand and manoeuvre through significantly more and more complex code easier and faster. It turns it from hunting for keywords and line numbers to having a blueprint for the file and focussing only on what it is you want to look at.
Don’t be afraid to add white space and use new lines. You are not being charged by the character/line and at some point in the future you are going to be rapidly hunting down with the scroll wheel, and want distinct parts discernible from each other even at a quick glance.
And work with Unity’s components system, such that you want each MonoBehaviour to perform 1 thing, such that you could remove that thing from the whole and everything else would still work. I.e. If you removed your Movement Component, there is no reason your gun firing component shouldn’t work, or your look component. Don’t try to jam them all into a large Player class that does everything, because it’ll only cause headaches when you decide to change one part (and you will at some point). This should help reduce the need to have larger files.
Use /// on the top of objects(classes/variables/methods/properties/etc…) to do your commenting. This works with Intellisense so that when you use that class in a different file, your documentation will show up as tooltips. This makes it easier to remember what each thing is for, without having to jump back and look at the code. It also automatically creates a commenting framework. This one is much more significant in group projects, or projects involving multiple modules rather than personal, 1 programmer projects.
All that being said Software Design is a massive topic with pretty much everyone having their own opinions. I wrote a couple extra, but it really depends highly on your personal preferences.
Woa thanks for all the tips! This is really going to help me with my programming career in unity!
Thanks for this thread guys, I really wasn’t aware that unity used JavaScript.Net and thought that C# might restrict my unity apps to the windows platform but that doesn’t seem like the case now and I’ll happily be rewriting my latest project ( luckily I’m not far in )
It doesn’t, it uses Unityscript.
–Eric
A huge plus for unityscript is its similarity to flash actionscript 3 - coming from an actionscript background it only took me a day or two to pick it up fluently. They are 99% the same. It should work visa versa, so if you haven’t dabbled in flash and you have a firm us understanding, give it a try.
C# has a benefit in that it’s the goto language These days, so it will put you in a better programming position on your resume and increase your employability prospects.
That’s imho the only reason to go with UnityScript. For someone who knows neither JavaScript, ActionScript nor C# or Boo, C# is clearly the better way to go