One things I consider viataly important when writing code, make it readable. Something that are just as valuable in perl as any other language, if not more so given the oportunity to abuse perl.
Avoid side effects, ensure that each line has a specific purpose. Try to ensure that each line performs a single operation. This will save you hours in debugging and maintenence. Likes such as:
return $v[0]->[$h].$h[!!$h].$and[!!($h&&($t||$u))].$v[!(1==$t&&($u+=10
+)&&($t=0))]->[$t].$format{'space'}.$v[0]->[$u];
Should be split into several lines. Why write the code to be so difficult to read?
All in all very clever code, VERY hard to read, consequently its worth is much reduced.
--
Zigster | [reply]
[d/l] |
Or seen "Apocalypse Now" which was based upon Conrad's book.
I basically feel a little like the Marlon Brando character to
zigsters Martin Sheen. Not to say that I'm mad or that Perl and
Perlmonks are akin to savages, far from it. But like the
savages proving more effective than the U.S Special forces,
Perl proves it's worth over programming languages on a daily
basis.
This is one of the first lessons I picked up in a Perl coder
rich environment: Perl is not wholly a scripting language and
not entirely a programming language. As a result it doesn't
sit entirely in the idiom of either. You will concede that
the coding philosophies for these two differ?
I am upset by the slanderous comment about side effects,
if I removed the return from the line of code you've
quoted and relied on the fact that Perl returns the value of
last item used in the sub-routine, then that would be a sort
of side-effect (I prefer to call them features). If you
really mean short-circuits, yes I've used them by the
bucket-load, what of it? Of course
if you dislike Perl's making things easy for you approach, there
are other languages that are also interpretted where you can
spend weeks doing the stuff that Perl does in a day.
I hold my hands up to the comments about all this code going
on one line, so:
return join('', (
$v[0]->[$h],
$h[!!$h],
$and[!!($h&&($t||$u))]
$v[!(1==$t&&($u+=10)&&($t=0))]->[$t],
$format{'space'},
$v[0]->[$u]
);
As to the lousy coding standards in this code. I can only
assume that people have avoided it since ar0n pointed
out that: lhoward has done this already. When I've finished
this I'll be hitting CPAN to study his method. I suspect
some people have refused to comment, from contempt of the
bad style. I concur that it is not nice but it is far from
illegible, some of it is made of Perl 'phrases' or 'clichés'
that I picked up, and after a while you look at and go ah that's a ....
This isn't obfuscation, it's unkempt and written in a style
too terse to be easily maintained 1. but in a
language where the optimisation is a false economy 2.
1.) I am however hoping that the numeric sequence we use won't change
in my life time ;o).
2.) I've done some tests with this, but too few to draw a
positive conclusion, I suspect there are more legible ways,
with less overheads. I'll see what lhoward did.
--
Brother Frankus. | [reply]
[d/l] |
Perl proves it's worth over programming languages on a daily basis.
This is not about one being better than another, this is about programming standards. There are many standards that can be applied to any and all languages. I would certainly not say perl has proved its worth OVER any other language. I as a programmer have a toolbox of languages and techniques to call upon. Perl is a valuable tool in that box.
This is one of the first lessons I picked up in a Perl coder rich environment: Perl is not wholly a scripting language and not entirely a programming language. As a result it doesn't sit entirely in the idiom of either. You will concede that the coding philosophies for these two differ?
I would be interested in hearing what differences you percieve between the two languages. Larry has his own opinions He feels that the difference is meaningless and I agree.
I am upset by the slanderous comment about side effects, if I removed the return from the line of code you've quoted and relied on the fact that Perl returns the value of last item used in the sub-routine, then that would be a sort of side-effect (I prefer to call them features).
Side effects Have specific meaning have a look at Referential Transarancy Avoid side effects in general to improve the resiliance of your code. It is general and good advice IMHO and has nothing to do with perl in specific. It is CERTAINLY not slander, I can only assume you did not understand my comment.
--
Zigster
| [reply] |
