php-general Digest 30 May 2012 14:04:33 -0000 Issue 7832
Topics (messages 318024 through 318030):
Re: Function size
318024 by: Paul M Foster
318025 by: Ashley Sheridan
318026 by: Tedd Sperling
318027 by: Paul M Foster
318028 by: Matijn Woudt
318029 by: Robert Cummings
318030 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 ---
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.
OMG in alpha order?! At best, I might group them together by function
type, with some comment notation in the file. But not alpha order. I
prefer not to have "forward declares" in my files, so I generally
arrange functions so that those called by other functions later are
defined before they're called. (Probably a holdover from my C days; PHP
doesn't care.)
No offense. I never even thought about arranging functions in
alphabetical order. But I don't think I'd do it.
> - 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.
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 M. Foster
http://noferblatz.com
http://quillandmouse.com
--- End Message ---
--- Begin Message ---
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.
>
> OMG in alpha order?! At best, I might group them together by function
> type, with some comment notation in the file. But not alpha order. I
> prefer not to have "forward declares" in my files, so I generally
> arrange functions so that those called by other functions later are
> defined before they're called. (Probably a holdover from my C days; PHP
> doesn't care.)
>
> No offense. I never even thought about arranging functions in
> alphabetical order. But I don't think I'd do it.
>
> > - 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.
>
> 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 M. Foster
> http://noferblatz.com
> http://quillandmouse.com
>
I agree there is a certain amount of "let's make this in a cool way so
the next guy is dazzled" but after they come across stuff from the guy
before them it's soon curbed!
And yeah, alphabetical order? Really? 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.
--
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On May 29, 2012, at 5:06 PM, Paul M Foster wrote:
>
> 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.
That's not kewl to me.
> 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
Same here.
Cheers,
tedd
_____________________
tedd.sperl...@gmail.com
http://sperling.com
--- End Message ---
--- Begin Message ---
On Tue, May 29, 2012 at 11:56:47AM -0400, Tedd Sperling wrote:
> On May 29, 2012, at 10:20 AM, Stuart Dallas wrote:
>
> > -snip- Besides, truth is subjective, but then so is everything,
> > including that assertion.
> >
> > -Stuart
>
> You reply was longer than my monitor was high so I can't give an
> immediate reply -- I have to scroll. :-)
>
> However, with that said, you made good points and I don't disagree
> with any of them.
>
> As for me, I was speaking from my experience where the size of my
> functions over the last few decades has grown (up to a point) with my
> increasing monitor size. However, my eyesight has not improved and
> thus should be figured into this somehow.
>
> As I said before, mine is just an observation that supports the limits
> in reception/comprehension articles I have read.
>
> I think your 24 line terminal vs the 30" monitor argument is a valid
> one, up to a point. But I think the problems (if any) would depend
> upon many factors -- too numerous to elaborate here.
>
> But let me pose an idea.
>
> When I was in college, my degrees were in Geology. My Summer Field
> study (6 weeks) was to map out Geologic outcrops on a USGS topographic
> map. At the end of the study, all maps that matched the Professors'
> maps, were given the highest grades (mine the highest in all modesty).
> Not because they were alike, but because they approached the "truth"
> of the matter. The truth here was not subjective for there was only
> ONE defining truth and that could be discovered by detailed mapping.
> We all (including the Professors) approached the same problem in the
> same way and reached similar results. The closer to the truth, the
> more similar the maps.
>
> Over the years I've seen programming languages converge producing
> single solutions for common tasks, such as a FOR loop and IF
> statements. These seem to be universal constructs in programming
> logic. So my question is, as in my Geology study "Is this convergence
> in programming logic discovering the truth of the task?" Do you see
> what I mean?
>
> If so, then maybe the way we break down problems into smaller subsets
> might also be approaching an optimum method as well. I used to use
> (30+ years ago): 1) Input; 2) Calculation; 3) Display; as the main
> categories in my division logic to tackle problems and that was long
> before I heard of MVC.
>
> So, what I am saying is that we might all be approaching and
> contributing to an overall optimal logical solution in programming.
> Kind of an ant-colony think sort of thing. The solution is certainly
> not simple, but it might be an universally single solution to all the
> problems we perceive.
>
> Said only for "Food for thought".
About 30 years ago, a guy wrote an essay about "architectural
stablization" or somesuch. He was a computer guy who had written a whole
office suite for 8 bit computers (called Valdocs, written for the Epson
QX-10 computer, for you voracious learners). His point was that this
phenomena was recognizable in many fields involving technology. For
example, the architecture of automobiles eventually stabilized in such a
way that these days, they pretty much all have steering wheels used for
steering, four wheels, two headlights, etc. I think "mainstream"
programming languages have probably done a lot of stabilization over the
years. You do occasionally find weird languages like Lisp/Scheme, but in
the main, most languages bear strong resemblance to C and Fortran.
They're geared for slightly different environments or purposes, but
syntactically, they bear strong resemblance to each other, compared to,
say, APL or Lisp/Scheme. And to some extent they model how most people
(programmers) would naturally approach the solution of programming
problems.
(Of course, there are always the oddballs like me who still prefer
reverse polish notation on our calculators. Go figure.)
Paul
--
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com
--- End Message ---
--- Begin Message ---
On Tue, May 29, 2012 at 11:06 PM, Paul M Foster <pa...@quillandmouse.com> wrote:
> OMG in alpha order?! At best, I might group them together by function
> type, with some comment notation in the file. But not alpha order. I
> prefer not to have "forward declares" in my files, so I generally
> arrange functions so that those called by other functions later are
> defined before they're called. (Probably a holdover from my C days; PHP
> doesn't care.)
>
> No offense. I never even thought about arranging functions in
> alphabetical order. But I don't think I'd do it.
>
Like most of us on this list (I think), I agree with you that
alphabetical order really doesn't make any sense.
>> - 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.
>
> 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();
- Matijn
--- End Message ---
--- Begin Message ---
On 12-05-29 07:17 AM, Stuart Dallas wrote:
>
I wasn't going to respond to this thread because I think it's a largely
> ridiculous topic, but some of the responses have scared me. Sir Cummings
> (hopefully) sarcastic response about using a 5px font size demonstrated
> how daft it is to base function size on how much code you can see on the
> screen at once.
Guilty as charged ;)
One time I was helping a friend of mine do his Java homework at Cornell
and when he got the assignment back he scored 24 out of 25 and I was
like "What?!". The marker subtracted a point for a function that spanned
more than one printed page. What a dork! I guess he didn't like my brace
style since if I'd used a less vertically consumptive style then it
would have printed cleanly on one page *lol*.
Cheers,
Rob.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.
--- End Message ---
--- Begin Message ---
"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?
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.
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.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
--- End Message ---
