Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

Re: Re: do/redo or for(;;): what's Kosher?

by chromatic (Archbishop)
on Jan 04, 2002 at 02:54 UTC ( #136135=note: print w/replies, xml ) Need Help??

in reply to Re: do/redo or for(;;): what's Kosher?
in thread do/redo or for(;;): what's Kosher?

If you have a choice between an idiom and an uncommon construct that will require a comment, go for the idiom. Reading code is a lot more difficult than reading English, and takes a different kind of brainpower. Switching back and forth between the two takes cycles.

I can skim well-formatted and idiomatic code and get the gist of things. If I haven't written it, sometimes I can even pick out bugs that way. If there's no real need to use something different, you're adding maintenance costs for no real gain. Yeah, comments help, but they have a way of being ignored and of becoming obsolete very quickly.

  • Comment on Re: Re: do/redo or for(;;): what's Kosher?

Replies are listed 'Best First'.
Re: Re: Re: do/redo or for(;;): what's Kosher?
by Lord Wrath (Friar) on Jan 04, 2002 at 03:29 UTC
    True, the switching back and forth between english and code takes a gear shift. So in order to have a happy medium, why not make the comment
    #while(1) psuedo-loop
    } #end psuedo-loop
    Seems logical. Therefore, you have the readability and the code is not actually re-evaluating the condition.

    I am currently working in a place where it is common and acceptable for everyone to use their own style if formatting. For example, I make my if like this:
      indented code block
    mostly due to my 2 year job as faculty assistant and grader for my college
    #begin sub-rant
    {as a matter of fact I stopped helping people debug errors in lab if it was not formatted in a similar way since it's so hard to read it}, but I never once criticised a neat way of doing something because it made me think or look at it a second time. I learned many tricks from the students I was supposed to be helping to teach.
    #end sub-rant

    yet many of the people I work with use the format
    if (condition) {
    unindented code block
    and many other variations. It's something I just learn to shift my brain around. I absolutley can't stand to look at these j-builder style formats, but I hafta. So the argument if you don't hafta do something different don't, doesn't hold much with me.

    Besides, the thought of leaving in un-needed processor instructions {for whatever reason, be it not knowing what it is, or just to make my code pretty} starts to remind me of a well documented taboo that is talked about a lot here. I agree that comments are often ignored and so on, but there is a risk we take when trying to standardize a new way of solving things. I'm sure the first case statement was met with people crying how different is was and why don't we just use a lot of if's. Sure, it can be done that way, but maybe the labeled block, or commented block is the right way to have an infinite loop. I mean really, while(1) is probably the most misleading way of doing it, because when is 1 ever != 1, and yet programs all over the globe end in a timely manner. So I say it's all personal choice.

    Lord Wrath
      Comments are evil.

      It's not that you should not comment, for even evil things are necessary, but it is the duty of the good person to avoid doing evil where practical.

      Comments are evil, because they can lie. Code does not lie, it is the ultimate presentation of the truth. Sometimes, the truth can be hard to understand, but it is not wrong, only obscured.

      If you create your loop:

      # while(1) { .. redo }

      Then any maintainer or formatting program can come and change that comment, or the code it supports, with no effect on the functionality of the program. Your testing suite will continue to work, your users will notice no difference, and yet your program contains a lie. This lie can cause no end of grief down the road, as programmers read comments and code alike as the truth.

      It is the duty of the programmer to convey the truth of the program, to both computer and maintainer alike. It is the duty of the language, to convey that truth to the computer in an efficient manner, and to the maintainer in a manner easy to understand. Do not take upon yourself the duty of the language without good cause, you will cause much suffering to the maintainer.

      I think you're wasting way too many brain cycles trying to save CPU cycles. I was heavy into assembly programming for a while and used to be the same way; however at some point your realize that 10,000 clock cycles just aren't worth the 3 hours extra work. If you're really so bent on speed as to mind every last CPU cycle, how did you end up with Perl?

      > #while(1) psuedo-loop
      > {

      Isn't this kind of the worst of both worlds? You have to type out the while anyway, in addition to the redo, and get the horrible maintainability of the naked block you're using. And you also have to maintain all your pseudocode comments to match the actual code. I can't think of any way to make things more awkward.

      To your subrant: smack them over the head if they don't use indentation. I don't care about exact formatting habits like where people put their curlies and whether their else's are cuddled, but indentation is an iron rule.

      while(1) is misleading only to a person who has never seen this idiom before, while it is the most efficient way to signal "infinite loop" to someone who's spent any amount of time writing Perl. Personally, the moment I see that idiom, I know what's going on without even thinking. Learning these idioms is what makes you good at a language.

      Questioning accepted good practice is a good way of thinking; throwing accepted good practice out of the window just for the sake of doing things differently, in your own style, is not. I used to question everything and often went about things my own way. In the end I discovered that I only repeated mistakes others had made before and which had led them to establish those accepted good practices I dismissed. Tradition becomes tradition, because it actually works well, not because everyone just does it that way. Sometimes, straying from it is good; but someone who is too quick to dismiss it will not stay true to his new, "better" rules for long either.

        First of all, I ended up in PERL because I took a job that deals with PERL, and in the current market slump, any job that pays is better than no job at all. I have grown to enjoy PERL, but it is not, and I don't expect it to ever be, my favorite language {ducks the hurled mugs}.

        Second, I don't see how maintaining a naked block is any more difficult than a labeled block. This might be due to my relatively short 8 years as a programmer, but it seems to me the psuedocode comments should pretty well fall into place when writing the loop. In a multi-leveled if structure I am in the habit of labeling most of my close brackets so those who are using editors that do not support matching bracket searches have less trouble debugging. So adding a beginning comment in place of a loop condition and then a comment at the end does not seem like a massive undertaking in my eyes. To some it may, and I guess this entire thread should not interest you and you can continue with your day.

        Third, you said you know what's going on without even thinking. I believe this is the problem with the whole sub-thread we are looking at here. This is no longer about PERL and it's not really even about programming at the root level. Many people will tell you the best way to improve is to make your own mistakes, and that forces you to have a fundamental understanding of the error. When I was in pre-veterinarian classes, my first chemistry class and my first biology class had us doing the most basic experiments possible. This was to help us to learn why the priciples existed, so we did not blindly memorize the work of others and have no real knowledge to make improvements of our own. Now I have been working with DBI for a while now, and many of the old scripts I come accross use ORAPERL. I change them to use the new way. I do not leave them because it used to be the vastly accepted way of doing it. If people did not question the ways things were done, there would be no USA, and I would probably be sitting in one of the English provinces banging away in COBOL and FORTRAN. I approve of all those who question the "accepted" ways, because this shows a person who has not rolled over and died. I refuse to crush the budding creativityof a programmer becuase I might not like the fact he used needless keystrokes to comment a naked block that seemed like a good way to go. I won't even argue that it is the best thing to do, but I will {obviously} defend their right to find out why it is or is not. Besides, your shop standards may be wildly different than mine, so that's why I suggested the monk who asked this question take it to their manager and group who will be maintaining this code. If they see it as good and not confusing then who are we to tell them different.

        Now, not to be stupid or to point out the obvious, but considering the author of this debated loop, and his long list of credentials, and his deep understanding of and link to the language itself, I cannot for the life of me figure out why this is even a matter of dispute.

        Lord Wrath

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://136135]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (6)
As of 2018-06-22 05:59 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (121 votes). Check out past polls.