Boolean Algebra

[ASB]

The bigger problem though is that you described what you wrote as a business rule. The fact is it isn't. The arguably larger issue is that statement1 through statement4 may or may not be executed in all cases. That depends on the language. This could have unintended consequences.

[ASB]

Clearly that's a mistake but it should be pretty obvious when (if) they come to test it.

What I can't stand seeing is lots of nested if statements when a single one could be used (eg if(object != null) { if (object.Item == "Test"); }). I've seen that kind of thing so many times from supposedly degree educated developers, pure lazyness.

But how else would you write it? It depends on the language constructs available and whether the language short circuits.

In Cobol for example:-

if object not null and object.item = "Test" will be fine.

In C# it'll throw an exception in the case where the object is null because it doesn't short circuit. Same is true in VB. Of course in VB.NET you could:-

if object isnot nothing andalso object.item = "Test"I imagine there is a similar construct in C#

The construct you described is not necessarily laziness, it may be the only option that was available. It may be that the implementer felt it made it blindingly obvious.

[Spacecadet]

Of course, in it's entirety it's more than just a language, but then so is Java.

.NET is a framework
VB.NET and C# are languages

[Jaws]

But how else would you write it? It depends on the language constructs available and whether the language short circuits.

In Cobol for example:-

if object not null and object.item = "Test" will be fine.

In C# it'll throw an exception in the case where the object is null because it doesn't short circuit. Same is true in VB. Of course in VB.NET you could:-

if object isnot nothing andalso object.item = "Test"I imagine there is a similar construct in C#

The construct you described is not necessarily laziness, it may be the only option that was available. It may be that the implementer felt it made it blindingly obvious.

In C# boolean expression evaluation is short circuited.

if (object != null && object.test == "Item") // would work

If there are 5-6 levels of nesting in a method due to things like this, any gains from making things obvious are lost as far as I'm concerned.

I'm very forgiving with legacy code and last minute bug fixes, it's just when newly written code comes to me in that format that it bothers me.

[ASB]

In C# boolean expression evaluation is short circuited.

if (object != null && object.test == "Item") // would work

Fair enough. I was under the impression it wasn't short circuited (i.e. same as vb.net), obviously wrongly.

If there are 5-6 levels of nesting in a method due to things like this, any gains from making things obvious are lost as far as I'm concerned.

Quite agree.

I did once see something very like:-

Select Case True
Case SomeObject isnot nothing
if Someopbject.Property = "xyz"
do something
end if
end select

A novel approach if nothing else.

[doodab]

Of course, in it's entirety it's more than just a language, but then so is Java.

.NET is a framework
VB.NET and C# are languages

Yes, I know. If you had read more than one line of my post you would know I know, and you would also know that part of the .Net framework is a language.

The high level languages aren't strictly part of .Net, as you so rightly pointed out, but many people treat the term as a synonym for either C# or VB (but rarely both).

The CIL (common intermediate language for the google-challenged), which is both a language and part of .Net, is what I would call a modern OO langauge, i.e. it's object oriented, supports exceptions and doesn't require the developer to be responsible for memory management.

Anyway, to appease the pedants among you I have edited the original post.

The point I was making is that API functions that return null to indicate an exceptional condition are a carry over from days of yore and have no place in a modern object oriented whateverthe****youwantocallit that supports exceptions and takes care of memory management automagically.

[NickFitz]

...300 classes all of which should probably be named NullPointerExceptionFactory

Of course, in an ideal world I would tell the numpty to wrap whatever API is returning null objects in a factory class that throws an exception, as personally I think that functions that require checking their return values for null have no place in a modern OO language.

In many cases the Null Object pattern is appropriate. (Here's a GoF-style description.)

[doodab]

In many cases the Null Object pattern is appropriate. (Here's a GoF-style description.)

Perhaps some future dynamically typed language might feature a new concept of null as an object that implements any method call as a default "do nothing" action, thus forcing people to use exceptions to signal errors. Or at least getting rid of all those spurious checks for null references in return values.

[thunderlizard]

I did once see something very like:-

Select Case True
Case SomeObject isnot nothing
if Someopbject.Property = "xyz"
do something
end if
end select

once I saw:

For i = 1 To 2

 If i = 1 Then
  DoA()
 End If

 If i = 2 Then
  DoB()
 End If

Next i

[Zippy]

once I saw:

For i = 1 To 2

 If i = 1 Then
  DoA()
 End If

 If i = 2 Then
  DoB()
 End If

Next i

That deserves a prize of some sort