Reply to: Boolean Algebra

[doodab]

once I saw:

For i = 1 To 2

 If i = 1 Then
  DoA()
 End If

 If i = 2 Then
  DoB()
 End If

Next i

It is of course possible that DoA() might change the value of i, although that is no excuse for such an abomination.

[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

[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

[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.

[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]

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.

[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.

[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.

[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

[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.

[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.

[doodab]

.Net is NOT A PROGRAMMING LANGUAGE

Hth.

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

I think most people would, in this context, take Java to mean the Java language and .Net to mean the CIL and the higher level languages that target the framework. 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, 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.

[Churchill]

The nested if statements of the form you describe are usually bug fixes.

It starts with an incompetent permie writing

if (object.property == "xyz") 
{...

and then he (or an equally incompetent contractor bought in to fix the mess) has to fix all the null pointer exceptions so he wraps it in

if (object != null) 
{...

which may seem lazy, but you have to ask yourself, if you are asked to "take a look" at somebody else's code, which has 300 classes all of which should probably be named NullPointerExceptionFactory, what would you do?

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 such as Java or .Net.

.Net is NOT A PROGRAMMING LANGUAGE

Hth.

[doodab]

The nested if statements of the form you describe are usually bug fixes.

It starts with an incompetent permie writing

if (object.property == "xyz") 
{...

and then he (or an equally incompetent contractor bought in to fix the mess) has to fix all the null pointer exceptions so he wraps it in

if (object != null) 
{...

which may seem lazy, but you have to ask yourself, if you are asked to "take a look" at somebody else's code, which has 300 classes all of which should probably be named NullPointerExceptionFactory, what would you do?

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.

[Spacecadet]

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.

I see a lot of nested case statements which have been hacked together over a period of time. Much like you describe there.
Occasionally, I've found bits of case statements which would never be used, they just sit there untouched by logic like some sort of useless appendix.

and then the surplus brackets in SQL

and ((sales.customer_id) = (customers.customer_id))

You start to question if they're writing the stuff themselves or getting access to do it for them, lazy idiots