Showing posts with label syntax. Show all posts
Showing posts with label syntax. Show all posts

Monday, January 19, 2009

String versus string in C#

A month ago I had a developer that I'm currently in the same project with questioning me about my use of string versus my use of String. She found it confusing that I didn't just use one of them consistently. I told her my idea, which is that I'm using String when accessing static members and string otherwise, but she still found it confusing.

I then decided to consult the IDesign C# Coding Standard, and looking there I found some inconsistency. I decided to ask them about it, and they seem to share my belief. See my mail and answer below.

From: Juval Lowy
Sent: den 19 december 2008 15:51
To: Tommy Bryntse
Subject: RE: Contacting IDesign

You should use String for the static members.

________________________________________
From: Tommy Bryntse
Sent: Friday, December 19, 2008 6:27 AM
To: sales@idesign.net
Subject: Contacting IDesign

Hello IDesign!

I noticed an inconsistency in your C# Coding Standard.

In section 1.10 it says

Always use … string NOT String.

While in section 2.52 it says

Use String.Empty instead of "":

Myself I’ve always used String for accessing static members in string, and string
otherwise, just as your example. Section 1.10 was about to make me change that to
always use string, but after seeing section 2.52 I’m confused. What should I do?

Kind regards,

Tommy

Friday, March 14, 2008

Never Skip Curly Brackets

In the book that I'm currently reading the author continuously skips curly brackets where they are not needed. That is, in if, for, while etc. statements controlling only one line of code. I would have thought that all experienced software developers always used the curly brackets.

I can't come up with any reason not to use them, except maybe "less to type" or "less lines of code". Both reasons equally lame.

How much of your programming hours are spent typing? And whats the purpose to strive for less lines of code? The purpose must be readability, and I would not agree that it is increased by not using curly brackets. Rather the opposite. If your readability problem is caused by functions having many lines it is the design that is the problem, not the brackets.

Instead, not using curly brackets is very error prone.

Consider that you want to add something to the code block of an if-statement, now you'll need to add the curly brackets anyway. And if you fail to notice this it will cause weird errors in your program since the second line will always be executed.

if( foo )
foo = false;
bar = true;

Or lets say that you temporarily want to remove the executed statement with a comment. Now you'll need to add the brackets, or comment the if-statement too. If you don't do any of this the if-statement will instead control the next line of code.

if( foo )
//foo = false;

ASSERT(!foo);

As you see from these examples you may very well be fooled by the indentation of the code.

So, to all of you out there that aren't using those curly brackets unless you're forced too - start using them always!