http://qs321.pair.com?node_id=631946


in reply to Some thoughts around the "is Perl code maintainable" discussion

As many others already said, it's probably not the TIMTOWTDI that's different to other languages. The difference IMHO is the culture of celebrating that kind of freedom, that scares other people.

And it's a pity that even in todays colorful times most source code has to be shown without syntax highlighting, newspapers, books and even blogs mostly show it black/white.

If there would be more syntax highlighting then people would see how much more expressive and more readable Perl code can be compared to other languages which just don't have the syntactic richness to express different things differently and therefore are not able to color them accordingly.

  • Comment on Re: Some thoughts around the "is Perl code maintainable" discussion

Replies are listed 'Best First'.
Re^2: Some thoughts around the "is Perl code maintainable" discussion
by moritz (Cardinal) on Aug 11, 2007 at 10:17 UTC
    I totally agree on the importance of syntax highlighting. While code should arguably be readable without it, it makes reading far easier.

    That's why I even built my own offline CMS which handles syntax highlighting via Text::VimColor.

    Having regexes built into the language (rather than having a library which generates them from stings) makes it possible to do syntax hilighting for regexes.

Re^2: Some thoughts around the "is Perl code maintainable" discussion
by mreece (Friar) on Aug 12, 2007 at 00:40 UTC
    syntax highlighting is fantastic, and yet i've never seen an editor get it right for perl.

    i've got a number of source files littered with #'#fix vim highlight to give hints to the editor that, no, s|'|"|g; is not the start of a runaway string.

    only perl can parse Perl is the usual mantra. most software can't do it -- no wonder humans have trouble, too. ;-)

      yet i've never seen an editor get it right for perl

      I've been more than happy with emacs's cperl-mode (and mostly happy with perl-mode) syntax highlighting. So IMO emacs gets it right.

        Open up the source of SOAP::Transport::HTTP... does it look OK to you? (Scroll through the whole file)

        Seems really screwed here.

        YMMV.

        -David

      syntax highlighting is fantastic, and yet i've never seen an editor get it right for perl.

      Yep, but then I bet that even perl, which can properly parse Perl, would have some difficulties syntax-highlighting certain kinds of code in a meaningful manner. OTOH most smart enough editors do a decent job on most reasonable and common code. Sometimes you have to trick them or help them in some way. Mine not only helps me with SH, but also does automatic indentation etc. but again in some cases it gets it wrong, e.g. with

      local ($,,$\)=("\n") x 2;
      In this case the closing parenthesis is seen as quoted, and this screws up the following lines of code. Of course using
      local ($\,$,)=("\n") x 2;

      instead prevents the problem, and is also clearer a priori, but it was just to come out with a reasonably "real" enough example.

      Similar situations when here docs are included, even more so if they actually contain code. Then, in the rare situations in which I need to do a string eval, I prefer

      q{ ... }; # or qq{ ... };

      Over simple quotes, since then my editor won't recognize them as strings, but mistake them for code blocks, which is fine in this case. The Right Thing™ would have been... ehm "wrong" in this case.

      In some regexen like the one you mentioned, I overquote inside the regex, just not incur your same problem.

      Oh, and as a minor point, comments are only recognized if there's some whitespace on the left of #. So I always include some, but that's not a big harm since I consider it a good practice anyway. OTOH when I have to comment out big portions of code I use the "indent region" function of the editor itself, which is a big help especially in connection with its "unindent region" companion.

      One thing that is occasionally annoying is the confusion between "multi line" anonymous hashrefs and code blocks: to cope with that I often put parentheses instead, that I substitute with curlies later. Not terribly hard, but... well, annoying.

        > One thing that is occasionally annoying is the
        > confusion between "multi line" anonymous hashrefs and
        > code blocks: to cope with that I often put parentheses
        > instead, that I substitute with curlies later. Not
        > terribly hard, but... well, annoying.

        In my extensions to cperl-mode for Perl6 syntax (and here) I made a Perl6 like distinction between hashes and blocks in a way that no whitespace is allowed before the curlies of hashes. With that the distinction of hashes and blocks generally works better.

        I always use my enhanced variant of cperl-mode also for Perl5 code due to features like this, so maybe you also give it a try.