C# delegates, I love you ...

For confirmed devs, it can be obvious, but for people like me who come from more "simplistic" languages (javascript, ActionScript, Java, etc), their true use discovery just made me cheer like a soccer fan during finals, and say ... "goddamn it, why didn't I know this earlier ?"

So I wanted to share the experience, so other people who learn C# will not make the same mistake as me
(I'm not claiming to know everything about delegates, so if this post need corrections, feel free)

In short, delegates. That is the basic.
You can read the page, but to sum it up, delegate is attributing a method execution to a variable at runtime. So in short, imagine you have a huge core function, SpawnEnemy(), where at some point you want to spawn very different enemies with very different behaviours, under very different conditions. Instead of writing a 5000 lines long if () {} else if () {} else if () {} crap sauce, you just insert a delegate (let's say, OnSpawnEnemy()). Then for each new SpawnEnemy() called, you can reattribute the OnSpawnEnemy delegate to a different function from another script, depending on which condition is met (indeed, OnSpawEnemy reattribution has to happen before its execution).
For example, at time 25f, some manager reattributes OnSpawnEnemy = CreateTrolls to create Trolls, at time 50f OnSpawnEnemy = CreateOrcs to create Orcs, etc,. Then whenever I call OnSpawnEnemy(), it will create the defined type of enemy.

But I found this MSDN tutorial page wasn't doing much justice to their real power ...

Two things I found which were totally awesome :

1) Anonymous delegates : I don't know if it's some coder porn syndrome, but I love this one. In short, instead of hardwriting tons of different separate functions for each delegate case you want, you just write OnSpawnEnemy = delegate { //stuffToDo } . It's a must for structure visibility. The only downside is that what's inside the delegate doesn't save conditional variables. For example : for (int i = 0; i < 5; i++) OnSpawnEnemy = delegate { Debug.Log(i); } will always display 4. So you have to hardwrite variables. But it's not a big deal really, as you're not supposed to create super complicated anonymous delegate bodies (for debugging's sake).
What I like with anonymous delegates is that you can "hack" a core behaviour at any given time under whatever condition you want, just by writing a quick subscript. Visually, the fact of not declaring a whole new function will 100% fit the very contextual nature of the change, keeping your core architecture clean.

2) the most important one : the += and -= operators. So let's take our OnSpawnEnemy(). What if at some time, I want to spawn 4 Trolls AND 4 Orcs ? You just write :

Code (csharp):

1. OnSpawnEnemy += CreateTrolls;
2. OnSpawnEnemy += CreateOrcs;
3. OnSpawnEnemy(4);

And if later on, you don't want to spawn Orcs anymore, just write :

Code (csharp):

1. OnSpawnEnemy -= CreateOrcs;

As said in 1), the real power here is to make you able to hack a generic, core function. When you have a highly complex architecture, it's always better to merge redundant operations into core functions, so you trim the code noise for better clarity. It's better for debugging, too. For example with Orcs and Trolls, instead of creating 2 separate full creation functions, you merge every critical common code into SpawnEnemy (like memory management, common asset instancing, common variables like HP, strength etc declarations, etc). And then you create the "exoticisation" of your enemy in specific, separate functions that you integrate in the core one, like written above.
At first, I was using virtual/override methods to fit each different injection. But what if I wanted to create 2 merged overrides within the same virtual entry ? I had to create another virtual into the first virtual, or one after another, etc .... VIRTUALCEPTION ! a nightmare And most of all, a huge waste of code space as you have to declare your empty virtual functions ...
But here with delegates, no need to declare useless virtual empty functions.. just to call OnSpawnEnemy() (+test if null beforehand), and add/retrieve as many hacks as I want with a single += operator, from wherever I want.

________________

Conclusion : I don't know if delegates were created (or function pointers in C) with videogames in mind, but it's clearly a must for behaviour management, and totally fits the nature of videogames code dynamic logic.
Want to add a powerup to that punch ? No problem. OnStrikePunch += PowerUp;
Want to retrieve that wall bounce testing for that ball ? No problem. OnBallHitTest -= TestWalls;

I can also see how powerful delegates can be in a collaborative environment. The architect creates core code "waypoints" as delegates, and then each dev can control what type of behaviour he wants to add inside that waypoint.


Anyway, just to wanted to share my nerdiness for delegates, but feel free to add anything you want about them, like other particularly useful scenarios, etc.
Oh and did I mention that delegate were fast ? ;-)
(That was my first fear when I realized how powerful they were)

 

