When working with code I prefer to use themes with a dark background as I find they’re easier on the eyes. I love Rob Conery’s TextMate Theme and I’ve used it as a basis for my own theme.
The Jystic Theme uses a dark blue background and different colours for classes, interfaces, structs, delegates and enums. In addition to C# highlighting, it also supports xaml, aspx and css.
C#
XAML
ASPX
CSS
The font I like to use is DejaVu Sans Mono.
Tagged with:
Share it:
I’ve been having quite a lot of success lately with WPF thanks to an awesome technique that allows the injection of a dummy ViewModel at design time. This allows you to tweak the view in Visual Studio or Blend and see changes right away!
Unfortunately, having to add a property in so many places (the real ViewModel, the dummy ViewModel and the interface) was becoming a bit of a drag. So, I streamlined the process a bit by using RhinoMocks to generate the dummy ViewModel as a stub of the ViewModel interface:
public class SampleViewModel : ISampleViewModel { // snip internal class DesignModeFactory : IDesignModeFactory<ISampleViewModel> { public ISampleViewModel CreateInstanceForDesignMode() { var viewModel = MockRepository.GenerateStub<ISampleViewModel>(); viewModel.Stub(x => x.Title).Return("Design time title"); viewModel.Text = "Design time text"; return viewModel; } } }
public interface ISampleViewModel { string Title { get; } string Text { get; set; } }
I really like this approach because it guarantees that everything I’m binding to in design mode is available on the interface. This is important to note, because WPF uses reflection for binding, so I would have been allowed to bind to properties not on the interface and I wouldn’t realise until runtime.
So, all that’s left now is to hook up the dummy ViewModel. It would probably be best to do this with an attached property, but for me there was a more pragmatic solution. All of my views already derive from a specialised UserControl, which has a strongly typed ViewModel property for use by IoC containers. Given this arrangement, it was more pratical for me to add the dummy as part of the existing system.
public class UserControlView<TViewModel> : UserControl { public TViewModel ViewModel { get { return (TViewModel)DataContext; } set { DataContext = value; } } public UserControlView() { if (DesignerProperties.GetIsInDesignMode(this)) { ViewModel = CreateDesignModeViewModel(); } } private static TViewModel CreateDesignModeViewModel() { IDesignModeFactory<TViewModel> factory = ResolveFactory(); if (factory == null) { return default(TViewModel); } return factory.CreateInstanceForDesignMode(); } private static IDesignModeFactory<TViewModel> ResolveFactory() { return Resolve<IDesignModeFactory<TViewModel>>(typeof(TViewModel).Assembly); } private static T Resolve<T>(Assembly assembly) { return assembly .GetTypes() .Where(x => typeof(T).IsAssignableFrom(x)) .Select(x => (T)Activator.CreateInstance(x)) .FirstOrDefault(); } }
public interface IDesignModeFactory<T> { T CreateInstanceForDesignMode(); }
As you can see in the code above, we’re searching for the ViewModel’s DesignModeFactory. If we find one, we use it to create an instance of our dummy ViewModel. In my case, because I was already deriving from UserControlView, I don’t have to do anything extra! But, in case you haven’t used generics with xaml before, here’s the basic xaml for the view, the important part is the x:TypeArguments property.
<Sample:UserControlView x:TypeArguments="Sample:ISampleViewModel" x:Class="Sample.SampleView" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:Sample="clr-namespace:Sample"> <!-- snip --> </Sample:UserControlView>
And there you have it, design mode support that’s a touch more DRY :)
Share it:
The area of my code that has changed the most with the introduction of linq and extension methods has to be the way that I treat standard collections. The number of times I used to write some code like this:
IEnumerable<Fruit> fruits = GetAllTheFruit(); List<Fruit> freshOnes = new List<Fruit>(); foreach (Fruit fruit in fruits) { if (fruit.IsFresh) { freshOnes.Add(fruit); } } MakeFruitSalad(freshOnes);
What a waste of time! The time it took to write all that boiler plate code, as well as the time for someone else to read and understand all that boiler plate code :( All we wanted was to get the fresh fruit, why is that so hard? Well, actually, with linq it’s pretty easy:
IEnumerable<Fruit> fruits = GetAllTheFruit(); IEnumerable<Fruit> freshOnes = fruits.Where(x => x.IsFresh); MakeFruitSalad(freshOnes);
How about sorting? I used to find myself doing something like this:
List<Fruit> sortedFruits = new List<Fruit>(GetAllTheFruit()); sortedFruits.Sort(new FreshnessComparer()); class FreshnessComparer : IComparer<Fruit> { public int Compare(Fruit x, Fruit y) { return x.Freshness.CompareTo(y.Freshness); } }
That’s great, but do I really need to make a new class/method just to sort by freshness? Not if I use linq:
IEnumerable<Fruit> sortedFruits = GetAllTheFruit().OrderBy(x => x.Freshness);
What if I just want the single freshest fruit? I could do this:
Fruit freshest = null; foreach (Fruit fruit in sortedFruits) { freshest = fruit; break; } // got the freshest, or null if there was no fruit in 'sortedFruits'
Or I can just use linq:
Fruit freshest = sortedFruits.FirstOrDefault();
Great, so it’s nicer to use from the consumer’s point of view, but what about the provider’s? This is another area where I really like linq. Linq works on IEnumerable<T>, a really simple interface to implement when compared to the likes of IList<T> or ICollection<T>. It really allows our implementations to choose the best data structure for the job, instead of having to return an IList<T> or ICollection<T> just because they’ll be more convieniant for the consumer.
Linq is proof enough for me that object oriented and functional programming paradigms can complement each other nicely. Not having access to functional stuff like linq is one of my major pain points anytime I have to use Java these days.
Share it:
Social