Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Re: A matter of style: how to perform a simple action based on a simple condition?

by sundialsvc4 (Abbot)
on Sep 27, 2010 at 14:11 UTC ( #862219=note: print w/replies, xml ) Need Help??

in reply to A matter of style: how to perform a simple action based on a simple condition?

To me, the only consideration is that:   the code must be obvious and consistent.   Every “shop” will develop “accepted practices,” and the most important thing that you must do is to follow them.   Source code size is not a consideration.   The computer is blisteringly fast.   Disk space is unlimited.   If you can’t type, hire a typist.

Anyone who looks at your code must be able to understand at a glance what it is doing, and their “glance” must be correct.   Remember that people see what they expect to see, as demonstrated by this old chestnut:

PARIS IN THE SPRING,” right?   Look again.

So, “the correct style” is to first find out how your shop is writing such things now, and then to proceed to do it in exactly the same way.   Otherwise, find what is the most abundantly clear way to write it... which is usually not the most brief.

Finally, always consider changes.   The code that you write will one day be changed, probably in a hurry, probably not by you.   Does “a slight change” to your code “break it?”   Especially... does it “break it” in such a way that it no longer works as intended, but also does not produce a syntax-error?   The consequences of any such change can be disastrous.

  • Comment on Re: A matter of style: how to perform a simple action based on a simple condition?
  • Download Code

Replies are listed 'Best First'.
Re^2: A matter of style: how to perform a simple action based on a simple condition?
by BrowserUk (Pope) on Sep 27, 2010 at 16:00 UTC
    Anyone who looks at your code must be able to understand at a glance what it is doing, and their “glance” must be correct.

    Would you expect a non-musician to be able to work out how a piece of music will sound, from "a glance" at the score?

    Or your mother to know the function of a circuit, from a "glance" at a circuit diagram?

    Or a butcher where to cut you, from "a glance" at your head x-ray plate?

    Hopefully, that's taken care of the "anyone" bit.

    Musicians practice endlessly, even when playing a piece they've played hundreds of times before.

    Give a circuit diagram to the most qualified electronics engineer, and ask him what it does, and he'll likely want minutes, if not weeks of deliberation and inspection before he'll offer an opinion.

    And nobody wants a brain surgeon rushing into their head, after "a glance" at the x-ray.

    Beyond the most trivial, computer programs are at least as complicated as all of those. When will programmers stop devaluing their own skills, in the expectation that just anyone should be able to understand the product of hours or days of their effort, "at a glance".

    Source code size is not a consideration.

    This is another obvious sounding aphorism that simply isn't true. Disk space may be dirt cheap, and computers very fast, but computers don't write or modify code. Human beings do. And human beings have limited resources.

    We have limited recall. And limited vision. And one of the effects of that, is that the more spread out the code, the harder it is to grasp an overview of that code. It is this very thing that makes high level languages easier to read, write and maintain than assembler.

    The long, narrow source code layout of assembler with one op-code per line, makes it extremely difficult to maintain a knowledge of what variables are "in scope". And nigh impossible to gain and maintain an overview of what the code is doing. High level languages operate by hiding dozens or even hundreds of op-codes behind each individual line. Thereby allowing the programmer to see the wood for the trees.

    Laboriously and verbosely spreading out the individual elements of a program's structure in the vain ideal that it will make it easier for the uninitiated novice to understand, is like putting big, grippy handles on a scalpel, in the hope that it will make surgery easier for the local car mechanic.

    Programming is hard. It requires learning, skills and practice. It should not be devalued as a blue-collar skill that can be acquired by any walk-in after a 3 day orientation.

    It's a well documented fact that the best programmers are anything from 3 to 10 times as productive as the average. But that productivity does not come from them being able to type at 10x the speed. It comes in large part because they do more with each line of code they write.

    And that has the knock on effect that during maintenance, there is less code to read. It is easier to form the overview, because each screen-full embodies more of the overall picture. Each line enacts one, complete logical step of the high-level algorithm, rather than that logical step being spread out across 5 or 10 lines.

    Yes, each line may require more than "a glance" to understand. But because more logical steps of the full algorithm are visible, the overall flow becomes obvious more quickly.

    And your own example makes the point as clearly as any other. If you write your old chestnut as a single line, rather than spreading it out down the page:


    The flaw ("bug"), becomes obvious.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      /me applauds

      In my perception one of your best answers ever.

      It reminded me of a joke I recently heard (shortened):

      mechanic: why do you pay me $40/hour for fixing your car and you earn $400/hour for fixing a limb? We both deal with internals and complex systems. We both take it apart and put it back again so that it works. brain-surgeon: did you ever try to do so with a running engine?

      Enjoy, Have FUN! H.Merijn

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://862219]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (3)
As of 2021-01-22 00:08 GMT
Find Nodes?
    Voting Booth?