[PHP] Re: Function size
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
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
Re: [PHP] Too many arrays! My head is exploding!
On 29 May 2012 18:15, Gary wrote:
> Okay, let's assume I have three "things", A, B, and C. I need to produce
> an array with a list of all possible combinations of them, however many
> there might be in those combinations: e.g. A, B, C, D, AB, AC, AD, BC,
> ABC (not sure if I've missed any!). Normally I'm pretty good at working
> this stuff out, but to be honest I'm struggling with this one, at least
> to do it in any kind of elegant way. Does anyone have any ideas?
>
> Idealy what I'd like is a multidimensional array depending on the number
> of "things" in the combination. Something like:
> array(2) {
> [0]=>
> array(3) {
>[0]=>
>array(1) {
> ["name"]=>
> string(7) "A"
>}
>[1]=>
>array(2) {
> ["name"]=>
> string(5) "B"
>}
>[2]=>
>array(2) {
> ["name"]=>
> string(4) "C"
>}
> }
> [1]=>
> array(...) {
>[0]=>
>array(2) {
> ["name"]=>
> string(13) "A+B"
>}
>[1]=>
>array(2) {
> ["name"]=>
> string(12) "A+C"
>}
> (etc.)
>
>
>
If you are using linux, you can use the following:
$a = shell_exec("echo {a,b,c,d} && echo {a,b,c,d}{a,b,c,d} && echo
{a,b,c,d}{a,b,c,d}{a,b,c,d} && echo {a,b,c,d}{a,b,c,d}{a,b,c,d}{a,b,c,d}");
This will give you one line for 1 character combination, 1 line for 2
character combination and so on. You can then use explode to convert each
line to arrays.
Thanks,
Vikash
> --
> GaryPlease do NOT send me 'courtesy' replies off-list.
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP] Too many arrays! My head is exploding!
Le 29/05/2012 14:45, Gary a écrit :
Okay, let's assume I have three "things", A, B, and C. I need to produce
an array with a list of all possible combinations of them, however many
there might be in those combinations: e.g. A, B, C, D, AB, AC, AD, BC,
ABC (not sure if I've missed any!). Normally I'm pretty good at working
this stuff out, but to be honest I'm struggling with this one, at least
to do it in any kind of elegant way. Does anyone have any ideas?
Idealy what I'd like is a multidimensional array depending on the number
of "things" in the combination. Something like:
array(2) {
[0]=>
array(3) {
[0]=>
array(1) {
["name"]=>
string(7) "A"
}
[1]=>
array(2) {
["name"]=>
string(5) "B"
}
[2]=>
array(2) {
["name"]=>
string(4) "C"
}
}
[1]=>
array(...) {
[0]=>
array(2) {
["name"]=>
string(13) "A+B"
}
[1]=>
array(2) {
["name"]=>
string(12) "A+C"
}
(etc.)
--
GaryPlease do NOT send me 'courtesy' replies off-list.
Enjoy !
function combinations($letters) {
$combinations = array(array());
foreach ($letters as $letter) {
foreach ($combinations as $combination) {
$combinations[] = array_merge($combination, array($letter));
}
}
return $combinations;
}
print"";print_r(combinations(array('a','b','c')));print"";
outputs :
Array
(
[0] => Array
(
)
[1] => Array
(
[0] => a
)
[2] => Array
(
[0] => b
)
[3] => Array
(
[0] => a
[1] => b
)
[4] => Array
(
[0] => c
)
[5] => Array
(
[0] => a
[1] => c
)
[6] => Array
(
[0] => b
[1] => c
)
[7] => Array
(
[0] => a
[1] => b
[2] => c
)
)
--
Florian Lemaitre
Développeur Web -- Cellule Edition Web/Publishing
Ligne directe : +32 69 250 554
Nos sites :
www.Potoroze.com le portail de shopping mode
et beauté
www.Flash-Promos.com le portail des codes
promos
_www.LaFriperieduCoin.com _ le
spécialiste des petites annonces mode gratuites
/Pôle Digital//, Evolution S.A/
12 rue des sablières, ZI Tournai Ouest II, 7503 Froyennes - BELGIQUE
Fax: +32 69 221 122
www.evolutioncom.eu
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 ba
Re: [PHP] Too many arrays! My head is exploding!
On 29 May 2012 18:15, Gary wrote: > Okay, let's assume I have three "things", A, B, and C. I need to produce > an array with a list of all possible combinations of them, however many > there might be in those combinations: e.g. A, B, C, D, AB, AC, AD, BC, > ABC (not sure if I've missed any!). Normally I'm pretty good at working > this stuff out, but to be honest I'm struggling with this one, at least > to do it in any kind of elegant way. Does anyone have any ideas? Sure, but what you are asking for is a permutation and not a combination. Here's a good read on the subject: http://www.mathsisfun.com/combinatorics/combinations-permutations.html Here's the deciding difference: * If the order doesn't matter, then it's a combination. * If the order does matter, then it's a permutation. A combination of ABC is ABC. However, the permutation of ABC is: ABC ACB BAC BCA CAB CBA Oddly enough, a "combination lock" is a misnomer -- it should be a "permutation lock" because the order of the "combination" does matter. In any event, here's the code for as large a permutation as you may want: http://www.webbytedd.com/b1/permutation/ 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] Too many arrays! My head is exploding!
On Tue, May 29, 2012 at 10:55 AM, Tedd Sperling wrote: > On 29 May 2012 18:15, Gary wrote: > >> Okay, let's assume I have three "things", A, B, and C. I need to produce >> an array with a list of all possible combinations of them, however many >> there might be in those combinations: e.g. A, B, C, D, AB, AC, AD, BC, >> ABC (not sure if I've missed any!). Normally I'm pretty good at working >> this stuff out, but to be honest I'm struggling with this one, at least >> to do it in any kind of elegant way. Does anyone have any ideas? > > Sure, but what you are asking for is a permutation and not a combination. His example seems to suggest order does not matter (I've omitted 'D', which I suspect was a typo given the set of A, B, and C): A B C AB AC BC ABC If order did matter, he would have included BA, etc. That all said, combinations typically involve a consistent number of choices, and his example includes various ranges of r. These would be combinations for r = 1: A B C These would be combinations for r = 2: AB AC BC This would be the combination for r = 3: ABC What it seems like he's after is the power set of set ABC (minus the empty set): http://en.wikipedia.org/wiki/Power_set Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com -- 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 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] Too many arrays! My head is exploding!
On May 29, 2012, at 11:41 AM, Adam Richardson wrote: > On Tue, May 29, 2012 at 10:55 AM, Tedd Sperling wrote: >> On 29 May 2012 18:15, Gary wrote: >> >>> Okay, let's assume I have three "things", A, B, and C. I need to produce >>> an array with a list of all possible combinations of them, however many >>> there might be in those combinations: e.g. A, B, C, D, AB, AC, AD, BC, >>> ABC (not sure if I've missed any!). Normally I'm pretty good at working >>> this stuff out, but to be honest I'm struggling with this one, at least >>> to do it in any kind of elegant way. Does anyone have any ideas? >> >> Sure, but what you are asking for is a permutation and not a combination. > > His example seems to suggest order does not matter (I've omitted 'D', > which I suspect was a typo given the set of A, B, and C): Ahhh yes, he said AB, AC, BC, and ABC, but not AB, BA, AC, CA, and so on. I stand corrected. 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
> 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] Re: Function size
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 -- 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] Re: Function size
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
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] Re: Function size
On Tue, May 29, 2012 at 11:06 PM, Paul M Foster 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
--
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