Now read up on Lambda's, Action Func.

 

But I'm only lvl 33 ..
Thanks ;-) C# is really feeling like an endless Ali Baba's cave for efficiency, stability AND simplicity. Why isn't it more widespread in videogame dev jobs ?
(granted I didn't really extensively test C++, but it seems like C# is evolving much faster)

 

That's one of the reasons I completely switched to C# within Unity. I wish I could switch to C# in my day to day work, too

 

Delegates are really powerful but use it wisely! And C# is my fav programming language!

 

Code (csharp):

1.  
2. for (int i = 0; i < 5; i++)
3.     OnSpawnEnemy = delegate { Debug.Log(i); }
4.  

This code makes no sense, at least I don't see any, but if you want to get 01234, you can write it like this:

Code (csharp):

1.  
2. for (int i = 0; i < 5; i++)
3. {
4.     int i2 = i;
5.     OnSpawnEnemy += delegate { Debug.Log(i2); };
6. }
7. OnSpawnEnemy(); // prints 0 1 2 3 4
8.  

The temporary local variable is necessary, otherwise you'll get 55555 or maybe something else you don't expect too see. If you wonder why, read about closures and what they close over.

---
If at some point you decide to subtract your delegates, be careful:

Code (csharp):

1.  
2. class Program
3. {
4.     static void Main(string[] args)
5.     {
6.         Action a = A;
7.         Action b = B;
8.         Action c = C;
9.  
10.         Action x = (a + b + c) - a - c;
11.         x(); // prints B
12.         Console.WriteLine();
13.  
14.         Action y = (a + b + c) - (a + c);
15.         y(); // still prints ABC, because ABC sequence doesn't contain AC
16.         Console.WriteLine();
17.  
18.         Console.ReadLine();
19.     }
20.  
21.     private static void A() { Console.Write('A'); }
22.     private static void B() { Console.Write('B'); }
23.     private static void C() { Console.Write('C'); }
24. }
25.  

 

@Stramit : Thanks for the infos ! There's clearly a danger here ... I should check that out now ...

@Alexzzzz : the code was just for quick explanation purpose ;-) And thanks for your tips too ! I didn't grab that boolean logic yet, that's great info.

So in the end, should I deduce that Virtual/Override are safer concerning memory and GC ?
Therefore better for an intensive function triggering ? (like state manager)

 

@Stramit :

