in reply to Perl vs Python revisited

Python will make you write nice code. I call bull on this one. Sure you'll have to indent your loops so they work but that won't make you write nice code. I have a hefty slab of absolutely unreadable UI code sitting in a repository on a university server to prove it.

Indeed. I'm still surprised by how many folks, who don't know either language particularly well, claim that "Python is more readable", or that "Perl looks like line noise" -- to which, I normally reply that Russian is "unreadable" if you don't know Russian.

I sometimes further challenge folks who claim magical code readability powers for Python, to please explain how using Python ensures that they:

That is, far more important than "readability" is "maintainability", so that programmers who know the language can come to the code later in its life and understand its construction and intentions and change it comfortably and confidently.

See also: list of similar Perl v Python questions

Update: See also a later, more comprehensive version of this reply at: Re: Some Help for a Report About Perl (Readability vs Maintainability References)

Replies are listed 'Best First'.
Re^2: Perl vs Python revisited
by BrowserUk (Patriarch) on Jan 06, 2017 at 22:49 UTC

    I agree with your post, your point, and your list 100%; but I have a question...

    Define "magic number"? Preferably with real examples. Thanks.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    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". The enemy of (IT) success is complexity.
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

      I don't see a huge benefit in nailing down a precise definition of what is, and what is not, a magic number. We don't have hard and fast rules about magic numbers at work. Zero and one, for example, will usually survive a code review (though perhaps not if used with bools). There is room for common sense, negotiation and programmer discretion. The focus is on simplicity, clarity and maintainability.

      For example, a magic number like 7.4269 that may change in the future being sprinkled all over the place would not survive the review; you'd be asked to choose a meaningful name for it, $customer_interest_rate for example. Even if the number is PI, and so won't ever change, the code will usually be clearer if you use $pi rather than 3.14159.

      To be honest, I don't feel strongly about magic numbers and can't ever remember them being a big issue during a code review. There are bigger fish to fry, things like:

      • Is the component testable in isolation?
      • Is the component interface well-designed?
      • Has the programmer gone berserk with unnecessary cleverness?
      • Is there a coherent error handling policy?
      • Are there gaping security violations?
      • Is the program easy to support and troubleshoot remotely?

      Obligatory references:

[reply]
[d/l]
[select]
        I don't see a huge benefit in nailing down a precise definition of what is, and what is not, a magic number.

        Fair enough. My personal criteria is that a number used once, is just a number. Used more than once -- to represent the same value -- it should be a symbolic constant or enum.

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        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". The enemy of (IT) success is complexity.
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      A reply falls below the community's threshold of quality. You may see it by logging in.

      You've already got the answer you wanted, but an amusing (to me and one workmate at least, although not amusing to another) example may be appreciated.

      A workmate and I were working through refactoring and understanding some code (C++, but not really relevant to the story) that another workmate had written. The code concerned used circular buffers at the end of a calculation chain for feeding samples into a digital to analog converter. Getting the size of the buffer right is a critical part of making the system work correctly. We encountered a few lines that were used to configure the buffers and looked something like:

      mOutBuffer = CreateBuffer(baseBufferSize+3*2*k10HzKneeSampleBufferSize
+);

      [download]

      We couldn't figure out what the 3 * 2 was doing in there and there were no comments to give any clue so we changed it to:

      #define PI 3.1415 // Circular buffers

mOutBuffer = CreateBuffer(baseBufferSize + 2 * PI * k10HzKneeSampleBuf
+ferSize);

      [download]

      which we at least thought amusing. We hoped that the other workmate would appreciate the joke then provide some sort of sensible name for the constant and perhaps a useful comment. Instead, at the next scrum he noted that someone had added a PI constant "probably they thought it was amusing" and it wasn't right!

      Sadly the PI constant is still in the code and we still don't really know why that particular value is used. There was no doubt a clue in the value being written as 3 * 2, but it escaped us.

      So, that's a classic magic number. It's critical to correct operation of the code, but provides not obvious rational for its selection.

      And if you read a little friction in the team between the lines, you are right. The person who wrote that part of the code is very bright, but I think he has trouble appreciating that not everyone understands stuff in the way he does.

      Premature optimization is the root of all job security
[reply]
[d/l]
[select]

        Nice example. Thanks.

        (Now you've got me sitting here wondering: Is it 2 channels (stereo) and 3 byte (24-bit) samples? And also wondering; did anyone actually ask him :)

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        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". The enemy of (IT) success is complexity.
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[reply]

In Section Meditations