Hatena::Grouphatena

はてな技術発表会日記 このページをアンテナに追加 RSSフィード

株式会社はてなでは日々、開発者が持ち回りでひとつの技術トピックについて発表を行っており、公開可能なものについては、その内容を音声と動画で公開しています。

 | 

2005-11-01

11月01日の技術勉強会

21:30 | 11月01日の技術勉強会 - はてな技術発表会日記 を含むブックマーク はてなブックマーク - 11月01日の技術勉強会 - はてな技術発表会日記

11月01日に行われました技術発表会の内容を撮影した動画ファイルを公開いたしました。内容は以下のとおりです。

テーマPerl::Critic
発表d:id:onishi
時間9:24
ファイルサイズ54,560,778Bytes

以下よりダウンロードしてご覧ください。

http://www.hatena.ne.jp/sound/tech/051101hatenatech.wmv

Perl::Critic::Policy::NamingConventions::ProhibitMixedCaseSubs

Conway's recommended naming convention is to use lower-case words separated by underscores. Well-recognized acronyms can be in ALL CAPS, but must be separated by underscores from other parts of the name.

コンウェイお勧めの命名規則はアンダースコアで切り離された小文字だよ。よく頭文字を大文字にするけど、アンスコで分けたほうがいいよ。

  sub foo_bar{}   #ok
  sub foo_BAR{}   #ok
  sub FOO_bar{}   #ok
  sub FOO_BAR{}   #ok

  sub FooBar {}   #not ok
  sub FOObar {}   #not ok
  sub fooBAR {}   #not ok
  sub fooBar {}   #Not ok

Perl::Critic::Policy::NamingConventions::ProhibitMixedCaseVars

Conway's recommended naming convention is to use lower-case words separated by underscores. Well-recognized acronyms can be in ALL CAPS, but must be separated by underscores from other parts of the name.

変数も一緒だよ。

  my $foo_bar   #ok
  my $foo_BAR   #ok
  my @FOO_bar   #ok
  my %FOO_BAR   #ok

  my $FooBar   #not ok
  my $FOObar   #not ok
  my @fooBAR   #not ok
  my %fooBar   #not ok

Perl::Critic::Policy::Subroutines::ProhibitBuiltinHomonyms

Common sense dictates that you shouldn't declare subroutines with the same name as one of Perl's built-in functions. See perldoc perlfunc for a list of built-ins.

組み込み関数と同じ名前のサブルーチンを宣言しないのは常識だよね。perldoc perlfuncでビルトインの一覧を確認しといてちょ。

  sub open {}  #not ok
  sub exit {}  #not ok
  sub print {} #not ok

  #You get the idea...
参考

Perl::Critic::Policy::Subroutines::ProhibitExplicitReturnUndef

Returning undef upon failure from a subroutine is pretty common. But if the subroutine is called in list context, an explicit return undef; statement will return a one-element list containing (undef). Now if that list is subsequently put in a boolean context to test for failure, then it evaluates to true. But you probably wanted it to be false.

ブルーチンがfailureなときにundefを返すのはかなり一般的だよね。でも、サブルーチンがリストコンテキストで呼ばれた場合、明示的なreturn undefは(undef)を含む1個のリスト要素を返す。ブーリアンコンテキストで失敗したものがtrueと評価されてしまう。ほんとはfalseとなって欲しかったのになあ。

  sub read_file {
      my $file = shift;
      -f $file || return undef;  #file doesn't exist!

      #Continue reading file... 
  }
  #and later...

  if ( my @data = read_file($filename) ){

      # if $filename doesn't exist, 
      # @data will be (undef),
      # but I'll still be in here!

      process(@data);
  }
  else{

      # This is my error handling code.
      # I probably want to be in here
      # if $filname doesn't exist.

      die "$filename not found";
  }

失敗を返したいときは単にreturnと書くこと。そうすれば、コンテキストにより空のリストかundefが返るよ。

  sub read_file {
      my $file = shift;
      -f $file || return;  #DWIM!

      #Continue reading file... 
  }

Perl::Critic::Policy::Subroutines::ProhibitSubroutinePrototypes

Contrary to common belief, subroutine prototypes do not enable compile-time checks for proper arguments. Don't use them.

一般に言われている事に反し、サブルーチンのプロトタイプコンパイル時の引数のチェックを不可能にするんだ。使わないでちょ。

トラックバック - http://hatena.g.hatena.ne.jp/hatenatech/20051101
 |