11 Things that Annoy Me in .Net Programming
12/22/2008
Development, C#
(9)
Here are eleven things that annoy me that I have run into while doing .Net programming. Some are legitimate gripes that should be fixed poste haste and others are simply personal preferences that you very well may disagree with (you have the right to be wrong).
-
If statements without the curly braces
You don't need curly braces to write an if statement but for the love of God, use them! Leaving the braces out will cause the line following the if statement condition to be treated as if it were the code inside the curly braces (but only that one line of code). Using this technique makes code less readable and can also lead to subtle bugs as illustrated in the code below:
if (myValue > 10)
x = 5;
y = 7;
It's easy to look at this and expect that if myValue > 10, x will be set to 5 and y will be set to 7. And if not, nothing will happen. I reality though, only the "x = 5;" line is part of the if statement. "y = 7;" is a statement outside of the if and will always be ran. If you wrote this same statement out with the braces, it would read as below, which is much easier to understand and spot the error.
if (myValue > 10)
{
x = 5;
}
y = 7;
-
After Merge, Check-In is Canceled
In Visual Studio 2005 and 2008 (using the default merge tool at least), after you run through the merge process, you get a message saying that nothing was checked in. You subsequently have to run the check-in process again, which often involves reselecting numerous files that you need to check in. I understand that you should test your merged code out if there are any non-trivial changes, but often times the changes that I merge in might be something as simple as another developer having changed a comment or updated the page formatting or just a one line fix they made. In these cases, I know for sure that the code will still work but I still have to walk through the check-in process from the beginning. It would be nice if there was some option to check-in after a merge or cancel the check-in to do some testing.
-
ASP.net ID Mangling
There often is a need to update control IDs so that you don't end up with two controls using the same ID (especially when dealing with dynamically created controls in something like a gridview). But when I simply have a button on my page for submitting with an ID of "btnSubmit", it would be nice to be able to refer to this button in clientside scripting as btnSubmit instead of ctl00$cphMainContent$btnSubmit (normally you get this name by doing something like <%=btnSubmit.ClientID %>, which is another step I'd like to avoid). ID Mangling does need to happen in some instances, but not in all thus there should be an easy way to turn this off, like setting a property "idMangling=false" on each control.
-
Inserting a value into a string
When you are creating a string with a variable value inside of it, there are a couple ways to do it. The first method is:
nameString = String.Format("My name is {0}", Mud);
For some reason, I just never liked when people do it this way. It's really just personal preference and cannot explain it anymore than I can explain why I find the color blue more appealing than the color green. I much more prefer doing this sort of string operation this way instead:
nameString = "My name is " + Mud;
-
Regions
Some people really like these for organizing code. I'm not one of them. I like to be able to easily scroll through my code and hate the extra click involved to see the contents of each region. Rarely when I work on<
This article has been view 38 times.
|