Now I'm afraid
If I understood correctly, you mention there that when a container (gameobject) is destroyed, the references in his components are not ? (assuming they're not referenced anywhere else)
Is it like that ? For example I have let's say a "system" gameObject, where I put a bunch of Texture2D references, all loaded with Resources.Load. If I destroy this System gameObject, those Texture2D references won't be cleared ? :O
Shouldn't it be the case ?

 

Ok thanks

 

A brief example:

Code (csharp):

1. public class FooManager : MonoBehaviour
2. {
3.     public Action actions = null;
4.  
5.     public void DoActions()
6.     {
7.         actions();
8.     }
9.  
10.     // ...
11. }
12.  

Code (csharp):

1.  
2. public class Foo : MonoBehaviour
3. {
4.     private byte[] hugeAmountOfData = new byte[100000000];
5.     private FooManager manager;
6.  
7.     private void Start()
8.     {
9.         manager = (FooManager) FindObjectOfType(typeof (FooManager));
10.         manager.actions += DoSomethingUseful;
11.     }
12.  
13.     private void DoSomethingUseful()
14.     {
15.         //...
16.     }
17.  
18.     // ...
19.  
20.     private void OnDestroy()
21.     {
22.         manager.actions -= DoSomethingUseful; /* You need this, because 'actions' delegate
23.                                               * still contains a reference to this Foo instance,
24.                                               * which means the instance will always stay alive
25.                                               * and won't be collected by the GC. */
26.     }
27. }
28.  

 

Ok. I understand the logic, but, shouldn't a Destroy() (in an ideal world) turn every instance of it to null?
Like here, calling manager.actions() should ideally make a NullReferenceException ? (if we don't substract to manager's delegate)

 

Code (csharp):

1.  
2. var referenceToInstance = new GameObject("Lucky");
3. var secondReferenceToTheInstance = referenceToInstance;
4. var andAnotherOne = referenceToInstance;
5.  
6. DestroyImmediate(referenceToInstance); /* Releases some internal resources that
7.     the instance were using, but it doesn't destroy/erase/eliminate the instance
8.     * completely, only the garbage collector can do it. But at this moment the GC
9.     * still can't collect the object, because there are three references to it.
10.     * There's no any magical way that Destroy() could set all the variables to null,
11.     * they are still pointing at the halfdead object. */
12.  
13. Debug.Log(referenceToInstance == null); /* Prints 'true', because UnityEngine.Object
14. * overrides the comparison and returns 'true' if the object is marked as destroyed.
15. * It doesn't mean that the reference is actually null. */
16. Debug.Log(ReferenceEquals(referenceToInstance, null)); // Prints 'false' (that's the truth :)
17.  
18. referenceToInstance = null;
19. secondReferenceToTheInstance = null;
20. andAnotherOne = null;
21.  
22. /* Now there are no live references to the object and the GC is able to collect it. */
23.  
24. Debug.Log(ReferenceEquals(referenceToInstance, null)); // Prints 'true'
25.  

 

Gotta love C#

I didn't know about Action and Func. I've been writing my own delegate definitions here, and looks like I may have reinvented the wheel a few times, heh.

Cheers

 

Ok thank you Alex, that makes sense now.
If we wanted Destroy to take full control of that nullification, there should be a "ref" keyword as object parameter I suppose.

 

When you do a += to register a delegate you must always add a -= to the same delegate otherwise the game will leak like hell.

By the way delegate are not that fast, they are slow actually. But indeed it is very powerful and useful for event management.

You made a example with Spawning enemies, but instead of using delegate, i prefere here to use an Interface (with a spawn function) and to implement decorator pattern to add different logic to the spawn.

http://en.wikipedia.org/wiki/Decorator_pattern

 

Welcome to continuations/closures.

BTW JavaScript supports this and, while I haven't used Java in 15 years, I would assume it does too though it might be hackish, I'm not really sure. In fact most languages support this sort of thing though it might take a bit of thinking-outside-the-box to get it done.

 

Thought someone would find them useful. C# started off with hideously verbose delegates and slowly made them more and more usable.

For those interested in finding out more about C#'s awesomeness C# in Depth is a great book. My list of everyday cool things are:

• Extention Methods
• Lambda's
• Linq
• IEnumerator/IEnumerable
• Named Optional paramaters. Oh, and Params.
• Nullables
• Generics

I don't declare delegates often, but I do like mucking around with them on occasion:

Code (csharp):

1.  
2. delegate _ _();
3. _ _ = null; _ = () => _;
4.  
5. _()()()()()()()()()()()()()()()()()();
6.  

 

Thanks for the link Cripple ;-)

Delegate are slow ? Meh, I'm confused, I read the exact opposite on Stackoverflow ? They were benchmarking Virtual/Override vs delegates, and results showed same perf ?
edit : here it is : http://stackoverflow.com/questions/2082735/performance-of-calling-delegates-vs-methods
Most voted answer benchmarks delegates as faster than interfaces.

 

