Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • With folk who live on terminals maximised horizontally, so they end up with 400char wide lines.

    No excuse of course...
    • These are the same people who don't understand what's wrong with 500 line subroutines which do 23 unrelated things.

      • Indeed. I have to be much more careful with advice like "if it doesn't fit on half a screen it's too complex" for folk have a display with more characters than I had pixels when I were a lad :-)
      • The code in the top level post is bad but even if the guy had a normal sized terminal going it still would have been bad code, just easier to see it all.

        My PuTTY session is set up to start at 157 x 60 which after screen is up and running gives me 157 x 58 and fills the entire display. Are you saying that more display real estate equates to bad code?

        People with more display real estate shouldn't be lumped in with the clueless masses who churn out chum. I don't write the 500 line subroutines that do 23 d

        • As a general rule of thumb, I've seen that the longer individual lines of code are, the worse the code quality. However, that's only a rule of thumb and certainly not a hard and fast rule. What's important here is whether a programmer can look at a particular bit of code and understand what's going on. The "larger" the code (wider or taller), the lower the chance of that happening.

          If a programmer is writing code that other programmers will have to work on -- now or in the future -- it's even more imper

          • As a general rule of thumb, I've seen that the longer individual lines of code are, the worse the code quality. However, that's only a rule of thumb and certainly not a hard and fast rule. What's important here is whether a programmer can look at a particular bit of code and understand what's going on. The "larger" the code (wider or taller), the lower the chance of that happening.

            I agree with you; I just wanted to get you to elaborate a bit. :)

            If a programmer is writing code that other programmers will have to work on -- now or in the future -- it's even more imperative to follow reasonable guidelines which most people will accept. A 76 to 80 character width for lines is one of those guidelines :)

            I agree again. This is why we use perltidy with a shared configuration file. No matter who runs perltidy the results will end up looking the same (unless they explicitly override the options on the command line).

          • I hit submit too soon.

            I was fairly certain that you would say something similar to what you actually did. I wanted you to say it though (if that makes any sense to you).

          • I refuse to break my code at unnatural spots just to fit an obsolete limitation. 1024×768 is ubiquitous and permits much wider lines than 80 chars.

            That doesn’t mean I make my lines gratuitously long. I usually stay a good deal below 80 chars, because my code style is generous with whitespace and has plenty of natural breaking points – very deliberately so. Eg. were I to write the exact same code as your example, then each line would be broken before the if, which would follow on an inde