programming practices: never say never

Jan Bannister wrote this post: bool considered harmful, and writes:

Never Use Bool, or more specifically never user bool as a parameter. It is the most foolish of datatypes and conveys the smallest amount of information possible.

I can disagree with that in a number of ways, but the culprit was the "never use bool as a parameter", the biggest problems I see
- you would end up with hundreds of enums to replace your bool parameters, and then
- where do you put all those enums?
- at some point you would probably duplicate some of the required functionality

so, what do we do, bool is still "harmful", but not always, that's the key, I can think of at least 2 situations where you don't necessarily need to replace your bools with enums
- private methods: they are (hopefully) only used in that class... and the method is not that big, and the class is not that big, and you added comments for the method/parameters... sigh...
- functions with a single parameter that is just an on/off thing, e.g. SetVisible(true)

there, now it doesn't sound that bad, bottom line, never say never, don't abuse any technique

is not about the pattern, it's about the practice

There's a discussion going on in the blogosphere about "bashing patterns", Corneliu (parallel thinking) says:

This month seems to be the month of bashing the singletons and some of the other design patterns.

From posts like Singleton Considered Stupid to Singleton – the most overused pattern and Criticism on one the Patterns (Blog 3), the blogo-sphere is full of comments about why singleton is bad or evil.

I don't think the problem is with the use of the pattern, but with the abuse of them; but this has always been the problem in programming in general, most of the time programmers learn a few things just to "get things working", and as long as it works "if is not broken why fix it".
Is it all the programmers fault? I don't think so, I think it has to do a lot with management requesting things to be done by yesterday (bad estimates), but that's another topic which has been discussed quite a lot already

so this is not a new problem, is the same old problem (abuse of techniques) applied to the patterns, the patterns are good, the implementation may be correct, but the usage (the practice) of them is the problem

why the singleton? I think because that's one of the "easiest" ones, you can pretty much copy and paste it, you don't even need to understand the inner workings, you just know that "it will be a single instance of your class", and that's something you can't do with other patterns

we need to teach better usages, better practices.

programming with a mouse considered harmful

I had a hard time deciding if the title should be "programming with a mouse considered harmful" or "real programmers don't use a mouse"; but I think you get the idea

I'm mentoring a guy right now, and he started using the mouse to move around in the code, I told him

"don't use the mouse, that's a bad practice"

It doesn't matter how many years you have been programming, if you use the mouse, you are implicitly slow, you can do things at least twice as fast using only the keyboard.

leave the mouse for things that you don't usually do, but for everything that you are doing in code there absolutely no reason to use the mouse; if you are new to programming it should be a lot easier to learn to use all the shortcuts, if you have been programming for a while is definitely harder (and you probably think you're better off without them at this point) but you would definitely increase your programming speed

I am known for being pretty fast (and they say I'm cocky for that matter), but one of the main reasons I'm fast is because I learn to use the shortcuts, I had a hard time switching from Delphi IDE to VS, but I did it without remapping the keyboard to use "Delphi IDE style", I think it's a bad idea to remap the keyboard to your specific style, specially is you do some type of pair programming (you are doing paired programming, right?)

you don't have to learn all of the shortcuts available, just the ones for all the little tasks that you do commonly when programming

use the keyboard, program faster

good bye username and password

Whenever you use user names and passwords in your applications, consider using System.Net.NetworkCredential to pass the information around functions, it encapsulates those fields, and allows you to extend in the future to maybe use a domain as well.

In my case we're using it in a plugin architecture to authenticate against any system, using this class encapsulates those fields and allows the plugin to authenticate against most standard systems as it is not tied specifically to username and password