Use of Syntactic Sugar / Built in Functionality

I was busy looking deeper into things like multi-threading and deadlocking etc. The book is aimed at both pseudo-code a开发者_开发技巧nd C code and I was busy looking at implementations for things such as Mutex locks and Monitors.

This brought to mind the following; in C# and in fact .NET we have a lot of syntactic sugar for doing things. For instance (.NET 3.5):

lock(obj)
{
   body
}

Is identical to:

var temp = obj;

Monitor.Enter(temp);

try 
{ 
   body 
}
finally 
{ 
   Monitor.Exit(temp); 
}

There are other examples of course, such as the using() {} construct etc. My question is when is it more applicable to "go it alone" and literally code things oneself than to use the "syntactic sugar" in the language? Should one ever use their own ways rather than those of people who are more experienced in the language you're coding in?

I recall having to not use a Process object in a using block to help with some multi-threaded issues and infinite looping before. I still feel dirty for not having the using construct in there.

Thanks,

Kyle

Stick to the syntactic sugar as much as possible. It's concise, more maintainable, less error-prone, well understood, and they created it for a reason.

If you must have manual control over something (e.g. manipulating an IEnumerator<T> instead of using foreach), then yes, ditch the syntactic sugar. Otherwise, being idiomatic is a good thing.

The biggest cost of software development is maintenance over the long term, so the answer is always, do the thing that will give you the easiest and most cost effective maintenance path (with all the exceptions that might prove the rule, perf for example). If you can use syntactical sugar to make your code more readable then that's your answer if the syntactical sugar gets in the way then don't use it.

In C#, this linq statement:

var filteredCities =
    from city in cities
    where city.StartsWith("L") && city.Length < 15
    orderby city
    select city;

is syntactic sugar for (and equivalent to):

var filteredCities =
  cities.Where(c => c.StartsWith("L") && c.Length < 15))
    .OrderBy(c => c)
    .Select(c => c); 

If you know C# well, the latter version is far easier to pick apart than the former; you can see exactly what it is doing under the hood.

However, for typical everyday use, most people find the sugared version cleaner to look at, and easier to read.

Your example of not being able to use a using construct is my most common deviation from the new approaches made available in .Net languages and the framework. There are just a lot of cases where the scope of an IDisposable object is a bit outside of a single function.

However, knowing about what these shortcuts do is still as important as ever. I do think many people simply won't dispose an object if they can't wrap it in a using, because they don't understand what it does and what it's making easier.

So I do wish there was something like a tooltip helptext for some of these wonderful shortcuts, that indicated something important is happening - maybe even a different keyword coloring.

Edit:

I've been thinking about this, and I've decided that I believe using is just a misleading keyword to have chosen. foreach does exactly what it sounds like, whereas using doesn't imply, to me, what's actually going on. Anybody have any thoughts on this? What if they keyword had been disposing instead; do you think it'd be any clearer?