Slash Boxes
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

use Perl Log In

Log In

[ Create a new account ]

rjbs (4671)

  (email not shown publicly)
AOL IM: RicardoJBSignes (Add Buddy, Send Message)
Yahoo! ID: RicardoSignes (Add User, Send Message)

I'm a Perl coder living in Bethlehem, PA and working Philadelphia. I'm a philosopher and theologan by training, but I was shocked to learn upon my graduation that these skills don't have many associated careers. Now I write code.

Journal of rjbs (4671)

Wednesday October 08, 2008
07:33 AM

our text editors, our secret masters

[ #37621 ]

Ever wonder how much of our programming style is dictated by our desire to see the right pretty colors? In Perl, I think it's a good bit.

For example, I know that the person who wrote this line wasn't using Vim's default Perl syntax:

Account->q(accountid => $self->{accountid});

...because it would interpret q(...) as a non-interpolative string. Meanwhile, the guy who wrote this was:

$logger->("setting account information to \%info");

...because syntax highlighting told him that %info was a variable, even though Perl doesn't interpolate hashes.

I always put spaces around my range operators, because otherwise in 1..2 the dots are different colors.

Other examples welcome.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • If I have a comment that I want to stand out I use the shebang rule to my advantage (dark blue instead of cyan).
    #!# A very important comment that want everyone to notice
    • I am color weak so that is hard for me to tell so I just use # XXX to have something stand out.

      • Heh. I also use that trick from time to time. That reminds me, I need to modify my Vim config to make '# BUG' stand out in red.
        • I copied the perl syntax file to my .vim directory and tweaked it to highlight bug comments differently. 'BUG' gets colored white on red and the rest of the comment in the normal cyan (if you use the default color scheme).

          [mmusgrove@test perl]$ diff /usr/share/vim/vim70/syntax/perl.vim ~/.vim/syntax/perl.vim
          > syn keyword perlBug                     BUG contained
          < syn match  perlComment           

  • In this:

          //ATTRIBUTE[($NAME="$bckwrd_wf" or $NAME="$bckwrd_ses") and $VALUE="NO"]/$VALUE |

    VS. this:

          //ATTRIBUTE[($NAME="$bckwrd_wf" or $NAME="$bckwrd_ses") and $VALUE="NO"]/$VALUE |

  • The YAML mode in emacs cannot cope with comments containing apostrophes. So I don't write "don't" or "isn't", but "do not" or "is not" ...
  • I've thought about this a lot. For a long time, I avoided chained method calls, like:

    $foo->bar->baz(123, "abc");



    because only the first method was highlighted as such. Some day I discovered perl-mauke.vim [1] which made lots of things better. However, there are still some things I avoid because of Vim. However, that's probably just me. I also avoid modules with names that are not correctly camel-cased (in my understanding), or methods that start with an uppercase letter.

  • A huge pain in the ass for me is that literal barewords for fat commas are falsely shown as keywords.

    foo( reset => 1 );

    Another big one, for me at least, is that all POD blocks should start with =pod, otherwise the relatively simple comment checker in Ultraedit can't handle it.

    • Using a keyword as a bareword is what causes this. I haven't looked into fixing it as I see it as a feature. Try

      foo( bar => 1 );

      and you'll see that bar is treated like quoted text.