Re: [PHP] Function size
On 23 May 2012, at 15:14, Tedd Sperling wrote: Hi gang: 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. You hit upon a theory of mine -- and that is our functions grow in size up to our ability to view them in their totality. When our functions get beyond that limit, we tend to refactor and reduce. I know from the last several decades of programming, my functions have increased in number of lines. But, they have reached a limit that limit is generally about the number of lines I can read in half of my monitor's height. This of course, is dependent on monitor resolution, font-size, and how far I am sitting from the monitor. But I think this is a natural and physical limit that we don't normally recognize. I can cite studies that support my theory. It would be an interesting survey to ask programmers to review their code and provide the average number of lines in their functions AND how many lines of code their monitor's can display. In other words, look at your editor; count the number of lines your monitor can display; estimate the number of lines in your average function; and report the findings. For example, mine is about half -- my monitor can display 55 lines of code and my average function is around 25 lines. YMMV. Interesting, yes? It's a theory, yes, and for many people it may be valid, but it's not for me. The resolution of your screen; the size of your font; the colour scheme you use. These should not be a factor in the way you write your code. If they are then you'll be making decisions for all the wrong reasons. The art of software development is in taking a problem, breaking it up in to bite-size chunks, and putting those chunks together to form a practical solution. Anyone who considers themselves a better programmer because their functions are large due to their ability to handle large functions needs to keep their ego in check. Mental capacity has nothing to do with it. My philosophy for functions is simple... a function does one well-defined, discrete task, and it does it well. The inputs are clearly specified, and the potential outputs/exceptions are fully understood. Sound familiar? These requirements make it incredibly easy to write unit tests for the code. The number of times a function is used does not enter my field of interest. It's irrelevant, as is the number of lines in each function. Following this philosophy does naturally lead to fairly small functions, but as you move up the levels of abstraction they tend to grow larger. For PHP, I consider code in a file that's not within a function to be a function in itself, and the same philosophy applies. 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. Looking at the stats for your code is meaningless, and it's particularly meaningless if you're looking at lines rather than statements, but even then it lacks sufficient meaning to be worthwhile. Shiplu posted a great video on using polymorphism to properly model different behaviours of a base type, and that's great, but for PHP you need to factory in the sizeable speed difference between using a switch statement and using objects. You should never let the elegance of a solution take priority over efficiency. Tony had some curious comments... On 29 May 2012, at 08:52, Tony Marston wrote: 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 DRY principle -- a great principle to observe. However, having functions that are only used once does not violate the DRY principle, in fact in some ways it makes it easier to adhere to it. Also, there is a point to pulling out code that's only used once into a separate function, it's called unit testing, and if you're not doing that then YOU are in the wrong job :) KISS is more important than DRY in my opinion, and KISS should naturally lead to DRY (in most cases). 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. Oh, dear $DEITY, the hardship. Hmm, then again, naming my functions properly will help you with your DRY goals. Hmm. Seriously tho, you've refactored that code into its own function BECAUSE it's doing a discrete task. Naming it should not be
Re: [PHP] Function size
On 29 May 2012, at 14:38, Tedd Sperling wrote: On May 29, 2012, at 7:17 AM, Stuart Dallas wrote: It's a theory, yes, and for many people it may be valid, but it's not for me. The resolution of your screen; the size of your font; the colour scheme you use. These should not be a factor in the way you write your code. If they are then you'll be making decisions for all the wrong reasons. As gifted as you are, you missed the point. I'm don't think I did, but as gifted as you are, I think you missed mine :) At no time did I say that anyone should do anything to the number of lines they write. Quite right, but you did say that your functions have grown in size as the number of lines you can fit on half your monitor height has increased. So on some level you are basing your architectural decisions on that measurement, whether consciously or not. Also, at no time did I say anything about Mental capacity. Quite right, it was Tony who brought that into it. I apologise for mixing it into my general response but I couldn't let it go unchallenged because it's trying to turn it into a pissing contest which is not good for any developer in the ecosystem. My statement was not a recommendation, nor a suggestion, but rather an observation. An observation regarding known limits of human perception and comprehension. It is a known fact that we have short term memory limits -- there have been countless studies on this -- I do not want to belabor the point further. Web promotion has rekindled and advanced this interest. Here are a few contemporary books on the subject (they are all a good read): 1. Don't make me think by Steve Krug 2. Submit Now by Andrew Clark 3. Neuro Web Design by Susan Weinschenk 4. !00 Things by Susan Weinschenk 5. Seductive Interaction Design by Stephen Anderson 6. Designing with the Mind in Mind by Jeff Johnson 7. Rocket Surgery Made Easy by Steve Krug (this is not as important as above, but should be considered LAST) The earliest study I have been able to find on human perception and comprehension limits is: http://symboldomains.com/sperling.html (his study is there) George Sperling laid the basic foundation for this span of apprehension (as he called it) and many are continuing the investigation. I'm familiar with the theories (tho I must admit I hadn't come across that one), and I don't disagree with the general point. As you say there's an abundance of studies that support the idea that we have a limited mental work area. However, I don't think they should factor into decisions about how you organise your code because I see those as extremely subjective. The point I was trying to make (poorly it seems) was that if you follow common software engineering principals, use your common sense and refactor based on the logical way a problem breaks up into pieces, you'll usually end up with the same result. So why make the point? I hear you ask… I think the motivation behind architectural decisions, whether macro or micro, is fundamental. Making those decisions because you can see it all on your screen, or hold it all in your head, or any other I can do this therefore reason has great potential for resulting in code that's difficult for anyone but you to maintain. Let's say you're working on a text-only terminal. Your functions (or groups of logic to be more accurate) are likely to fit within 24 lines. Then you take on a project that's been developed by someone using a 30 monitor in portrait. She can see far more lines at once than you can. In fact she can see lines from multiple files at once. If their code structure has been determined by arbitrary, personal preferences such as how much they can see on the screen at once, their code will be a maintenance nightmare, especially for you on your 24-line terminal. That was the only point I was trying to make. Your observation is not wrong; it makes a lot of sense. However, I don't believe it should be given any further consideration than noting the observation, and you may want to consider what that observation means as far as the overall structure of your code. In essence you are writing more complex functions, because you can which I think is a very dangerous road to be on. As for the rest of your post, but of course, you are correct as you always are. You just missed the point that you are human and thus are subject to the same physical limits as the rest of us. Of course, you are free to think otherwise, but knowing you, the truth will eventually win out. :-) I am human, but we appear to see our limits differently. I see my limits as I'm fallible therefore the simpler I can make my code the more likely it is to behave the way I want, regardless of what level of complexity with which I think I'm capable of working whereas you see it in a similar way to Tony, where your limits are based on how much you can see at any one time. I'm not saying there's a
Re: [PHP] Function size
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. Cheers, tedd _ tedd.sperl...@gmail.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
The art of software development is in taking a problem, breaking it up in to bite-size chunks, and putting those chunks together to form a practical solution. Anyone who considers themselves a better programmer because their functions are large due to their ability to handle large functions needs to keep their ego in check. Mental capacity has nothing to do with it. My philosophy for functions is simple... a function does one well-defined, discrete task, and it does it well. The inputs are clearly specified, and the potential outputs/exceptions are fully understood. Sound familiar? These requirements make it incredibly easy to write unit tests for the code. The number of times a function is used does not enter my field of interest. It's irrelevant, as is the number of lines in each function. Following this philosophy does naturally lead to fairly small functions, but as you move up the levels of abstraction they tend to grow larger. For PHP, I consider code in a file that's not within a function to be a function in itself, and the same philosophy applies. Stuart, Your philosophy is interesting. Of course, a function should have one well-defined and discrete task, but it is not always clear what one task is. Let me take an example of a list. For example, you want to write a function that removes an element from a list. In this example, we will only use this list to remove items from it, so the code required here won't be used another time. Now you have a few possibilities: 1) (This one is probably Tony's approach): Write a single function that searches the element and removes it from the list. 2) (My approach): Write a search function first, even though we're not going to use it elsewhere), then write a delete function that uses the search function to find it and remove it. 3) (Crazy approach ;)): Write a function that gets the next element in the list, write a search function that uses the previous one. Write a delete function that uses the search function, and then calls a function that removes the actual element. With your philosophy all three can fit. The other interesting part in this discussion is the limited mental work area. I assume that this is true, supported by the related studies, makes me feel that we should write code as compact as possible, right? - Matijn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On May 24, 2012, at 5:01 PM, Ashley Sheridan wrote: On Thu, 2012-05-24 at 15:48 -0500, tamouse mailing lists wrote: On May 23, 2012 9:14 AM, Tedd Sperling t...@sperling.com wrote: H Yes, I think that is *exactly* the criterion-- not a mystery or an emergent thing, really, was a pretty expicit reasoning--being able to see/scan the entire function on one page (or now in one screenful) makes it much easier to see what happens in the function, where blocks open/close, and it forces one to break up code into logical units. With the odd exception being where code is more readable in a longer format, as seen with my and several others examples of long functions that rely heavily on switches. -- Thanks, Ash Yep, not everything can it -- there are exceptions. Cheers, tedd _ t...@sperling.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On Wed, May 23, 2012 at 10:14 PM, shiplu shiplu@gmail.com wrote: On Thu, May 24, 2012 at 1:56 AM, Matijn Woudt tijn...@gmail.com wrote: I agree that large switch block are not always easy and useful to split, however, writing too much code inside a switch block isn't considered good practice too IMO. Though, it is unavoidable in some cases I think. I do have some of these functions in my code too, I have one switch block of more than 500 lines, but that's just because I have more than 400 individual case statements, and I don't think there's a better way to do it. Doesn't mean I like it btw. I never encounter such big switch statement in PHP yet. However I saw huge switch and had to optimize it while working with a custom programming language interpreter written in C. When I see the language is OO, I try to apply polymorphic behavior and eliminate any switch statements. Here is a video that demonstrated the concept http://www.youtube.com/watch?v=4F72VULWFvc This is interesting. You do realize that if I would take this switch down to OO, I would have to create 400 different classes to replace this switch statement? Luckily in PHP we can have more classes in a single file, thinking about Java for example would mean I have to create 400 new files... I like the concept, but I don't see how it works for such switch statements. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Function size
My monitor can also display about 55 lines of code, my functions are, on
average, just a few lines of code though -- a maximum of about 20, with an
average of around 5 or so.
This is because the rule of thumb I follow is that a function should do
one
thing, and should be named well. The biggest downside to the type of style
I have is that if not done correctly, people can feel like they're
swimming in a sea of chasing down functions to find out wtf is going on.
When done correctly, it leads to pretty clear code, IMO.
--
Tedd,
I think the length of code depends on a few different factors, what if you
have your docblocks, and comment lines, as well as your bracing style?
Where do you consider your function to start?
Personally, I use this bracing style:
# decide if we should work, or sleep
if($do == $something)
{
# do something here
$work = 'done';
}
else
{
# something isn't being done now
$work = 'sleep';
}
In this (really crude) example, there are 11 lines of code. Granted, the
way you do your bracing you can lose a few lines, and within this example,
it could be written as:
# decide if we should work, or sleep
# default action for if something isn't being done
$work = 'sleep';
if($do == $something) {
# do something here
$work = 'done';
}
So, with that craptastic example, we've taken 11 lines, and compressed it to
7.
Anyways, I get the rule of thumb to be able to fit a function on a
screen, or to make it as small as possible, but sometimes comments can get
in the way, and if you like your bracing style, you end up with a lot of
extra lines of code too (also if you like to have blank lines between
actions).
Anyways, my IDE that I use, shows 47 lines on the screen, at 145 characters
across, using Courier New 9pt, and I try to keep it to 80 characters wide,
but that doesn't always happen :P
Steve.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
Steven Staples sstap...@mnsi.net writes: My monitor can also display about 55 lines of code, my functions are, on average, just a few lines of code though -- a maximum of about 20, with an average of around 5 or so. This is because the rule of thumb I follow is that a function should do one thing, and should be named well. The biggest downside to the type of style I have is that if not done correctly, people can feel like they're swimming in a sea of chasing down functions to find out wtf is going on. When done correctly, it leads to pretty clear code, IMO. -- Tedd, I think the length of code depends on a few different factors, what if you have your docblocks, and comment lines, as well as your bracing style? Where do you consider your function to start? I, and I'm fairly sure many others, do not count docblocks, comment lines, or lines containing only braces in the count for LOC in a function. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On May 23, 2012, at 3:49 PM, Ashley Sheridan wrote: I'm of the same mind. Generally I'll split a function if I'm reusing more than a couple of lines of code. I only split a large function if it's actually doing several things, if it happens to need 200 lines to perform one 'step' then I'll leave it as is. While I do prefer my functions to fit into a single 'screen', it rarely happens quite like that, because I move from screen to screen with different resolutions, so there's no constant limit for me. As a rough example, on a random selection of 27 functions taken from a controller on a site I worked on I get these general statistics: Functions: 27 Mean lines: 22.5 Mode lines: 3 Max lines: 218 The function with 218 lines is a large switch, and it doesn't make sense to do it any other way, because it would actually end up less readable. I see you and I are like minds in many ways. I had one large switch block that had 255 different cases. Oddly enough I was parsing a Tiger data file (USGS survey data) that contained 255 different record types. Each record type required a different function to parse the data and render it's portion of the overall map. That lead to me create a linked-list that held the memory addresses of both data and function. That way simply accessing the linked list coupled data to function and drew the map. It was neat. I find it also neat, while I'm not an expert on the subject, eliminating the need for 'switch' and 'if' statements via extending classes in OO. Shiplu provided a link, which I found interesting: http://www.youtube.com/watch?v=4F72VULWFvc It showed how one can eliminate such conditionals, but at the same time it massively increased the code to preform 1 + 2 * 3. :-) And to others, I don't need comment on how I missed the point -- I didn't. Cheers, tedd _ t...@sperling.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On May 24, 2012, at 8:37 AM, Steven Staples wrote: Tedd, I think the length of code depends on a few different factors, what if you have your docblocks, and comment lines, as well as your bracing style? Where do you consider your function to start? It starts where it starts. It doesn't make any difference how you do it, it's what you see in one view that counts. If you are very verbose with spaces, brace styles, comments, and such, then your functions have less actual statement lines than others with more cryptic coding styles, but I would bet the line limit of total number of lines remain in place regardless. This is more a condition of physical/mental limits on humans than it is on coding style. So, there's no better or worse' point here -- it is more an observation. Cheers, tedd _ t...@sperling.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On Wed, May 23, 2012 at 8:14 PM, Tedd Sperling t...@sperling.com wrote: Hi gang: 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. You hit upon a theory of mine -- and that is our functions grow in size up to our ability to view them in their totality. When our functions get beyond that limit, we tend to refactor and reduce. When number of lines becomes the criteria of function size? Wouldn't it depends on the task the function is doing? I follow this rule, *Each time I end up need a code block I wrote earlier, I convert it to a function. *So simple. This way you re-factor your code automatically and you dont do any copy paste. Last year someone on Stackoverflow asked something like this[1]. And that was my answer. [1] http://stackoverflow.com/a/8597409/376535 -- Shiplu.Mokadd.im ImgSign.com | A dynamic signature machine Innovation distinguishes between follower and leader
Re: [PHP] Function size
On May 23, 2012, at 11:49 AM, shiplu wrote: On May 21, 2012, at 8:32 PM, tamouse mailing lists wrote: When number of lines becomes the criteria of function size? Wouldn't it depends on the task the function is doing? You missed the point. Of course, the difficulty of the task of a specific function will directly contribute to the number of lines of code for that function, but that's not what I was talking about. What I was talking about was that what we can grasp in one view, we can understand better. If the code lies outside of our view, then we understand it less. I can support this claim with numerous articles/books/studies of human visual limits vs short-term memory. I am only bringing this forward for us to consider in our writing code. If we know why we do things, then we can better understand what we do. Cheers, tedd _ t...@sperling.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On 12-05-23 12:15 PM, Tedd Sperling wrote: On May 23, 2012, at 11:49 AM, shiplu wrote: On May 21, 2012, at 8:32 PM, tamouse mailing lists wrote: When number of lines becomes the criteria of function size? Wouldn't it depends on the task the function is doing? You missed the point. Of course, the difficulty of the task of a specific function will directly contribute to the number of lines of code for that function, but that's not what I was talking about. What I was talking about was that what we can grasp in one view, we can understand better. If the code lies outside of our view, then we understand it less. I can support this claim with numerous articles/books/studies of human visual limits vs short-term memory. I am only bringing this forward for us to consider in our writing code. If we know why we do things, then we can better understand what we do. That's why I code in 5px font. On my huge monitor I sometimes find the code is shaped like a tiger, or a dragon, I swear I even saw Piccolo. It really does help to see the big picture :B 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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On Wed, May 23, 2012 at 5:49 PM, shiplu shiplu@gmail.com wrote: On Wed, May 23, 2012 at 8:14 PM, Tedd Sperling t...@sperling.com wrote: Hi gang: 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. You hit upon a theory of mine -- and that is our functions grow in size up to our ability to view them in their totality. When our functions get beyond that limit, we tend to refactor and reduce. When number of lines becomes the criteria of function size? Wouldn't it depends on the task the function is doing? I follow this rule, *Each time I end up need a code block I wrote earlier, I convert it to a function. *So simple. This way you re-factor your code automatically and you dont do any copy paste. Last year someone on Stackoverflow asked something like this[1]. And that was my answer. Hi, While this could be one reason to start a new function, it should not (IMO) be the only reason. Sometimes you can have a large complicated function, with say 200 LOC. While I wouldn't need any of these lines a second time, I usually try to rip blocks of say 50 lines out and put it in a seperate function, so that the main function itself is easier to understand. - Matijn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On May 23, 2012, at 12:21 PM, Robert Cummings wrote: On 12-05-23 12:15 PM, Tedd Sperling wrote: What I was talking about was that what we can grasp in one view, we can understand better. If the code lies outside of our view, then we understand it less. I can support this claim with numerous articles/books/studies of human visual limits vs short-term memory. I am only bringing this forward for us to consider in our writing code. If we know why we do things, then we can better understand what we do. That's why I code in 5px font. On my huge monitor I sometimes find the code is shaped like a tiger, or a dragon, I swear I even saw Piccolo. It really does help to see the big picture :B Cheers, Rob. Forgive me -- I should have know better. This is a bit like talking to my grandkids -- if it doesn't involve dulling crayons, there's no point. :-) Cheers, tedd _ t...@sperling.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On Wed, 2012-05-23 at 20:59 +0200, Matijn Woudt wrote: On Wed, May 23, 2012 at 5:49 PM, shiplu shiplu@gmail.com wrote: On Wed, May 23, 2012 at 8:14 PM, Tedd Sperling t...@sperling.com wrote: Hi gang: 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. You hit upon a theory of mine -- and that is our functions grow in size up to our ability to view them in their totality. When our functions get beyond that limit, we tend to refactor and reduce. When number of lines becomes the criteria of function size? Wouldn't it depends on the task the function is doing? I follow this rule, *Each time I end up need a code block I wrote earlier, I convert it to a function. *So simple. This way you re-factor your code automatically and you dont do any copy paste. Last year someone on Stackoverflow asked something like this[1]. And that was my answer. Hi, While this could be one reason to start a new function, it should not (IMO) be the only reason. Sometimes you can have a large complicated function, with say 200 LOC. While I wouldn't need any of these lines a second time, I usually try to rip blocks of say 50 lines out and put it in a seperate function, so that the main function itself is easier to understand. - Matijn I'm of the same mind. Generally I'll split a function if I'm reusing more than a couple of lines of code. I only split a large function if it's actually doing several things, if it happens to need 200 lines to perform one 'step' then I'll leave it as is. While I do prefer my functions to fit into a single 'screen', it rarely happens quite like that, because I move from screen to screen with different resolutions, so there's no constant limit for me. As a rough example, on a random selection of 27 functions taken from a controller on a site I worked on I get these general statistics: Functions: 27 Mean lines: 22.5 Mode lines: 3 Max lines: 218 The function with 218 lines is a large switch, and it doesn't make sense to do it any other way, because it would actually end up less readable. -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Function size
On Wed, May 23, 2012 at 9:49 PM, Ashley Sheridan a...@ashleysheridan.co.ukwrote: ** On Wed, 2012-05-23 at 20:59 +0200, Matijn Woudt wrote: On Wed, May 23, 2012 at 5:49 PM, shiplu shiplu@gmail.com wrote: On Wed, May 23, 2012 at 8:14 PM, Tedd Sperling t...@sperling.com wrote: Hi gang: 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. You hit upon a theory of mine -- and that is our functions grow in size up to our ability to view them in their totality. When our functions get beyond that limit, we tend to refactor and reduce. When number of lines becomes the criteria of function size? Wouldn't it depends on the task the function is doing? I follow this rule, *Each time I end up need a code block I wrote earlier, I convert it to a function. *So simple. This way you re-factor your code automatically and you dont do any copy paste. Last year someone on Stackoverflow asked something like this[1]. And that was my answer. Hi, While this could be one reason to start a new function, it should not (IMO) be the only reason. Sometimes you can have a large complicated function, with say 200 LOC. While I wouldn't need any of these lines a second time, I usually try to rip blocks of say 50 lines out and put it in a seperate function, so that the main function itself is easier to understand. - Matijn I'm of the same mind. Generally I'll split a function if I'm reusing more than a couple of lines of code. I only split a large function if it's actually doing several things, if it happens to need 200 lines to perform one 'step' then I'll leave it as is. While I do prefer my functions to fit into a single 'screen', it rarely happens quite like that, because I move from screen to screen with different resolutions, so there's no constant limit for me. As a rough example, on a random selection of 27 functions taken from a controller on a site I worked on I get these general statistics: Functions: 27 Mean lines: 22.5 Mode lines: 3 Max lines: 218 The function with 218 lines is a large switch, and it doesn't make sense to do it any other way, because it would actually end up less readable. I agree that large switch block are not always easy and useful to split, however, writing too much code inside a switch block isn't considered good practice too IMO. Though, it is unavoidable in some cases I think. I do have some of these functions in my code too, I have one switch block of more than 500 lines, but that's just because I have more than 400 individual case statements, and I don't think there's a better way to do it. Doesn't mean I like it btw.. - Matijn
Re: [PHP] Function size
On Thu, May 24, 2012 at 1:56 AM, Matijn Woudt tijn...@gmail.com wrote: I agree that large switch block are not always easy and useful to split, however, writing too much code inside a switch block isn't considered good practice too IMO. Though, it is unavoidable in some cases I think. I do have some of these functions in my code too, I have one switch block of more than 500 lines, but that's just because I have more than 400 individual case statements, and I don't think there's a better way to do it. Doesn't mean I like it btw. I never encounter such big switch statement in PHP yet. However I saw huge switch and had to optimize it while working with a custom programming language interpreter written in C. When I see the language is OO, I try to apply polymorphic behavior and eliminate any switch statements. Here is a video that demonstrated the concept http://www.youtube.com/watch?v=4F72VULWFvc -- Shiplu.Mokadd.im ImgSign.com | A dynamic signature machine Innovation distinguishes between follower and leader
Re: [PHP] Function size
I use a lot of switches but they are always small in size because they look
mostly like this:
switch($action) {
case 'hello':
$someObject-executeAction();
break;
case 'world':
$someOtherObject-executeOtherAction();
break;
default:
$this-anotherAction();
break;
}
Maybe it's not the rule for some really specific small functionality which I
know I won't be using ever again, but that's the latest trend I've acquired in
order to improve readability. Personally I find that the particular switch
statement disorders the code, but at least it is a lot better than a lot of
if/elses xD
Haven't you tried this approach or does that particular function do have a lot
of cases?
Greetings.
On 23 mei 2012, at 21:49, Ashley Sheridan wrote:
On Wed, 2012-05-23 at 20:59 +0200, Matijn Woudt wrote:
On Wed, May 23, 2012 at 5:49 PM, shiplu shiplu@gmail.com wrote:
On Wed, May 23, 2012 at 8:14 PM, Tedd Sperling t...@sperling.com wrote:
Hi gang:
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.
You hit upon a theory of mine -- and that is our functions grow in size up
to our ability to view them in their totality. When our functions get
beyond that limit, we tend to refactor and reduce.
When number of lines becomes the criteria of function size? Wouldn't it
depends on the task the function is doing? I follow this rule, *Each time I
end up need a code block I wrote earlier, I convert it to a function. *So
simple. This way you re-factor your code automatically and you dont do any
copy paste. Last year someone on Stackoverflow asked something like
this[1]. And that was my answer.
Hi,
While this could be one reason to start a new function, it should not
(IMO) be the only reason. Sometimes you can have a large complicated
function, with say 200 LOC. While I wouldn't need any of these lines a
second time, I usually try to rip blocks of say 50 lines out and put
it in a seperate function, so that the main function itself is easier
to understand.
- Matijn
I'm of the same mind. Generally I'll split a function if I'm reusing
more than a couple of lines of code. I only split a large function if
it's actually doing several things, if it happens to need 200 lines to
perform one 'step' then I'll leave it as is. While I do prefer my
functions to fit into a single 'screen', it rarely happens quite like
that, because I move from screen to screen with different resolutions,
so there's no constant limit for me.
As a rough example, on a random selection of 27 functions taken from a
controller on a site I worked on I get these general statistics:
Functions: 27
Mean lines: 22.5
Mode lines: 3
Max lines: 218
The function with 218 lines is a large switch, and it doesn't make sense
to do it any other way, because it would actually end up less readable.
--
Thanks,
Ash
http://www.ashleysheridan.co.uk
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
Tedd Sperling t...@sperling.com writes: It would be an interesting survey to ask programmers to review their code and provide the average number of lines in their functions AND how many lines of code their monitor's can display. In other words, look at your editor; count the number of lines your monitor can display; estimate the number of lines in your average function; and report the findings. For example, mine is about half -- my monitor can display 55 lines of code and my average function is around 25 lines. YMMV. Interesting, yes? Cheers, tedd _ tedd.sperl...@gmail.com http://sperling.com My monitor can also display about 55 lines of code, my functions are, on average, just a few lines of code though -- a maximum of about 20, with an average of around 5 or so. This is because the rule of thumb I follow is that a function should do one thing, and should be named well. The biggest downside to the type of style I have is that if not done correctly, people can feel like they're swimming in a sea of chasing down functions to find out wtf is going on. When done correctly, it leads to pretty clear code, IMO. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
