I'm very much of the opinion that code should be written in the same structure as English: code should read much like prose. We learned English since birth, code is a relatively new development. Changing the rules just leads to confusion.
We read left to right, to to bottom, in a single pass, and we parse sentences for meaning as we read. Unless there's a good reason to the contrary, program structures should follow the same patterns.
This is why, for example, I consider foreach() clearer than map(). Linguisticly, foreach() is simpler.
foreach() says, basically: set pronoun $_ to each of these nouns in turns, and then read the following sentences in the appropriate context. Children deal with pronoun substitution all the time. No problem.
map() does the job backwards. We have first to read each of the sentences, abstract away the meaning of the pronoun $_ without knowing what it means, remember the meaning of the sentences, and then, at the end of the statement, take the memorized meaning of the abstracted sentences we've read, and substitute in each noun for the abstracted sentence. That's harder: we seldom do all that in English.
Why is map() less clear? Well, because it breaks the familair linguistic rules of English. Specifically, it breaks the rule that says I can expect to know what a pronoun means before it's used. When that rule is broken in conversation, many people get confused. For me, the same trait carries over into coding; I'm more likely to get lost if I'm missing expected context.
That distracts me from what I really want to understand: the hows and whys of what's been written, and specifically, why it's right, or what's gone wrong.
As I've argued before, programming (in a professional context) should be considered akin to technical writing: a formally correct document that's transparently understandable to as wide an audience as possible. Writing obscure, beautiful poetry should not be the goal of a technical writer, nor of a professional coder: clarity, correctness, and simplicity should be the order of the day.
Good coding, like good technical writing, is hard work. And like technical writing, it's easy to spot bad code, but harder to identify good code, except by contrast. I don't see the creation of ANSI Perl; Perl's strength as well as it's weakness is the richness of it's feature set. I see the creation of a myriad of fragmented in-house coding standards, and a lot of conflicting style guides.
--
Ytrew Q Uiop
In reply to Re^2: Code Structures
by Anonymous Monk
in thread Code Structures
by artist
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |