Compact code, using C# shorthand and coding habits

I've been reprimanded for writing code that's too complex...well, not exactly reprimanded, but told to please make my code less complicated.

One of the things i do often is use shorthand..for those that doesn't know what shorthand is, its when your use "logical" operators like "? :" and "??" in your code.

ex.

bool result = (object.type == businessObjectType.Status)
                       ? true
                       : false;
instead of:
bool result;

if (object.Type == businessObjectType.Status)
{
    result = true;
}
else
{
   result = false;
}
The same goes for not always using { } when i don't see the need.
ex.
if (object.FieldValue > 10)
   if (otherObject.FieldValue == object.FieldValue)
       // do something

To me, shorthand code is extremely easy to use. I even use it nested at times when returning an object or value if there's multiple checks to do and the logic can return multiple objects or values.

My bad habits are obviously not in check with good coding practises, but i've been using this type of code for a LOONG time..the coding style is hard to changed but since it's requested i suppose i'll have to try.

What do people think about it?

Published Wednesday, July 04, 2007 8:13 AM by Brian Madsen
Filed under:

Comments

# re: Compact code, using C# shorthand and coding habits

I think your first example is too long:

bool result = (object.type == businessObjectType.Status) would be sufficient and preferred in my book.

On the second point, highly nested if statements possibly indicate that you need to refactor the method.

Tuesday, July 03, 2007 7:48 PM by skware

# re: Compact code, using C# shorthand and coding habits

well, personally, instead of your examples I would just write:

bool result = (object.type == businessObjectType.Status);

Tuesday, July 03, 2007 7:52 PM by alex

# re: Compact code, using C# shorthand and coding habits

hey skware and alex,

the example may not have been a real life scenario..more to show what shorthand is.

but both of you indicate that using shorthand seems to be ok..

would you say it makes the code harder to read or simpler?

and yes, too many nested IF statements definitely means refactoring is in order..

the rule here is 2 as a max..

the refactoring and/or the nested IFs isn't the issue either..more the lack of the { } when the code is readable without it..

gosh you two a picky :)

anyways, what's your view on the {} usage when it's not needed, IMHO that is?

Tuesday, July 03, 2007 8:34 PM by Brian Madsen

# re: Compact code, using C# shorthand and coding habits

I would really say it depends

I would say the following is more clear without the { }

if (Alert != null)

    Alert(this, EventArgs.Empty);

but I think keeping the { } can add clarity when for's and if's are nested, which is a code smell anyway.

I agree with alex & skware with the syntax for

bool result = (object.type == businessObjectType.Status);

...except in the case of a return value, eg:

bool CheckType()

{

  return (object.type == businessObjectType.Status);

}

(imho ^^ that would be bad)

I'm also in favor of introducing locals for parameter names where an override exists and is not immediately obvious eg I favor this:

bool SupressKeypressInConsole = true;

ConsoleKeyInfo answer = Console.ReadKey(SupressKeypressInConsole);

...over this:

ConsoleKeyInfo answer = Console.ReadKey(true);

Just my 2c :-)

Face it Brian, you just like leaving out the { } because you want your C# to look like VB!

:-)

Tuesday, July 03, 2007 10:34 PM by James Green

# re: Compact code, using C# shorthand and coding habits

I'm not indicating that "shorthand seems to be ok" at all. Personally, that example is not a shorthand, that's how it should be. Code should be light, clean and readable for obvious reasons.

I'm not completely aware of the issue with your code being "too complicated", but I guess it is more to do with something different then the matter how many nested ifs it has or using shorthands.

Tuesday, July 03, 2007 11:55 PM by alex

# re: Compact code, using C# shorthand and coding habits

Alex, using the ?? and : or ?? is called shorthand...

the first example i showed was shorthand, whereas using the IF/ELSE/ELSIF/ELSEIF isn't.

the feedback i've gotten is that it's too complicated to read..

i've gotten permission to use single "simple" shorthand statements..but that's not the debate i'm looking for here...

more on how people view shorthand..if you say that it's not really what you'd classify as shorthand, but that it is how it should be done, then i take it you support shorthand as that's what it is ;)

nevermind...

as for leaving the { } brackets, i sometimes find it easier to read without..

i like single line statements IF they can fit without scrolling..

like.

if (x != y) callthisMethod();

again, i like it short and compact.

Wednesday, July 04, 2007 12:14 AM by Brian Madsen

# re: Compact code, using C# shorthand and coding habits

OK, would you mind to tell me, how many shorthands in the example I provided:

bool result = (object.type == businessObjectType.Status);

;-)

btw, personally, I would not accept anything like that:

if (x != y) callthisMethod();

