It should be clear in respect to what yields the fastest development and maintenance time for the environment in which you are in, while still maintaining quality. I am specifically being vague about the "who" I am talking about, because it's not about the who, but the concept of maintainable code, and cost effective maintenance.
Yes, some people will have to learn. And foreach() is something specific to Perl, that I think is good. Some concepts in Perl don't exist in other languages. That's a given. And if a new person has to get up to speed, then they will have to take the time to do so. Avoiding the advantages of a language wasn't my point. From way back near the beginning of of the coding practices portion of the thread, what was being singled out was obscure coding; ie. taking 10 lines of code and finding a way to crunch it into one, very difficult to interpret line. It's not a matter of whether Person X or Person Y thinks the code is clearer, but rather whether the department Z, over the number of years the code will need to be maintained, will see it as "clear", where "clear" equals minimized maintenance and development costs. This is not something that can be put into a specific case, as it's more a general measurement. In reference to an individual, it means that the individual doesn't have to spend more time on the same high level concept of execution. If person A spends 5 minutes writing code i, and 6 months later must spend 20 minutes to figure out what he did before changing it, because it was coded obscurely in the first place thats bad. A better scenario would be that Person A spent 8 minutes coding a longer but more clear function, and only 10 minutes 6 months later... especially if in another 6 month the code must be revisted again. I'm sure you know what I am talking about. Trying to pick it down to the nitty gritty really only detracts from the general point. A person (A or B) should make sure that it's pretty easy to figure out what is going on when either they (at a later point) or another person has to go look at the code. It's not about the fundamental syntax, but rather the coding style and standards... things like, indentation, variable names, function names, 1 phrase (ended with semi-colon) per line (maybe a few rare exceptions)... It's about the code being clear, not whether someone knows the syntax. And in a larger situation with more programmers, consistency of that standard across the code is also a good thing (where possible). Heck, I don't even remember how we got down this path from mod_perl not letting Apache start. heh. Cheers, -Alex On Mon, 15 Apr 2002 09:34:23 +1000, Ken Williams wrote: > > I should have been more clear. I think you're supposing that > there's some "lingua franca" in which people can program and all > be understood by each other. I'm proposing that no such thing > exists. Furthermore, there is code such that: > > * Person X thinks code A is clearer than code B, but > * Person Y thinks code B is clearer than code A. > > So who, in that case, do you try to satisfy? The answer simply > depends on what kind of people are going to be working on this > project. Here's a really simple example: > > Code A: > my $i; > my $n = scalar @array; > for ($i = 0; $i < $n; $i++) { > $array[$i]++; > } > > Code B: > foreach (@array) { $_++ } > > Person X: a C programmer with no Perl experience > Person Y: an experienced Perl programmer > > > It sounds like you're in a corporate environment where people > are going to be coming and going, and you can't depend on any > familiarity with Perl. Most unfortunate, but I guess you've > figured out how to deal with it. In other situations, the > strategy would be different. > > > -Ken > > ================================================== Email: [EMAIL PROTECTED] Website: http://www.beardeddragon.org/ ==================================================