Web Dev Bros » programming style http://www.webdevbros.net hot talk about web development Thu, 20 Jan 2011 19:55:06 +0000 en hourly 1 http://wordpress.org/?v=3.0.1 Testing code changes, bugfixes, new features, … http://www.webdevbros.net/2009/08/20/testing-a-change-bugfix-implemented-feature-%e2%80%a6/ http://www.webdevbros.net/2009/08/20/testing-a-change-bugfix-implemented-feature-%e2%80%a6/#comments Wed, 19 Aug 2009 23:00:52 +0000 Michal http://fabiankoehler.de/wdb/?p=14 When you implement a new feature somewhere, when you change just some bits of your code, when you fix a bug, or you just change a common text in an app… What do you do afterwards? Do you really check the result or do you trust yourself that it works fine 100%. It is an interesting thing to talk about…

I have to be honest and admit that I trusted myself a lot of times in the early days and at least 2 of 10 times I was wrong. If you deal with customers then it’s two times too much. Especially when you have that guy on the phone and you claim that you did change it, but he is browsing the application and does not see any changes. In that case you’re really pissed because you haven’t spent one minute to check the result/consequence of your change.

So that’s why I always suggest to check EVERYTHING that has been changed. You never know what you forget, but when you get sure that you see the change yourself then you’re on the safe side. Here is a list what you could not have thought about:

  • you have been working in the wrong file. The file you have been working on was just a backup, in the wrong location, wrong server, etc. Such things happen everyday.
  • you forgot to refresh/restart some service, application, etc.
  • forgot to publish the file. This is common but i am sure it happens as well. For instance you forgot to upload the file on the server if its a web app.
  • forgot to compile. for all out there who need to do this.
  • last but not least programing failures which you haven’t thought about (especially when you are changing code of others you should 100% check the effect of the change even if it’s just a typo): you changed the wrong part of the code. Happens usually when there are duplicate pieces of code, which in turn happens because of bad programming style (think of the DRY principle).

Hence it’s highly recommended to check EVERY change. You save yourself and others a lot of troubles and iterations of changing and testing. Personally I think that this is a programmers quality characteristic and that it’s not a tall order to expect a check of the change. In most cases it’s less than a minute. Don’t get lazy …. For sure everybody does, but be aware of all the points I mentioned above.

]]> http://www.webdevbros.net/2009/08/20/testing-a-change-bugfix-implemented-feature-%e2%80%a6/feed/ 2 Service vs. Component http://www.webdevbros.net/2009/07/14/service-vs-component/ http://www.webdevbros.net/2009/07/14/service-vs-component/#comments Tue, 14 Jul 2009 06:05:57 +0000 Michal http://www.webdevbros.net/?p=374 I was having trouble to differentiate between both nor could I 100% explain to someone what’s the real difference between a Service and a Component. Today I’ve found a really nice definition by Martin Fowler which I would like to share with you:

Component

I use component to mean a glob of software that’s intended to be used, without change, by application that is out of the control of the writers of the component. By ‘without change’ I mean that the using application doesn’t change the source code of the components, although they may alter the component’s behavior by extending it in ways allowed by the component writers. – Martin Fowler, Inversion of Control Containers and the Dependency Injection pattern

Service

A service is similar to a component in that it’s used by foreign applications. The main difference is that I expect a component to be used locally (think jar file, assembly, dll, or a source import). A service will be used remotely through some remote interface, either synchronous or asynchronous (eg web service, messaging system, RPC, or socket.) – Martin Fowler, Inversion of Control Containers and the Dependency Injection pattern

]]> http://www.webdevbros.net/2009/07/14/service-vs-component/feed/ 2 C# tips, tricks and things you should know http://www.webdevbros.net/2007/11/14/c-tips-tricks-and-things-you-should-know/ http://www.webdevbros.net/2007/11/14/c-tips-tricks-and-things-you-should-know/#comments Wed, 14 Nov 2007 11:33:25 +0000 Michal http://www.webdevbros.net/2007/11/14/c-tips-tricks-and-things-you-should-know/ .net components During my previous holidays (i have to admit 1.5 months surfing in portugal) I had some literature with me which also included the book Programming .net components released with O'Reilly. It talks about the aspects of components in general and provides good examples how to achieve those in .net. Although these pages are a very good read (rather for experienced devs) for ppl interested in component development, I found it more interesting because of its general C# content. There are concepts & approaches, small tips & tricks and intersting things about C# which can be used not only in component based architectures and are therefore good to know anyway.

