From: Petr Baudis <pasky@suse.cz>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/5] gitweb: Do not use bareword filehandles
Date: Sun, 10 May 2009 09:50:53 +0200 [thread overview]
Message-ID: <20090510075053.GA6058@machine.or.cz> (raw)
In-Reply-To: <200905100236.20158.jnareb@gmail.com>
On Sun, May 10, 2009 at 02:36:19AM +0200, Jakub Narebski wrote:
> The script was using bareword filehandles. This is considered a bad
> practice so they have been changed to indirect filehandles.
> Changes touch git_get_project_ctags and mimetype_guess_file.
>
> While at it rename local variable from $mime to $mimetype (in
> mimetype_guess_file) to better reflect its value (its contents).
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> Perl::Critic::Policy::InputOutput::ProhibitBarewordFileHandles
>
> Write open my $fh, q{<}, $filename; instead of open FH, q{<}, $filename;.
>
> Using bareword symbols to refer to file handles is particularly evil
> because they are global, and you have no idea if that symbol already
> points to some other file handle. You can mitigate some of that risk by
> 'local'izing the symbol first, but that's pretty ugly. Since Perl 5.6, you
> can use an undefined scalar variable as a lexical reference to an
> anonymous filehandle.
>
> See also Damian Conway's book "Perl Best Practices",
> chapter "10.1. Filehandles" (Don't use bareword filehandles.)
>
>
> This follows similar patch for git-send-email.perl by Bill Pemberton
> http://permalink.gmane.org/gmane.comp.version-control.git/117886
>
> CC-ed Pasky, who is responsible for code in both cases...
Yeah, the book I learnt Perl from many years ago used bareword
filehandles (but it was an excellent textbook in most other aspects)
so this is a custom I have to work hard to evict. ;-)
Acked-by: Petr Baudis <pasky@suse.cz>
next prev parent reply other threads:[~2009-05-10 7:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-10 0:03 [PATCH 0/5] gitweb: Some code cleanups (up to perlcritic --stern) Jakub Narebski
2009-05-10 0:05 ` [PATCHv2 1/5] gitweb: Remove function prototypes Jakub Narebski
2009-05-10 9:05 ` Jakub Narebski
2009-05-10 0:36 ` [PATCH 2/5] gitweb: Do not use bareword filehandles Jakub Narebski
2009-05-10 7:50 ` Petr Baudis [this message]
2009-05-10 9:27 ` Jakub Narebski
2009-05-11 1:21 ` [PATCH v2 " Jakub Narebski
2009-05-10 0:38 ` [PATCH 3/5] gitweb: Always use three argument form of open Jakub Narebski
2009-05-11 1:29 ` [PATCH v2 " Jakub Narebski
2009-05-10 0:39 ` [PATCH 4/5] gitweb: Localize magic variable $/ Jakub Narebski
2009-05-10 0:40 ` [PATCH 5/5] gitweb: Use block form of map/grep in a few cases more Jakub Narebski
2009-05-11 0:47 ` [PATCH 0/5] gitweb: Some code cleanups (up to perlcritic --stern) Junio C Hamano
2009-05-11 1:33 ` Jakub Narebski
2009-05-11 4:21 ` Junio C Hamano
2009-05-11 5:13 ` Daniel Pittman
2009-05-11 7:19 ` Jakub Narebski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090510075053.GA6058@machine.or.cz \
--to=pasky@suse.cz \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.