I spent the week end converting all my virtual/overriden core methods to delegate, so I now got a clear look about the difference (saved 2 different repositories so I can compare). As an information, there were a lot of override calls in my system mechanics.
And it seems I gained 0.1 - 0.2ms frametime (which is a lot, as I was at 1.0ms already, so it's 10%-20% increase).

I don't really have the time to do proper metrics, so yeah it's kind of statistics put out of my ass right now. But I feel it's very slightly faster. It might also have to do with having a few enums to test with override method that I don't have to test now, but enums are supposed to be cheap, so ..
Anyway the big gain is that now I can add pretty every kind of new behaviour into just every input of my state machine, which is huge improvement
(think "very specific combat rules", "complex conditional behaviours", "extensions to core fight mechanics", etc)

This was worth the 2 days of work.

 

Delegates and especially Events are the reason while I dropped C++ like a hot potato when C# first became available - I LOVE C#, haven't programmed in C++ since.


The fact that Unity supported C# was a tick off the FIRST checklist item on my game engine list!


-Will

 

do you think you can share a small sample of the way these functions actually work together, I understand delegates on a theoretical level but havn't seen any good REAL examples.

 

set the event = null, and all the delegates go away.

 

Currently I am developing an editor tool so you can assign delegate members from the inspector.

So basically if you have this..

Code (csharp):

1. [System.Serializable]
2. public delegate IEnumeartor Routine();
3.  
4. public class Mono : MonoBehaviour {
5.     public Routine onStart, onExit;
6.  
7.     public IEnumeartor R1() { ... }
8.     public IEnumeartor R2() { ... }
9.     public IEnumeartor R3() { ... }
10.  
11.      void IEnumeartor Start() {
12.          yield return StartCoroutine(onStart);
13.          yield return StartCoroutine(onExit);
14.      }
15. }
16.  

Then a drop down with [R1, R2, R3] will be available for onStart and onExit fields. It works amazingly well and I am going to write a visual scriptor like PlayMaker but with delegates in place of Action objects.

 

cool, but just out of curiosity, any reason you made your delegate an IEnumerator? Do you have void working too?

 

Were you doing this just for speed?

It's not the kind of thing I'd do, because while both can often be used to implement the same functionality in different ways, design wise they're intended for different things and I'd rather not fight against my tools.

 

At first it was for speed
But soon I realized the superior convenience of delegate composing ! Being able to add / substract a whole chain of behaviors on-the-fly is incredibly fit to video games mechanics. It's an incredible tool.

Sounds powerful !

 

That's a really bad call for delegates imho, it's well documented and saying "we'll make something else so users don't shoot themselves in the foot" means you're actually making it likely anyone who knows C# will shoot itself in the foot.
Also begginers should swarm their programs with LINQ and foreach, and at equal level, people won't produce faster code without linq that with it, quite the other way around, same for foreach except for the bad GC, but it's certainly not to take as a rule of thumb, people should use foreach everytime they actually semantically want to foreach, and then optimise later when (if!) needed. My take on this is:
- Either you're begginer level and you should use foreach
- Or you're advanced enough to care and you should still use foreach, wrapping the enumerator so that it doesn't leak !-_-!

 

Fun thing about delegates.
Few days ago I got feedback from one of my customers, he describe why he choose my system insted standart delegate. (I will not post a url, because advertising is not purpose of this post)

So here is his problem:

All code in dll. When he uses delegates from dll, everything working in editor and IOS simulator. But delegates not working on devise.
Every time when hi try to dispatch event hi got:

Code (csharp):

1.  
2. ExecutionEngineException: Attempting to JIT compile method '(wrapper managed-to-native) System.Threading.Interlocked:CompareExchange
3.  

Point is that when you have code inside dll like

Code (csharp):

1.  OnMouseUpClick += method;  

You will get error when you will try to dispatch OnMouseUpClick;

Everything great if you use:

Code (csharp):

1.  OnMouseUpClick = method;  

And my system also work well because I use HashTable to store delegates.

But it just funny, that

Code (csharp):

1.  OnMouseUpClick += method;  

will not work on IOS if it's inside dll.

 

This sounds like a bug unless you're somehow instantiating a non multicast delegate, but by the name it sounds like an event so that shouldn't be the case?

 

Here is full code listing. And it's giving exception on event dispatch, tested on (iPhone4, iPhone4s, IPad2, IPad mini)


This is "DelegateButton.cs" - with will work from dll

Code (csharp):

1.  
2. using UnityEngine;
3. using System.Collections;
4.  
5. public class DelegateButton : MonoBehaviour {
6.  
7.     public delegate void MouseUpClickHeadler();
8.     public event MouseUpClickHeadler OnMouseUpClick;
9.    
10.     public float w = 150;
11.     public float h = 50;
12.    
13.     void OnGUI() {
14.         Rect buttonRect =  new Rect((Screen.width - w) / 2, (Screen.height - h) / 2 - 150, w, h);
15.         if(GUI.Button(buttonRect, "click me delegates")) {
16.  
17.             if(OnMouseUpClick != null) {
18.                 OnMouseUpClick();
19.             }
20.         }
21.     }
22.  
23.  
24. }
25.  

And this is "ExampleListner.cs" witch should be simply in our Asset folder and attached to a Main Camera in a empty scene

Code (csharp):

1.  
2. using UnityEngine;
3. using System.Collections;
4.  
5. public class ExampleListner : MonoBehaviour {
6.    
7.     public GUIStyle style;
8.    
9.     private string label = "Click's: ";
10.     private int count = 0;
11.    
12.  
13.     void Start () {
14.  
15.         DelegateButton db = gameObject.AddComponent<DelegateButton>();
16.         db.OnMouseUpClick += onButtonClick;
17.     }
18.    
19.    
20.     private void onButtonClick() {
21.         count++;
22.     }
23.  
24.    
25.     void OnGUI() {
26.         GUI.Label(new Rect(0, 0, 200, 100), label + count.ToString(), style);
27.     }
28.    
29. }
30.  
31.  

This is defiantly bug.
But it is very difficult to say what is the cause) Unity? IOS? AOT compiler?
The exception will appear only on device. (In IOS Simulator or Unity Editor this code will work just fine)

 

