php-general Digest 29 May 2012 07:52:59 -0000 Issue 7830
Topics (messages 318010 through 318011):
Re: What is The best way/tool for debuging PHP?
318010 by: Lester Caine
Re: Function size
318011 by: Tony Marston
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
LEOPARD Corporation wrote:
Dev-PHP is an IDE, and I don't need such tool because I'm using Eclipse,
and I'm very comfortable with.
Good to hear others are using Eclipse as well ;) I work on a lot more than just
PHP so as a single platform it's great - even between Linux and Windows.
what I really want to know is:
what is the best "pure" debugging tool which its function is to debug PHP
scripts and applications only.
I'm still using PHPEclipse for the PHP editing, and while I do have xdebug
installed with it, I tend not to have to bother 'debugging', I normally just
need to add the occasional print_r() in the simple stuff, and the bitweaver
framework has some additional debugging facilities built right in for tracking
SQL problems and proving a pretty view of data provided by print_r(). A little
longer winded than setting breakpoints, but it works well the majority of the time.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
--- End Message ---
--- Begin Message ---
On May 21, 2012, at 8:32 PM, tamouse mailing lists wrote:
> A rule of thumb is no more than 50 lines per
> function, most much less. Back in the day when we didn't have nifty
> gui screens and an 24 line terminals (yay green on black!), if a
> function exceeded one printed page, it was deemed too long and marked
> for refactoring.
I think the idea of setting an arbitrary limit on the number of lines that a
function should contain is quite ludicrous and something which I will
completely ignore. If a function requires a hundred or more lines then so be
it. The only reason to take a block of code and put it into its own function
is when that code is likely to be called more than once so that it conforms
to the DRY principle. If it is only ever used in one place then there is no
point.
The problems I have with creating lots of small used-only-once functions is
as follows:
- you have to create a meaningful name for each function.
- all those functions should be arranged in alphabetical order within their
containing file - having them in a random sequence makes it difficult to
find the one you want.
- when browsing through the code you have to keep jumping to another
function, and then returning to where you came from.
I don't know about you, but I would rather use the scroll wheel on my mouse
than keep jumping from one position in the file to another.
Another problem I have encountered in the past with such an idea is that it
encourages a stupid programmer to decrease the number of lines of code by
compressing as many statements as possible into a single line, which then
makes the code less easy to read and understand. This is much worse than
having more than 20 lines in a function.
Whether a file contains 10 functions of 100 lines each, or 100 functions of
10 lines each, you still end up with 1000 lines of code. If you do not have
the mental capacity to deal with a 100-line function then you are in the
wrong job.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
--- End Message ---