but this code is completely OK with me:

if (x != y)

 callthisMethod();

Wednesday, July 04, 2007 1:56 AM by Alex

# re: Compact code, using C# shorthand and coding habits

Alex,

the reason the post was also titled "Coding habits" is because i'm also trying to ascertain if my habits are way off (code smell?)..

you don't personally like:

if (x != y) callthisMethod();

but i happen to think it's very logical and easy to read..again, that's an old habit formed in me, which i'm trying to shake but so far haven't quite gotten rid of it..some habits just takes longer to die than others.

I also wasn't referring to your excample as being shorthand..you took my first excample litteral and wanted to improve it..it was merely an excample that's all as i didn't want to write an OS to get my meaning across.

Lucky for me, i don't work on your team and you're not in a position to accept or not accept my code ;)

Lastly, this wasn't a rant, but i was trying to find out if my habits of using shorthand and my "possibly" bad habits was causing "code smell"....if there's a distinct nauseous odour coming from the code then i should definitely try REALLY hard to change it.

and urggghhh @ James for mentioning VB.Net here!!! bad James!!!

Wednesday, July 04, 2007 9:46 AM by Brian Madsen

# re: Compact code, using C# shorthand and coding habits

Brain,

there is a document somewhere outlining how you should write your code, name classes and variables, etc. I'm pretty sure it is out of date, but will give you some clue what's is acceptable and what is not.

I believe, it has been written by your team leader    :)

Wednesday, July 04, 2007 8:19 PM by Alex

# re: Compact code, using C# shorthand and coding habits

Hey Alex,

yeps, have read it...and you're right, it's out of date...

it also doesn't have anything mentioned in there about shorthand and it's not very detailed either.

and yes, again, you're right, it's written by the TL.

I don't really want this to be a work-discussion as that's not the point Alex and there's a big difference in adhering to very old coding conventions and keeping it up-to-date with the platform we're working on. Regardless, this isn't a work discussion Alex..

this, and i'll repeat myself again if you missed it the first time, was meant to figure out if using shorthand in general was bad form.

Some of the most used productivity add-ins for Visual Studio has features inbuilt which will shorten things like references, method names, variables etc...some can convert code to use different logics..

I admit i haven't seen shorthand used that frequently, but is it bad to use it?

Wednesday, July 04, 2007 8:55 PM by Brian Madsen

# re: Compact code, using C# shorthand and coding habits

Do you know what it comes down to? How easy you code is for other to read. I err on the side of verbosity with things like curly braces and parenthesis.

Using ternary operators (the ? thing) is fine as it is an understood construct. And if they are all on one line then they are easy for another developer to work out what is going on.

Dropping curly braces though, IMHO is a no-no - it is too easy to make a mistake and if you have even been up at 3 am trying to debug some code (I know you have Brian ;) ) they are just another place that can trip you up.

The extra confusion saved by two keystrokes is just not worth it.

Tuesday, July 10, 2007 12:40 AM by Myles Eftos

# re: Compact code, using C# shorthand and coding habits

I tend to agree with you Myles...at least on some of what you say..

1) i believe that one line constructs are easy to read IF they aren't wider than the screen (eg. no horz-scrolling in the editor)

2) dropping curly braces is a no-no in general.

ex.

if (whatever == null)

 return;

if (whatever == something)

 for (whatever.....)

   do something;

that to me is easy to read... but, the #1 rule i have is that if the [for] statement isn't a 1-liner then i dont do it. no else or multiple-line for/while etc statements.

also, no else in the other end, provide the [if] statement initially is a 1-liner

ex.

if (whatever == something)

 do something;

else

{

 do something else;

 over multiple lines;

}

if the [else] is a 1-liner it can look like this:

ex.

if (whatever == something)

 do something;

else

 do something else on 1 line;

obviously i can read both, but i've seen many say that it's code smell to do, so i'm stopping it... ;)

strangely enough, it's not a matter of being lazy either - i use ReSharper and it adds the closing curly bracket for me..same goes if i'm "lost" in a sea of curly brackets (while refactoring something for instance) i just have to hover on the last curly bracket and it will show me where it starts..

the more compact the code is the better - i just wonder if i'm sometimes taking it too far.

and yups - i've been up way past 3am debugging code before..uhmm record is a 40+ straight working day(s) - can't quite remember how long it was but it was long..not sure how easy the code was to read in the end tho.

I think one of the problems i've had is that i've been "taught" by too many and i'm a confused lil' boy in the code jungle...

Even after reading tons of best bractises articles, code structure books - some of my own bad habits tend to be completely logical to me...

Tuesday, July 10, 2007 1:00 AM by Brian Madsen