1. Extensible - The code is capable of being expanded for future growth.
2. Properly Engineered - Code should match the job. Overengineering doesn't help anyone if the project doesn't call for it. Overly verbose code ends up destroying agility, which hinders the programmer's ability to solve a problem quickly.
3. Efficiency - The fastest processing code with the smallest amount of lines of code is the name of the game. It's the programmer's dilemma, and it's one of the reasons I love programming.
There's probably more nuances in good code, but I think that the above 3 characteristics describe good code, and lack of the above characteristics describe bad code.
Delegates are one concept in code that gets at all 3 of the above characteristics. A delegate is not all that easy to explain, but I'll do my best, given my experience with them, and the value I find in them, at a practical level.
A delegate can do many things, but the first thing that all the tutorials talk about with the application of delegates is to "Encapsulate a method." In a nutshell, that means delegates provide another form of abstraction. Below is an example:
delegate void GenericMessage(string message);
///Notice that this method is type void
///just like the delegate. Also has the
///same parameter types as the delegate
private void realMessageWriter(string theMessage)
///The entry method for this class
public void Entry()
///Notice variable _Message is of type
///GenericMessage - which is the delegate
///Similar functionality could be done
///with an abstract class or an interface
GenericMessage _Message = realMessageWriter;
This is a very simple code example, but I think it demonstrates the point, that delegates provide a way to hide a method, as long as the method shares a similar "fingerprint" as the delegate. In the above example, the method that is being hidden (realMessageWriter()) is of type VOID, and accepts a string parameter.
This is the foundation of a delegate. There is a curve ball that delegates present, when you take into account that they are the foundation for events, which could allow you to fire code in the event that something happens without proactively coding for that scenario after each iteration of some action, but I think that falls into Delegates Part 2.