Re^4: Module Announcement: Perl-Critic-1.01

[Herkum]

in reply to Re^3: Module Announcement: Perl-Critic-1.01
in thread Module Announcement: Perl-Critic-1.01

I can understand not wanting the code to shout. However, when you are working with special system variables. They are so compact and non-descriptive they can be problematic to identify and debug. Imagine looking at $/ and meaning to use $\, talk about subtle.

English may have code that SHOUTS but it brings attention to itself with the upper-case syntax and is more descriptive than the built-in variable names. There are good reasons why TheDamian recommended its use in PBP.

[xdg]

Imagine looking at $/ and meaning to use $\, talk about subtle

I used to have trouble remembering these until I read somewhere about thinking about them like funnels -- just mentally remove the "S" from the "$".

|/ is a funnel *in* ($/)

|\ is a funnel *out* ($\)

That doesn't change your point about subtle -- it's just the mnemonic I picked up somewhere.

[stvn]

However, when you are working with special system variables. They are so compact and non-descriptive they can be problematic to identify and debug. Imagine looking at $/ and meaning to use $\, talk about subtle.

I suppose a lot of this really depends on how oftern you need to use special punctuation vars. Most of my $work code (medium-large web app) I never use anything other than $@. And the longer version of this (IMHO of course) is just overkill.

English may have code that SHOUTS but it brings attention to itself with the upper-case syntax and is more descriptive than the built-in variable names.

I can understand wanting to bring attention to certain usages of these variables, but not all. With more common variables and usages (like $@) it ends up being a distraction to the visual flow of the code, and drawing attention to an "exceptional" case.