C# is an awesome language. I chalk it up to a couple of things:

1. Snobbery. I used to work with a C++ guy, and as far as he was concerned, if you weren't using C++, you were a kid pretending to program with a kiddie programming language. I think this is very common (to lesser degrees).
2. MS bandwagon hate. Granted, lately MS seems to be doing everything they can to make themselves look rotten. But their development tools are the best, imo. Their OS...is there a more versatile OS on the planet, that supports the amount of hardware and software thrown at it? Not to mention, it is THE biggest gaming platform ever.
3. Ignorance

 

Note: In my previous job, I happened upon the following material by accident. When I asked my superiors about it, they knew nothing themselves, so I wound up creating a presentation on it. My knowledge since then has matured, as I've used it a bit more in my own game projects, so the material in this post will be a bit better than that presentation. But, it's still a wall of text. Worse, there is no TL;DR version. So, if text scares you, either A) don't read it, or B) don't read it all at once.

Time for you to level up again Mr. Lv.33 Developer!

LINQ/Lambda expressions are the next step upwards from this point.

Code (csharp):

1. using System.Linq;
2.  
3. // ...Boilerplate here...
4.  
5. public long Fibonacci(long x)
6. {
7.   // Note: this is the version compatible with Visual Studio.  In Mono, you can combine this into a single line.
8.   Func<long, long> fib = null;
9.   fib = n => (n < 2) ? n : fib(n-2) + fib(n-1);
10.  
11.   return fib(x);
12. }

This single method finds the fibonacci number for a given index, using a function delegate. In .NET 3, two additional 'delegate' types were introduced: Actions, which act similarly to SUBs in BASIC languages (e.g. a function with return type of void), as such:

Code (csharp):

1. Action<int, int> foo = (a, b) => Debug.Log("Sum: " + (a + b));

The generics for an action denote the types of the arguments.

Similarly, Funcs are similar to the BASIC FUNCTIONs - they return some result, as seen above. In the case of a Func, the final type given is the output type; all preceding types are argument types:

Code (csharp):

1. Func<int, int, int> foo = (a, b) => a + b;

This is important for when you are using LINQ, which is a framework that provides brief ways of working with IEnumerable types. While it is little more than syntactical sugar, it helps. Imagine you have a foreach as such:

Code (csharp):

1. SomeBehavior desiredBehavior = null;
2. SomeBehavior[] behaviors = GetComponents<SomeBehavior>();
3. foreach(SomeBehavior behavior in behaviors)
4. {
5.   if(behavior.SomeProperty == true)
6.   {
7.     desiredBehavior = behavior;
8.     break;
9.   }
10. }
11.  
12. return desiredBehavior;

In that code, we're looking for a behavior in a series of behaviors with some property that matches a desired value. But, look at all that ugly code! LINQ gives us a better way to write that:

Code (csharp):

1. SomeBehavior[] behaviors = GetComponents<SomeBehavior>();
2. SomeBehavior desiredBehavior = behaviors.FirstOrDefault(b => b.SomeProperty == true);
3. return desiredBehavior;

Note: You see the .FirstOrDefault() method call? Don't check for null! The reason is that under certain circumstances, not everything is by default null! You would perform a check against default([Your Type Here]) to determine if a default object was returned.

The way most LINQ methods work, is they conceal a foreach loop against an IEnumerable. The lambda expression is used as a filtering condition. Thus, while behind the scenes that nasty foreach is still happening, it's not cluttering up your code.

I highly recommend researching this aspect of C#, especially for your Unity creations; recently, I was able to use LINQ and the .NET 3 delegate types to build a pretty nice state machine I'm using for AI in my current project, in less than 100 lines of code (much of that being language boilerplate.) With learning delegates you took your first step into a larger world - now, keep going!

