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.

  • Use The Wrong Access Modifiers 

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.

  • Reinventing The Wheel

 reinventthe wheel 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!

  • Insert Logic To Your Managed C++ Layer

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”.

  • Call Virtual Methods From Constructor

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?

  • Not Commenting Your Code

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 :

8 Responses to “10 Ways To Programaticly Shoot Yourself In The Foot – Part B”

  1. tab

    Said on November 25, 2008 :

    I certainly agree about commenting your code – I am more interested in what the code is supposed to accomplish as opposed to what it does.

    I also find a lot of resistance from my fellow developers when I suggest they comment code. They fall back on the agile pseudo-mantra that code is self documenting which is pretty much a load of crap in terms of the intent behind it – the code might be self documenting in terms of variables and method names, etc but the name cannot tell you the intent behind the lines of code and why you collated them that way.

    Just a thought…

  2. Veera

    Said on November 26, 2008 :

    Failing to add proper comments in code is a crime. :D

  3. James

    Said on November 26, 2008 :

    I would add “Be a generalist and never learn to fully exploit a language or technology.”

    Too often, I find developers overly generalize and never learn the most powerful features of a langauge or technology. Each language offers many powerful features that speed development and improve quality. Technologies have many ins-and-outs that cannot be learned in a month.

    I often see very “generic” code that doesn’t take advantage of basic language features like type safety, memory management, or built-in API functionality. Instead, the code is written for the least common denominator and ends up being bloated, brittle, hard to debug, and a reinvention of the wheel.

    C++ code written using hand coded data structures and pointers instead of STL and std::shared_ptr. Java applications with raw threads instead of java concurrency. The list goes on. Even one implementation of MSMQ that didn’t take advantage of its message durability capabilities.

    Take the time to learn what a language or technology has to offer. Then when its time to generalize and “learn the syntax” for the next language, you know what to look for. I’m tired of looking at code that doesn’t use templates or generics because the programmer didn’t take the time to learn about it.

  4. Mathias

    Said on November 28, 2008 :

    I wholeheartedly agree with the access modifiers part. By default, nothing should be public, unless it is clear that you want this to belong to the public API. In a past project, I over-used public, and as a result there were multiple ways to access the same method on a class, directly or indirectly, which made maintenance/refactoring a complete nightmare.
    On the commenting aspect, I would say that every class file should start with a short comment on what the class is about; if anything it forces you to see if the class is well defined: if you can’t explain what the class does in a couple of sentences, chances are, it’s too big. Unless self explanatory, public methods/properties ought to be documented so that the arguments are clear.

  5. Shahar Y

    Said on November 28, 2008 :

    @ James

    I totally agree.
    The problem is that learning the most powerful features of a langauge takes time, you can’t just learn it by reading a book.
    “Take the time to learn what a language or technology has to offer” – it comes with a lot of time and experiance, which your boss doesn’t have ;)

  6. stefano m

    Said on December 10, 2008 :

    i think these tips are very obvious.. all programmer should comment code , use proper modifiers, use standard solutions and so on…

  7. Shahar Y

    Said on December 10, 2008 :

    @ stefano m

    But not all programmers do it…

  8. Lupe Shryock

    Said on November 19, 2010 :

    Greetings I recently finished going through through your blog and I’m very impressed. I actually do have a couple questions for you personally however. Do you think you’re thinking about doing a follow-up putting up about this? Will you be likely to keep bringing up-to-date too?

Post a Comment