RE: Fw: [PHP] debuging and getting mor information about failures
-Original Message-
From: Chris W. Parker [mailto:[EMAIL PROTECTED]
Sent: 29 July 2003 19:22
To: Ford, Mike [LSS]; Gabriel Guzman; Peter James
Cc: [EMAIL PROTECTED]
Subject: RE: Fw: [PHP] debuging and getting mor information about
failures
Ford, Mike LSS
on Tuesday, July 29, 2003 11:00 AM said:
I know the braces vs. end-token debate is almost on the scale of a
holy war, and I admit to hating the curly-brace style with
a passion,
but when I see code like this:
function doit()
{
for()
{
if()
}
...
}
else
{
...
} // if
} // for
}
I wonder why the heck the author didn't just go for the alternative
syntax with proper end-tokens and get the added value they deliver.
You are correct. If I had in fact originally written my block of code
with // if and // for it would make more sense to use the
alternative syntax that you detailed in your original mail. But I
/didn't/ use // if and // for therefore I wouldn't use the
alternative syntax because it's just more characters to type
All true so far, and I wouldn't argue with any of this if that is your preference.
and
generates no useful benefit.
But this I would take issue with -- as I said in my original email, you tend to get
more-focussed error messages if you accidentally omit one of the end-tags than if you
omit a closing brace. It's also more obvious exactly *which* end-tag you've left out.
(Although I did once spend half a day completely failing to spot a missing endif
right where the error message was pointing, and chasing all sorts of other red
herrings before seeing the error and turning the local air blue in disbelief!!!).
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Fw: [PHP] debuging and getting mor information about failures
A tip on avoiding errors cause by not enough }'s is to close any bracket
immediately after you open it, so if I were writing a block of code:
function foo(){
}
I would write the above first, and then fill in between the {}'s. This
way, when I get to the end of my script, I know I'm at least not missing
any curly braces. You can do this with others, but these are usually
the hardest to track down once you have a large amount of code (with a
large number of {}).
I know this is painfully obvious, but it does help.
gabe.
On Tue, 2003-07-29 at 09:33, Peter James wrote:
Just forwarding this reply back to the list.
- Original Message -
From: Chris W. Parker [EMAIL PROTECTED]
To: Peter James [EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 10:26 AM
Subject: RE: [PHP] debuging and getting mor information about failures
Peter James mailto:[EMAIL PROTECTED]
on Tuesday, July 29, 2003 9:18 AM said:
These errors are usually caused by an extra or missing brace or
quote/apostrophe/backtick. The best way to find where this is
happening is to use another error.
[snip]
This is a very frustrating error message[snip]
It also helps to learn what to look out for. Not to say that I won't
ever have the need, but I've never needed to deliberately introduce one
error just to find another one, especially when it's a syntax error.
The best thing to do is just get used to scanning your lines of code for
proper syntax. Make sure you always have a ; at the end of each
statement, make sure your curly braces line up, etc.
Another thing that be making this error difficult for you to find is
because of your coding style. Your code could possibly be written in
such a way that it doesn't make scanning it too easy therefore making it
hard to find such tiny errors.
hth,
chris.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: Fw: [PHP] debuging and getting mor information about failures
Gabriel Guzman mailto:[EMAIL PROTECTED]
on Tuesday, July 29, 2003 9:44 AM said:
A tip on avoiding errors cause by not enough }'s is to close any
bracket immediately after you open it, so if I were writing a block
of code:
Good tip. I do this too.
I would write the above first, and then fill in between the {}'s.
[snip]
You can do this with others, but these are
usually the hardest to track down once you have a large amount of
code (with a large number of {}).
Especially when you write code like:
function doit() {
for() {
if() {
...
} else {
...
}
}
}
As opposed to the much easier to read (and line up curly braces) method:
function doit()
{
for()
{
if()
}
...
}
else
{
...
}
}
}
See how those curly braces line up all nicely? ;)
chris.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: Fw: [PHP] debuging and getting mor information about failures
-Original Message-
From: Chris W. Parker [mailto:[EMAIL PROTECTED]
Sent: 29 July 2003 17:56
[...snip...]
As opposed to the much easier to read (and line up curly
braces) method:
function doit()
{
for()
{
if()
}
...
}
else
{
...
}
}
}
Or the (IMVHO) even easier to read, even easier to match up, and producing more
focussed error messages:
function doit()
{
for():
if():
...
else:
...
endif;
endfor;
}
And yes, this is valid PHP -- it's the alternative control-structure syntax that is
mentioned throughout the control structures section of the manual. The beauty here is
that if you accidentally leave out (say) the endif, you'll get an error at the endfor
(because the parser is expecting an endif!), not wy down at the bottom of the file
when it just knows there's an unclosed brace from somewhere or other.
I know the braces vs. end-token debate is almost on the scale of a holy war, and I
admit to hating the curly-brace style with a passion, but when I see code like this:
function doit()
{
for()
{
if()
}
...
}
else
{
...
} // if
} // for
}
I wonder why the heck the author didn't just go for the alternative syntax with proper
end-tokens and get the added value they deliver.
OK, I'll step back off my soap-box now ... ;)
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: Fw: [PHP] debuging and getting mor information about failures
[snip] I wonder why the heck the author didn't just go for the alternative syntax with proper end-tokens and get the added value they deliver. [/snip] At the risk of stepping of of the curb into the holy-war that rages about this the answer Mike is that a lot of PHP coders are what as known as old school. They programmed in another older language where bracing was a requirement. It may be, for some, force of habit. Rather than the old dog learning a new trick, if the old trick works why fix it? :-) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: Fw: [PHP] debuging and getting mor information about failures
I know the braces vs. end-token debate is almost on the scale of a holy war,
and I admit to hating the curly-brace style with a passion, but when I see code
like this:
[snip code]
Yeah, I'd hate curly braces with a passion if I saw code like that, too. How can
anyone *possibly* read that and follow it clearly? I couldn't.
When I use control blocks, they are always indented making it much easier to
determine what goes where:
function doit() {
for() {
...floating code...
if() {
} else {
} // if
} // for
...floating code...
}
Much easier to read. But YMMV...
Chris
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: Fw: [PHP] debuging and getting mor information about failures
Ford, Mike LSS
on Tuesday, July 29, 2003 11:00 AM said:
I know the braces vs. end-token debate is almost on the scale of a
holy war, and I admit to hating the curly-brace style with a passion,
but when I see code like this:
function doit()
{
for()
{
if()
}
...
}
else
{
...
} // if
} // for
}
I wonder why the heck the author didn't just go for the alternative
syntax with proper end-tokens and get the added value they deliver.
You are correct. If I had in fact originally written my block of code
with // if and // for it would make more sense to use the
alternative syntax that you detailed in your original mail. But I
/didn't/ use // if and // for therefore I wouldn't use the
alternative syntax because it's just more characters to type and
generates no useful benefit. And besides, it reminds me of my days of
VBScript. blagh.
I also think there may be something to say about how often a person
checks their updates. I usually don't write more than a few lines of
code before I try it out in the browser. Checking the code frequently
makes it a trivial task to find syntax errors, especially since you know
the error has to be contained within the tiny block of code you were
just writing.
Chris.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Fw: [PHP] debuging and getting mor information about failures
* Thus wrote Jay Blanchard ([EMAIL PROTECTED]): [snip] I wonder why the heck the author didn't just go for the alternative syntax with proper end-tokens and get the added value they deliver. [/snip] At the risk of stepping of of the curb into the holy-war that rages about this the answer Mike is that a lot of PHP coders are what as known as old school. They programmed in another older language where bracing was a requirement. It may be, for some, force of habit. Rather than the old dog learning a new trick, if the old trick works why fix it? not to mention the % function in vi. with that I can easily find missing brackets. :-) hehe.. now I can start a vi/emacs war :) Curt -- I used to think I was indecisive, but now I'm not so sure. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