As I always make notes while reading "geek" books I thought: "so why not summarize them all up in a nice list and blog'em". Here we go...

1. implicit vs explicit interface
implicit interface implementation allows to use the interface member through an object or through the interface whereas the explicit interface implementation allows only access through the interface.

PLAIN TEXT
C#:
  1. //public interface IInterface {
  2.    void Foo();
  3. }
  4. //implicit implementation
  5. public AClass : IInterface {
  6.    public void Foo() { }
  7. }
  8. //explicit implementation
  9. public BClass : IInterface {
  10.    void IInterface.Foo() { }
  11. }
  12. //usage implicit
  13. AClass a = new AClass();
  14. a.Foo();
  15. IInterface b = new AClass();
  16. b.Foo();
  17. //usage explicit
  18. IInterface c = new BClass();
  19. c.Foo();
  20. BClass d = new BClass();
  21. d.Foo() //Fails because of explicit implementation!!!

Visual studio just offers the choice of the implementation but most people don't know the difference. With explicit implementation the server (implementing the interface) can prevent clients from using it directly on object which implements it. It forces that the members of the interfaces are only accessible via the interface itself

2. implicit vs explicit cast
this is just to get used to the terminology because a lot of guys are using it but don't know the terminology ;)

PLAIN TEXT
C#:
  1. //implicit cast
  2. T x = new T
  3. //explicit cast
  4. T x = (T)y
  5. //explicit cast (defensive)
  6. T x = y as T

Here you see that implicit casting is assigning a class instance directly to a variable. Explicit means casting from one type to another.

3. Destructors
A destructor of a class is defined with ~ClassName. In comparison to Dispose() the C# destructor is always called. Dispose() needs to be called by the client whereas the destructor is called when the garbage collector comes around. Best way is to implement both and channel the implementation to the method which does the cleanup. e.g. cleanup. Example of implementation [COMP05, 98]:

PLAIN TEXT
C#:
  1. public class MyBase : IDisposable {
  2.    private bool _disposed = false;
  3.    protected bool Disposed {
  4.       get {
  5.          lock(this) {
  6.             return _disposed;
  7.          }
  8.       }
  9.    }
  10.    public void Dispose() {
  11.       lock(this) {
  12.          if (!_disposed) {
  13.             CleanUp();
  14.             _disposed = true;
  15.             GC.SuppressFinalize(this);
  16.          }
  17.       }
  18.    }
  19.    //the method for the subclasses if they need to release resources
  20.    protected virtual void CleanUp() { }
  21.    ~MyBase{
  22.       CleanUp();
  23.    }
  24. }

Classes deriving from this baseclass can now implement their destruction by overriding the cleanup method and can now decide to do the clean up manually (calling Dispose) or leave it till the GC comes around. Important here is that if Dispose() was called we tell the garbage collector to exclude this instance from being garbaged later (with GC.SuppressFinalize()).

4. use "Using" defensive

PLAIN TEXT
C#:
  1. using (obj as IDisposable) {
  2. }

This approach will only call Dispose() if the object implements IDisposeable. Good if you dont really know if the object needs to release resources or not and if you want to be ready for future changes. e.g. the server decides to implement IDisposeable.

5. Delegate inference

PLAIN TEXT
C#:
  1. //instead
  2. publisher.someDelegate += new Delegate(someMethod)
  3. //u can use
  4. publisher.someDelegate += someMethod

This is much nicer to read but only supported with .net 2.0.

6. Custom event arguments
Custom event arguments (own class derrived from EventArgs) should have only readonly members. This prevents the client from changing the values. Readonly members can only be assigned in the constructor so the publisher of the event is able to set the values when creating the arguments.

7. Always fire events in a try catch block
You never know what the event handler method of the client does, so its good to put the firing into a try catch block. You could write your own EventsHelper class [COMP05, 144] for the purpose of firing event within your classes.

