NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
every Perl script that says:
"Don't be stupid."
--Larry Wall
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
You are an idiot (Score:1)
Just look at it:
That’s clearly orders of magnitude easier to read than the Perl version.
Re: (Score:1)
Oh wait, it has to be this:
Or possibly chain the methods.
Perl can’t hold a candle to any of that.
Re: (Score:2)
Re: (Score:2)
Sometimes I worry that the chorus of "Perl, in a Nutshell" will damage Perl's reputation ("it's so easy to write, but it's not always easy to read"). Then I think, if only I could be so lucky!
Re: (Score:1)
No programming language is readable until someone invents a programming language that reads like a native language. Think Pseudo-code, and THAT is readable (or at least you'll get the idea...) However, no-one has made a REAL language like that. Yet.
I've been to
You obviously have a lot to learn (Score:1)
After that you'll understand things like the inherent tradeoffs in commenting. It isn't as simple as "comments aren't done." And it isn't as simple as "comments make things readable." Instead it is much closer to, "comments are helpful but untrustworthy." Which is why there is a big emphasis on making your code (which can be trusted much more since errors there get noticed and fixed) read as much like comments as possible. (Much easier s
Re: (Score:1)
My original comments came from the fact I do black box testing at work, and have recently started to approach the source code. One way I find comments helpful is when they describe what the following function is supposed to do. If I just read through the function (slowly...
Re:You obviously have a lot to learn (Score:1)
The explicit or implicit API presented by a function should not (lightly) be changed. Therefore it is often worthwhile to comment on that. And it is always worthwhile to pick a function name that tells you what it means. However the mechanics of how the function works internally should not generally be commented.
That said, there isn't any magic by which good programmers become magically able to find any code readable. You can probably improve quite a bit from where you are, but there are definite limits. For instance spaghetti is not particularly readable by anyone, and everyone gets slowed by it. Plus with any significant codebase, productivity strongly depends on how well you know your way around it. Being able to find what you want is partly a question of being able to read the code, and partly a question of being able to figure out what code to read. Memory plays a definite role in that process.
So even after you've learned to program well, you'll still have to accept that code will not always be easy for you to read.
That said, the value of good code is that good programmers can become extremely productive with it. They can understand it more easily, make changes faster, the changes are more likely to be correct, and there are fewer unexpected interactions between different parts of the code. Bad programmers also benefit from good code, but they just don't benefit as much, and their changes tend to reduce the quality of the code.
Reply to This
Parent
Re: (Score:1)
Also very important is your knowledge of the problem domain.