cloc-git: リモートの git リポジトリのコード行数を数える

#はじめに
[stackoverflow のこちらの質問](http://stackoverflow.com/questions/26881441/can-you-get-the-number-of-lines-of-code-from-a-github-repository)への回答として紹介されていた cloc-git が便利でしたので、大変僭越ではございますがこちらにメモを残させていただきます次第でございます


#前提条件
万能な loc カウントツールの **cloc** を事前にインストールしておきます

```bash:
brew install cloc
```

これだけでも、ローカルなフォルダを指定して、例えばカレントディレクトリで

```bash:
cloc .
```

とかすると

```bash:
cloc .
     131 text files.
     122 unique files.                                          
      14 files ignored.

http://cloc.sourceforge.net v 1.64  T=0.78 s (151.8 files/s, 18400.4 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
CSS                              6            985             70           6193
HTML                            94             34             18           3509
Javascript                       6            529            334           1323
PHP                             11            193            197            810
Perl                             1              0             40            179
Bourne Shell                     1              0              6              2
-------------------------------------------------------------------------------
SUM:                           119           1741            665          12016
-------------------------------------------------------------------------------
```

と、言語別に loc が表示されてエンピリカルな開発ライフが一気に進んでクオリティやプロダクティビティを定量的に自己評価できる今風のエンジニアに進化してしまいます。ポケモンの飴みたい

マネージャーの立場でスタッフのクオリティとプロダクティビティを loc だけでマイクロマネージしようとすると少し角が立ちますので自重したいです

# cloc-git
## 概要
cloc でローカルなフォルダの loc が計測できるのであればリモートなリポジトリの loc は

1. 対象のリポジトリを clone する
2. clone したフォルダの loc を計測する
3. 計測し終わったらファイルを削除する

これでできる理屈です。わかりやすい
自然言語でわかりやすい理屈ですが、実際に動いた実績のあるスクリプトをシェアしてもらえるとさらに本当にありがたいものです。論よりコード

[前述のstackoverflow](http://stackoverflow.com/questions/26881441/can-you-get-the-number-of-lines-of-code-from-a-github-repository) で紹介されていたのはこんなスクリプトです

```bash:cloc-git
#!/usr/bin/env bash
git clone --depth 1 "$1" temp-linecount-repo &&
  printf "('temp-linecount-repo' will be deleted automatically)\n\n\n" &&
  cloc temp-linecount-repo &&
  rm -rf temp-linecount-repo
```

--depth 1 しらなかった、こういう所でつかうんですね

## インストール
このファイルに実行権限をつけて

```bash:
chmod a+x cloc-git
```
パスの通っているフォルダ、例えば /usr/local/bin とかに置くと

```bash:
sudo mv cloc-git /usr/local/bin
```

出来上がりです

## 実行してみる
この一年、ガシガシと機能追加してきた自分のリポジトリの loc をちょっと((o(´∀｀)o))ﾜｸﾜｸしながら見てみます

```bash:
MBA:130115 takeyuki$ cloc-git https://github.com/UedaTakeyuki/slider
Cloning into 'temp-linecount-repo'...
remote: Counting objects: 58, done.
remote: Compressing objects: 100% (47/47), done.
remote: Total 58 (delta 8), reused 33 (delta 3), pack-reused 0
Unpacking objects: 100% (58/58), done.
Checking connectivity... done.
('temp-linecount-repo' will be deleted automatically)


      52 text files.
      52 unique files.                              
      11 files ignored.

http://cloc.sourceforge.net v 1.64  T=0.34 s (127.7 files/s, 6674.9 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Python                          24            281            430           1259
Bourne Shell                    19             44             69            165
-------------------------------------------------------------------------------
SUM:                            43            325            499           1424
-------------------------------------------------------------------------------
```

1.4K ... orz

あ、これは UI がないロジックだけのコードなんで、^^;;; ビシバシと UI 作り込んで、データストリームの処理まで工夫していれたサーバ側はきっと凄い loc になってるに違いない

```bash:
MBA:130115 takeyuki$ cloc-git https://github.com/UedaTakeyuki/monitor
Cloning into 'temp-linecount-repo'...
remote: Counting objects: 46, done.
remote: Compressing objects: 100% (42/42), done.
remote: Total 46 (delta 5), reused 25 (delta 0), pack-reused 0
Unpacking objects: 100% (46/46), done.
Checking connectivity... done.
('temp-linecount-repo' will be deleted automatically)


      36 text files.
      36 unique files.                              
      12 files ignored.

http://cloc.sourceforge.net v 1.64  T=0.23 s (109.7 files/s, 8677.1 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
PHP                             18            225            545           1028
Python                           3             26             27             61
Bourne Shell                     2              7             18             19
JSON                             1              0              0             16
Javascript                       1              0              0              5
-------------------------------------------------------------------------------
SUM:                            25            258            590           1129
-------------------------------------------------------------------------------
```

1.1K .........

私のプロダクティビティってそんなもんだったのか...

いや、コードがコンパクトな分、品質も保守性も保たれている筈...

うちの仏さんは小さいけど心が篭ったはる...

# 感想
今年もボケーっとしてたら[git の Advent](http://qiita.com/advent-calendar/2016/git)に登録しそこなってしまいました[^1]。皆様の記事を勉強させていただき、大変参考にさせていただいております事、この場をおかりしましてお礼申し上げます

# references
- [Can you get the number of lines of code from a Github repository?](http://stackoverflow.com/questions/26881441/can-you-get-the-number-of-lines-of-code-from-a-github-repository) 元記事です
- [コマンドラインツールであらゆる言語が使われていても行数を測定する](http://qiita.com/GeneralD/items/c4351f42d0a441373033) 具体的でわかりやすい cloc の紹介記事です
- [git リポジトリの最新の履歴だけを取得する shallow clone](http://qiita.com/usamik26/items/7bfa61b31344206077fb) --depth 1 知りませんでした、勉強になりました事、感謝いたします

# glossary

- **LOC(Line of Code)**: コード行数、批判もあるけど数えやすいので便利なソフトウェアメトリクス。規模を大雑把に捉うのに便利なので、コードベースの品質やエンジニアの生産性を大雑把に評価したいときに便利です

- ***エンピリカル(empirical)***: 実証論、theoretical の反対語。品質や生産性についての RQ(Research Question) を software artifacts の metrics などから実証しようとする研究手法が empirical study と呼ばれて流行ったことがございました




[^1]: 去年は RPi の Advent に登録しそこないました。我ながらトロいです...