Since the release of the .Net Framework 2.0 the amount of code I've had to write when building utility functions has diminished greatly. There is only one thing I enjoy more than writing code, and that is deleting code. :) I get to do that a lot nowadays especially when working on legacy .Net Framework 1.0/1.1 projects.
Take a look below and see how I've managed to reduce two functions which are screen specific to one.
// Duplicated in GetFormAInstance
public static screens.FormB GetFormBInstance(string key, out bool alreadyExists)
{
screens.FormB form = Controller.GetRegister.Get(key) as screens.FormB;
if (form == null)
{
alreadyExists = false;
form = new screens.FormB();
Controller.GetRegister.Register(key, form);
}
else
{
alreadyExists = true;
form.BringToFront();
}
return form;
}
// Duplicated in GetFormBInstance
public static screens.FormA GetFormAInstance(string key, out bool alreadyExists)
{
screens.FormA form = Controller.GetRegister.Get(key) as screens.FormA;
if (form == null)
{
alreadyExists = false;
form = new screens.FormA();
Controller.GetRegister.Register(key, form);
}
else
{
alreadyExists = true;
form.BringToFront();
}
return form;
}
// Function which uses generics to encapsulate GetFormAInstance and GetFormBInstance
public static T GetFormInstance<T>(string key, out bool alreadyExists) where T : Form, new()
{
T form = Controller.GetRegister.Get(key) as T;
if (form == null)
{
alreadyExists = false;
form = new T();
Controller.GetRegister.Register(key, form);
}
else
{
alreadyExists = true;
form.BringToFront();
}
return form;
}
As you can see I am using the ability to define constraints on Type parameters to indicate that the Type returned from GetFormInstance will support the new() constraint and the type will derive from the Form class. If I had not supplied this constraint information the compiler would have have complained about the "form = new T();" line and given me the following error : "Cannot create an instance of the variable type 'T' because it does not have the new() constraint".
Being a programmer, there are a few things that are extremely important to me with regards to the qualities my manager should have.One of the most important characteristics should be the way in which information or instructions are supplied to me.
I like to have:
1) The information I need before I start working on a task. I want to have to ask as few questions as possible during the development process.
Types of questions I would like to avoid are:
1) What is the project code for this project so I can book time to it?
2) How would you like me to implement the functionality requested in the UI?
UI development is always a pain if the specification is unclear or non-existent because everybody has there own opinion on the best way to implement the look/feel of a set of features which will satisfy the business requirements. Normally there are many roads through a forest (i.e. choices to make) in software development, but within the UI sphere the no. of choices increase dramatically.
The key here is to minimize the no. of assumptions the developer is forced to make. The less assumptions the developer has to make, the less the developer has to worry whether he has made the right choice and the less risk there is that the way in which the software is satisfying the functionality requirement will be incorrect.
Guide to managing your habits:
1) The manager is not interested in how the business requirements are implemented as long as the time constraints allocated to satisfying them are met.
- This sort of attitude inevitable leads to developers creating hacks if the time constraints are to severe.
2) Management asking you questions that are not relevant to the current problem domain. This is always due to poor communication between the programmer and manager. A developer should always touch base with his manager at least once a day. Your manager pays your salary, so at least give him the respect of updating him on the project's progress once a day.
3) Always be 100% honest and thorough. Keep your manager informed of what your impediments are, no matter how much the manager doesn't want to hear. Management will only respect the developer for being honest and raising any project impediments early in the software development life cycle.
The message I am trying to put across here is always be pro-active in terms of providing information. Whether you are a manager or developer make sure your work colleagues have the information before the need it. This prevents them from having to come to you to ask for it and disturb your work rhythm. Developers of today are really required to be jack of all trades. And one of the most important trades include managing their managers.
Jean Hibbert