Note: Given that C# memory leaks were brought up earlier in the topic, these delegate types behave like other delegates if bound to events - you must clean them up to prevent a memory leak. The Actions and Funcs are nice because you can declare what amounts to a temporary function that gets GC'd when a function goes out of scope, unless the function is being returned, as in the scenario of creating a C# closure:

Code (csharp):

1. public Action MyClosure(int parameter)
2. {
3.   int someBoundary = parameter - 1;
4.   int anotherBoundary = parameter + 1;
5.  
6.   return () => {
7.     Debug.Log(String.Format("Parameters: [{0},{1},{2}]", someBoundary, parameter, anotherBoundary));
8.     _somePrivateField += parameter;
9.   };
10. }

The Action returned will keep the reference to someBoundary and anotherBoundary around until the action is no longer referenced, and thus GC'd. Just another cool, but advanced, and rather uncommon thing you can do with the .NET 3 delegate types.

 

Hey, come back to check C++11, which includes function/bind in std now

 

This has nothing to do with delegates specifically... what you've described is the bad side of being a bad programmer. You can hold references in any number of ways.

And I love this thread. The entire Unity API would be a million times better if it used delegates and events instead being designed for people who for some reason are writing code but can't handle the += and -= operators and dirtying / race-conditioning everything up with all the handholding of the completely misnamed reflection "callbacks".

Edit: Whoa, necro. Still a good thread.

So, umm... it's been 17 months and there's still no sign of the "artists writing bad code friendly" event system. Maybe you guys should just focus on clean, allocation free programming APIs designed for programmers instead of artists.

 

Doesn't need to use events and the registering / unregistering syntax, can just use raw delegates and have them passed into methods for subscribtion have unity manage them so bad end user isn't even an excuse.

 

I cannot agree more.

I have worked in the games industry for about 15 years now. 13 of those years was spent as an artist in various senior roles. When I started my own games company I had to learn how to code from scratch. Even though I'm a great example of the artist-turned-coder I can't stand UT's attempts to "baby" beginner coders by building inefficient systems that encourage bad practices.

The best way to help an artist learn how to code is providing an API that encourages and rewards good code.

 

What's too bad is that pretty much all of .net is well designed and easy to use, so since you kinda have to learn .net APIs anyway to be proficient in unity it doesn't even saveup learning time it's just a bad tradeoff, you give away something get nothing in return.

 

Well, you should learn some .NET, but plenty of people don't even realise it's there to be learned about.

Check out the scripting section, for instance, and see the almost weekly threads about saving complex data using PlayerPrefs instead of using any of the many options available to you through the .NET/Mono standard library. People tell me they avoid it because it doesn't work reliably cross-platform, but while it does have its niggles if that were the case generally speaking then most of the code I wrote wouldn't work most of the time, so I really don't buy it. (And all of the niggles I've found were in places that, understanding how computers/operating systems work, it was pretty obvious for me to think "I should check if this works differently on a mobile device".)

I'm also no fan of the automatic reflection-based callbacks. And I'd love events (or something) for the things that I sometimes find myself polling and yet which I expect to change only rarely... it always makes me feel dirty. Though in some cases adding the event in the back-end might make performance suffer far more than my polling does. (Eg: I'd love to have an event on transforms that tells me when they're modified or that they became dirty some time in the current frame, but I understand that could potentially trash internal optimisations.)

 

I switched from C++ to C#! Im having so much fun with it! Im not gonna try UnityScript because I feel like it isn't as fun. The way you declare variables bother me so much! I cannot stand the 'var' type! I CANT! Its not so hard to just put in a specific type. It bothers me so much and having to declare variables like 'var something : GameObject' is annoying to me.

 

You'll come back to loving var... with type inference.

At this point I can't stand specifying types (and generic parameters) for fields...

Of course, I use a helluvalot of generics.

 

It's not good practice

 

The common idiom is to use var where the type can be inferred from the remainder of the code line.

e.g

var _myController = GetComponent<CharacterController>();

Which is a common use case and doesn't hurt readability. One could argue it helps readability because it is less verbose. It also helps to make sure your variable names are well thought out. For that you want to be more verbose than most people tend to be.

At least that's been my experience.

 

It's very good practice, don't come from another language with another mindset try to apply it to a new language you learn. In C#, it's perfectly fine practice, var is as strongly typed as specifying the type, and much more readable.

 

This phrase just made my morning.

P.s> It's really good to get both the positive and warning posts (from N0mad and Tim-C) on this topic.