|Problems? Is your data what you think it is?|
Re^5: Should I leave behind beautiful code or readable code?by BrowserUk (Pope)
|on Apr 02, 2007 at 10:42 UTC||Need Help??|
but spreading that to 3-4 lines and adding the braces definitely makes it easier for me to read.
But the devil is in the detail, hence my question. For example, one of the proposed reformattings (drawn from a post by perrin on the basis that whilst we have long both understood that we differ in these matters, I have, I hope, demonstrated in the past, that I have total respect for his consistancy regarding them.):
Without in any way admonishing perrin for his preference, I do not agree with the motivations behind this transformation.
Restricting myself to the scant information present in the OP, I would code that line as:
I believe that this would perform the same as the original in all circumstances that I have considered, whilst ignoring any potential caveats that are not in evidence in the OP. In other words, if the original formulation was correct, I believe this will also be so.
Now, based on those assumptions, I can see no reasons for breaking this down further, or for spreading it across more lines or statements. It is, to my eyes, clear, concise and readable, and as efficient an implementation as it could be without a much greater understanding of the details of the problem being tackled which could potentially lead to a better algorithm through knowledge of the data or how the results of the code are to be used.
This is a reworking of the original code, but a minor one that avoids the unnecessary generation of an intermediate list that the OP has admitted he had overlooked. It also uses slightly different syntax to the other similar reformulations I've seen. Less brackets or braces perhaps.
It is idiomatic Perl code. It utilises several unique Perl VHLL features.
So you see, I was not suggesting that there was no scope for reformatting the code to improve it's readability, nor that it had to be done in one line or statement as you earlier suggested that you thought I was. I was suggesting that some of the transformations that were being suggested, indeed all of them that I had seen at the point of my posting, were going much to far the other way, and (IMO) for the wrong reeasons.
I was railing against the notion, in vogue here for the last year or so, that one has to eshew idiomatic Perl; to explicitely state everything; break every part of an algorithm down into result = object.action( @arguments ) phrases; in order to write readable, mainainable code. Whether in the form of the chorus of "You don't want to be doing it like that, you must do it like this!" postings here at PM; or in the attempts to make the PBP guidelines enforcable, and mandatory for all; or anecdotal, perfunctory and capricious application of the phrase "unprofessional" to anything which doesn't measure up to the writers personal viewpoint; I find this notion ill-founded, abhorrant and (IMO) just plain wrong.
Of course, as I've tried to diligently indicate throughout this post, these are just my opinions and no one, but no one, is obliged to adopt them without reading my reasoning, verifying my conclusions, and reaching there own. In fact, I strongly urge everyone to do so.
But, much to my surprise, on the basis of the positive response my first post has received, I'm not alone in my thinking that this orthodoxic movement to deprofessionalise idiomatic Perl has become too strong, and it needs to be countered.
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.