[Phpwm] days_between()

[Phil Beynon]

> > > The other thing that I'm lead to believe is bad coding practise is the
> > use
> > > of the '@' symbol. I can understand not wanting to see the errors, but
> > > surely you should be catching them and dealing with them or let
> > > them bubble
> > > out so that the layer above can catch them.
> > > Finally perhaps a more suitable naming convention for your variables
> > might
> > > assist other programmers and readability in the future.
> >
> > Huh? thats the way it returns the 'X' - if you don't suppress the error
> > that
> > way it breaks the page by dumping the error out. I didnt want that
> > happening, if it has an error then its going to trigger the 'else return
> > "X"' caused by the boolean off the 'if' - try it and see! :-)
>
>
> I think you're missing the point I'm trying to make (and yes I was
> wrong in suggesting using try and catch due to PHP's internal error
> handling, but that's due to my java background that I expect to be
> able to catch any runtime error thrown) .
> The point I'm trying to make is that 'x' is a bad error character to pass
> back. Surely the 'null' character would make more sense as that
> way the view
> (or whatever is calling the function) could deal with the result as it saw
> fit?

As long as the next part of the program calling the function understands all
possible input conditions there is no instability, so if it is X, null, or
wibble, it is a matter of personal choice.

> I personally would even stay clear of using Boolean false because of
> php's dynamic typing.

Why? all the variables that fall within the scope of the Boolean comparison
are explicitly defined on the preceeding lines, so there should be no issues
with that.

I'm interested in why you should think negative - do you still call it
barred?? - logic is less valid than positive logic?
As a consideration you couldn't do a Karnaugh mapping solution of a complex
logic without negative logic properly.

> As for the use of the '@' symbol, I've
> always been led
> to believe that you should try not to use it where possible.

I don't, but in this case it was required for the reasons previously stated.

> I would have
> thought a better way is to check the data being passed into the function
> rather than allow PHP to have an error that you would suppress?

The error handling should in theory never actually be triggered, that
however is not a reason not to have it there!

> Also for code readability, would it not be better to keep to 'good
> practises' and not use single line if statements?

Thats been mentioned before :-)
Some of the machines I grew up on didn't enjoy too much whitespace jumbled
in with the code.
Funny thing is I can actually read, write and comprehend it quicker the way
I write it than stuff thats tabbed all over the page.
I was looking at a PHP class for something earlier today - by the time you
have taken all the whitespace, line feeds and verbose annotation out of it
the whole thing could have been written in about a dozen lines, yet it ran
to about 2 screen lengths for no real reason.

Phil