We pay for user submitted tutorials and articles that we publish. Anyone can send in a contributionLearn More
This is part B of the 10 Ways To Programaticly Shoot Yourself In The Foot article. As I already stated in part A, there are several things a software developer can do to make his life much more difficult in the future. In this article I will talk about another 5 issues that even the best developers have to be aware of. In other words, I will try to prevent you from programaticly shooting yourself in the foot.
There are four access modifiers: public, protected, internal and private. Don’t use public everywhere you can! Choose the correct access modifier! Did you try to use a library where all of the classes and all of their methods and properties are public? Believe me, you won’t be able to understand its usage and you will become very confused. I don’t want to get a list of 20 methods while only 2 of them shall interest me. There is another, stronger reason to use the correct access modifier: encapsulating classes and methods not only ensures that they don’t clutter up the rest of your code, it also ensures that the rest of your code doesn’t interfere with them. The main purpose of using access modifiers are providing security to the applications. When you want to create an assembly that can be used by various people in various applications, you want to restrict its usage to what it was meant for. If everything is exposed as public, your code will not be used properly and will probably crash. You don’t want to think about every usage scenario, it is much safer to expose the minimal set of functionality because there will be much less space for mistakes.
It is that simple, don’t implement it by yourself, check if others have done it before. Don’t ignore existing solutions and invent your own! Nowadays, existing solutions can be found easily, The Internet and especially Google offers a very easy way to find everything you need. The chances are that those existing solutions are much better than your invented solution because they have been tested by many others and sometimes there is a very large community supporting them. Besides that, it will be a waste of time to do what is already done. I am talking about small methods or classes and even large libraries which can be reused, they will probably be more powerful and stable than your own solution. I want to share a very annoying “reinventing the wheel” issue, I ran into in my last job. Computer Graphics was reinvented and instead of using well known and honored libraries like OpenGL or DirectX, they created their own library based on drawing with WinAPI, not utilizing the graphics card capabilities at all. Now, when they encounter a problem, it is unique and they can’t find common solutions in the Internet. This is how to programaticly shoot yourself in the foot!
If you want to bridge the gap between your managed code (C#, for example) and your unmanaged code (C++, for example), you can use various techniques. One of them is creating a managed C++ layer where you can use both, the managed and unmanaged code. The C# code can call the C++ layer through the managed C++ layer. This layer shall not include any logics at all, it shall only function as a link between the two worlds. If you add logics to this layer, it might contain some bugs and because nobody really write applications with managed C++, you won’t be able to find others who faced the same problems as you do. As a Microsoft consultant told me once: “Nobody at Microsoft thought that someone might use the managed C++ layer for more than just a bridge between managed and unmanaged code”.
Read my Call Virtual Functions From Constructor? article. Here is a summary:
If you call a virtual method from the base class constructor, the overridden method is called. But notice that when that overridden method is called, the derived class is not initialized because its constructor code was not executed yet. So, we are calling a method of an un-initialized instance…
Be aware of this matter because it is not a trivial issue and apparently, there are no errors or warnings generated by the compiler. So, the rule to remember is to never call virtual methods from constructors. Now, go and check your code, is there a possibility that you violated this rule?
I know that it might be very annoying to comment our code, it is slowing us down. We have to understand that this slow down is for the short term, how can somebody use our code if there is no hint of how to use it? Do you really think that I can know every detail about the expected method parameters just by reading their names? Using an undocumented code is the easy part, assume you need to take responsibility for it. It is a nightmare, it becomes an investigation mission to understand what’s going on. Please don’t tell me that a well written code should not be documented because the code “speaks for himself”. When I enter a class code, I want to know its responsibility by reading its comment, I don’t have time to start reading 500-1500 lines of code to just get the idea. Why not documenting your code is shooting yourself in the foot, you ask? because when others read your undocumented code they get nervous and angry that they can’t understand what you did, your reputation will be ruined and you don’t want that to happen. Here is a more strong phrase: “Always write and document your code as if the man that is going to maintain it is a serial killer who knows where you live.“
That is it, I am very curios about your opinions and can’t wait to hear about them. And please, don’t programaticly shoot yourself in the foot, it hurts…
Tags :.Netaccess modifiersbugsC#documentmanagedPrivateproblemsPublic
Copyright © 2012 Dev102.com
Breeze : Designed by Amit Raz and Nitzan Kupererd