Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

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

by Lord Wrath (Friar)
on Jan 04, 2002 at 01:57 UTC ( #136112=note: print w/ replies, xml ) Need Help??


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

I read through all the responses here, and it seems to me that a couple comments would suffice to reduce confusion on what this block does. Yes, being small makes the example easier to read, but if the real world example is as complicated as you make it out to be, then the condition won't be in view while you are editing it anyway. Now, my question is, why would you even think of re-evaluating the condition over and over again when a
# begin infinite loop
{
  ...
} #end infinite loop
would suffice? Programmers tend to go on and on about how code should be self explanitory and not need comments, but why not toss in a comment and let the darned thing go without a condition? Honestly, when you comment code, it should clear up any questions that might arise, although I believe that this type of thing is not actually confusing, merely it seems to be unfamiliar. I remember the first time I sat down at a terminal and read a B.A.S.I.C. program. Even though it was english-like, it was in no way readable. Then I read another, and a few more, and suddenly GOSUB was not a weird word that some cryptic programmer placed there to confuse me, but a very useful tool. I don't even want to get into the first time I came across a "standard replacement" for the lack of a case statement in perl {scary}. My point is, things that are unfamiliar are not necessarily bad. There are many people who scorn the use of unfamiliar practices, but those tend to be "Seat-Filler", and either refuse to learn new and smoother ways or can't learn at all.

In the interest of having a style, a few comments placed can be a very satisfactory clarifyer to bring coders with different experience {not more OR less} to the same page as you. As for the actual question about it being "acceptable style", the best person(s) to answer that is your Manager or Peer Review Board. If you don't have those, you may be doing this for yourself, or the code is commented well enough to allow for your personal style {borrowed from merlyn or not} to shine brightly. Go forth and code either way.

Lord Wrath


Comment on Re: do/redo or for(;;): what's Kosher?
Re: Re: do/redo or for(;;): what's Kosher?
by chromatic (Archbishop) on Jan 04, 2002 at 02:54 UTC
    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.

      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:
      if(condition)
      {
        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

        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.

        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.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (14)
As of 2014-09-16 18:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (43 votes), past polls