PLAIN TEXT
C#:
  1. public static class EventsHelper {
  2.    public static void Fire(Delegate d, params object[] args) {
  3.       if (d == null) return;
  4.       Delegate[] dels = d.GetInvocationList();
  5.       foreach(Delegate sind in dels) {
  6.          try {
  7.             sink.DynamicInvoke(args);
  8.          } catch {}
  9.       }
  10.    }
  11. }

8. use "property-like" approach for event accessors
As you do with common member variables (expressing them with properties) you also should do this with events. This alows you to control the adding and removing of event handlers for your event.

PLAIN TEXT
C#:
  1. public class MyClass {
  2.    MyHandler _myEvent;
  3.    public event MyHandler MyEvent {
  4.       add {
  5.          _myEvent += value;
  6.       }
  7.       remove {
  8.          _myEvent -= value;
  9.       }
  10.    }
  11. }

9. Static objects as keys

PLAIN TEXT
C#:
  1. static name = new Object();
  2. myCollection[name] = "a name"
  3. //instead of (old school)
  4. myCollection["name"] = "a name"

a static object is created to act as a key for e.g. collections (because every instance is unique - has its own identity!). The advantage in comparison to the "old school" version (key is a string) is that the key is already available in memory wheras the string needs to be created everytime. If you use this key in a lot of places it could save some time.

10. Combine enumeration values

PLAIN TEXT
C#:
  1. public enum color {
  2.    red,
  3.    green,
  4.    all = red | green
  5. }

This example illustrates that it is possible to have enumeration values which accept more than one existing values of the current enumeration.

11. Singelton Application
A singelton application is one which only allows running one instance per machine. e.g. Microsoft Outlook is a singelton application. Everytime the user starts the application it will check if an instance is already running. If its not running it will launch it otherwise it will focus to the current one. The source for an application which runs only once is available in another post "Singelton Application with C#"

12. Containment
If it is not possible to derive from a class we use a class to wrap around the class we would like to inherit from. This procedure is also known as "Containment" (I mention it here because the this term is more unknown - usually developers use wrapper)

13. Use Debug.Assert()
The use of Debug.Assert should be used as often as possible. During the development the developer should "assert" things which always should be true. This helps finding bugs easier and its easier for other developers to understand the code.

PLAIN TEXT
C#:
  1. int a = 10
  2. int b = 20
  3. int c = 20 - 10
  4. Debug.Assert(c> 0, "i need it bigger than 0. check might be done in the future")
  5. Console.WriteLine(10 / c)

This short example demonstrates that obviously the developer expects the variable "c" to be greater than 0. Why? Because in the next line he/she uses it for a dvision which would break with c = 0. If this is the case you would get an information seen in line 4. This concept is nice because it makes comments "active".

14. user string instead of String
String is just an alias for string and therefore its nicer to use the original type straight away. The same with int and Int32, etc.

15. Rethrowing exceptions

PLAIN TEXT
C#:
  1. try {
  2. } catch(Exception e) {
  3.    //some logging,etc...
  4.    throw;
  5. }

This piece of code rethrows the exception. The interesting thing here is that you dont need to specify the Exception explicitly. Just the keyword "throw" is enough to rethrow the exception.

15. Code exclusion with attributes and not with #if .. #endif

PLAIN TEXT
C#:
  1. [Conditional("DEBUG")]
  2. void Foo() {
  3. }

The advantage here is that the code is not reachable anymore if the condition is not met. This means that it will result in compile errors if you reference this method. #if ... #endif does not enforce this constraint. Its also nicer than the hash signs ;) Please check the MSDN Reference for more details about the conditional attribute.

Thats was it :) Hope there was something interesting and maybe new for everyone. I dont want to promote the book here but I really recommend it because it contains good content about programming with c# (and especially for component development) and should be read by every C# developer who wants to develop for enterprise.

Maybe you have some interesting tips & tricks which might be useful for others. Please be so nice and comment them... I am interested.

Resources:
[COMP05] .net Components, Juval Löwy, O'Reilly 2005 United States

]]> http://www.webdevbros.net/2007/11/14/c-tips-tricks-and-things-you-should-know/feed/ 6