php-general Digest 31 May 2012 10:02:10 -0000 Issue 7833
Topics (messages 318031 through 318036):
Re: Function size
318031 by: Sebastian Krebs
318032 by: Paul M Foster
318033 by: Steven Staples
318034 by: Paul M Foster
318035 by: admin
LAMP appliance
318036 by: Jordi Massaguer Pla
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 ---
Hi,
Just want to throw my 2 cent in :)
2012/5/30 Tony Marston <t...@marston-home.demon.co.uk>
>
> "Ashley Sheridan" <a...@ashleysheridan.co.uk> wrote in message
> news:1338326229.2616.31.camel@localhost.localdomain...
> > On Tue, 2012-05-29 at 17:06 -0400, Paul M Foster wrote:
> >
> >> On Tue, May 29, 2012 at 08:52:46AM +0100, Tony Marston wrote:
> >>
> >> > 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.
> >>
> <snip>
> >
> > And yeah, alphabetical order? Really?
>
> This is a throwback to my 3GL days when all components within a file were
> arranged in alphabetical sequence so that they were easier to find when you
> looked at the printed listing.
>
> > Group them by similarity, sure.
> > But today, with IDEs that will jump straight to functions and class
> > methods, and the good ol' find tool on every editor I've ever seen, is
> > sorting them alphabetically really necessary? Seems like a waste of time
> > that is likely not going to be done by fellow developers working on the
> > same codebase.
>
> I have never come across an IDE that jumps to a function when you click on
> its name, so how does it return to where you jumped from?
>
At least PhpStorm and Eclipse have a feature to return where you come from.
I haven't seen an IDE, that is _not_ able to jump to a functions or methods
source for a long time now.
>
> Rather than artificially reduce the size of a function to satisfy someone
> else's limited attention span I would rather use the scroll wheel on my
> mouse. Scrolling up or down within a single function is easier than
> searching/finding/jumping to a series of sub-functions which may exist at
> random locations within the same file.
>
If the functions were named properly you don't have to follow every
execution path to the deepest deep. Or do you reading PHPs C-source, just
because a wild "substr()" appeared? When you see a method "loadFromFile()"
and the IDE tells you, that it expects a $filename as parameter, why should
you jump there just to make sure, that the method loads something from a
file by the filename given as first parameter?
>
> I will only split a large function into sub-functions when it makes sense
> to
> do so, and not because some nerd cannot scan more than 20 lines at a time.
>
The question I ask myself is: Why ^should^ a scan more than 20 lines at a
time, if it is possible, to make it clearer, but another nerd decided, that
it is too much work (or whatever). Maybe it's may "attention span", but I'm
usually slightly bugged, when I have to read code monsters. Compared to a
book it's a kind of "One chapter in a single sentence".
Regards,
Sebastian
>
> --
> Tony Marston
>
> http://www.tonymarston.net
> http://www.radicore.org
>
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
On Tue, May 29, 2012 at 11:40:25PM +0200, Matijn Woudt wrote:
[snip]
> On Tue, May 29, 2012 at 11:06 PM, Paul M Foster <pa...@quillandmouse.com>
> wrote:
[snip]
> >
> > I think a lot of coders try to be kewler than the next 18 guys who are
> > gonna have to look at the code, so they use a lot of "compression"
> > techniques to reduce LOC. Plus, they're lazy. I'd rather see everything
> > with lots of spaces and plenty of comments and blank lines. Especially
> > since I'm sometimes that 18th guy to look at the code.
> >
> > Paul
>
> Paul,
>
> Are you stating here that compression is a bad thing?
>
> That means you consider this nice:
>
> if ( action == A )
> {
> doA();
> }
> else if (action == B )
> {
> doB();
> }
> else
> {
> doC();
> }
>
> Or perhaps flooded with comments that merely say the same as the code does?
>
> I'd go for
> if(action == A)
> doA();
> else if(action == B)
> doB();
> else
> doC();
>
> or , if it's really that clean, i'd probably go for
> if(action == A) doA();
> else if(action == B) doB();
> else doC();
No, that's not what I mean. It's not necessarily compression in the
sense that the coder is taking up less actual space. It's hard to
explain, and I'm not good at it because I try not to do it. It's more
along the lines of using very terse and peculiar coding techniques to
save time and look kewl. Maybe something like this:
The "long" way:
$alfa = 0;
if ($bravo) {
if ($delta)
$alfa = echo();
elseif ($foxtrot)
$alfa = golf();
}
elseif ($hotel) {
$alfa = india();
}
The "kewl" way would be to translate the above into a single expression
using solely multiple nested terniary operators ( ? : ) on a single line.
Nothing wrong with the functionality of the result, but it becomes hard
has hell to read and figure out what the code is trying to do. And
nothing against terniary operators. I use them where appropriate. But in
a complex conditional like the above, they really only serve to
obfuscate the meaning of the code. We might marvel at the skill of a
programmer who did such a thing, but he's obviously not looking down the
road at the other people who will later maintain his code.
Paul
--
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com
--- End Message ---
--- Begin Message ---
> Paul,
>
> Are you stating here that compression is a bad thing?
>
> That means you consider this nice:
>
> if ( action == A )
> {
> doA();
> }
> else if (action == B )
> {
> doB();
> }
> else
> {
> doC();
> }
>
> Or perhaps flooded with comments that merely say the same as the code does?
>
> I'd go for
> if(action == A)
> doA();
> else if(action == B)
> doB();
> else
> doC();
>
> or , if it's really that clean, i'd probably go for if(action == A) doA();
> else if(action == B) doB(); else doC();
>
> - Matijn
How about this:
($action == 1? doA():($action == 2? doB(): doC()));
Steve.
--- End Message ---
--- Begin Message ---
On Wed, May 30, 2012 at 04:31:12PM +0200, Sebastian Krebs wrote:
[snip]
>
> If the functions were named properly you don't have to follow every
> execution path to the deepest deep. Or do you reading PHPs C-source, just
> because a wild "substr()" appeared? When you see a method "loadFromFile()"
> and the IDE tells you, that it expects a $filename as parameter, why should
> you jump there just to make sure, that the method loads something from a
> file by the filename given as first parameter?
Here's why, and I've seen this happen a *lot*. The function may be
properly named, but have side effects. Or the guy who named the function
*thought* it was properly named, but was wrong. For example, he may have
named the function "loadFromFile()", and the function does in fact do
that. What the name doesn't tell you is that it then erases the file
from which it pulled. Oops! No, you're correct, the function is *not*
properly named in that case. But the guy who wrote it thought it was.
And before I look at the internals of the function, I don't know whether
it's properly named or not. Worse, the side effects may not show up
until later, and then with disasterous results. Imagine assuming
everything's okay, patching your code into the system, and finding out
that it's been hacking up the customer's filesystem for the last three
weeks. All because you didn't check to see what that other function was
*actually* doing.
Rule: NEVER assume you know what a function is doing by looking at its
name. ALWAYS satisfy yourself that you know what a function is doing by
*looking* at what it's doing.
Paul
--
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com
--- End Message ---
--- Begin Message ---
-----Original Message-----
From: Paul M Foster [mailto:pa...@quillandmouse.com]
Sent: Wednesday, May 30, 2012 10:54 AM
To: php-gene...@lists.php.net
Subject: Re: [PHP] Re: Function size
On Wed, May 30, 2012 at 04:31:12PM +0200, Sebastian Krebs wrote:
[snip]
>
> If the functions were named properly you don't have to follow every
> execution path to the deepest deep. Or do you reading PHPs C-source,
> just because a wild "substr()" appeared? When you see a method
"loadFromFile()"
> and the IDE tells you, that it expects a $filename as parameter, why
> should you jump there just to make sure, that the method loads
> something from a file by the filename given as first parameter?
Here's why, and I've seen this happen a *lot*. The function may be properly
named, but have side effects. Or the guy who named the function
*thought* it was properly named, but was wrong. For example, he may have
named the function "loadFromFile()", and the function does in fact do that.
What the name doesn't tell you is that it then erases the file from which it
pulled. Oops! No, you're correct, the function is *not* properly named in
that case. But the guy who wrote it thought it was.
And before I look at the internals of the function, I don't know whether
it's properly named or not. Worse, the side effects may not show up until
later, and then with disasterous results. Imagine assuming everything's
okay, patching your code into the system, and finding out that it's been
hacking up the customer's filesystem for the last three weeks. All because
you didn't check to see what that other function was
*actually* doing.
Rule: NEVER assume you know what a function is doing by looking at its name.
ALWAYS satisfy yourself that you know what a function is doing by
*looking* at what it's doing.
Paul
--
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com
--
PHP General Mailing List (http://www.php.net/) To unsubscribe, visit:
http://www.php.net/unsub.php
----------------------------------------------------------------------------
-------------------------------
That is WHY you put Function Definitions / Relations
Rick.
--- End Message ---
--- Begin Message ---
Hi,
I've created a first version of LAMP appliance with SUSEStudio that
includes phpmyadmin, webalizer and a bunch of php modules.
I am contacting you because I would love to hear some feedback from
php developers. A part from phpmyadmin and webalizer, what other tools
do you think should be part of the appliance?
I believe using an appliance can make life easier specially for new
php developers, so they don't have to configure anything but start
programming.
You can try the appliance here by clicking on testdrive. Testdrive
will start a new instance of it on your web browser.
http://susestudio.com/a/61bKK8/lamp-server-32bit
You can also download it as livecd, preload iso, vmware, hyperv, disc
image or upload it to your amazon account.
Looking forward to your feedback.
Thanks in advance,
jordi
--- End Message ---
