リーダブルコーディング技術スレ

1 ：2013/10/11 〜 最終レス ：2013/10/26

リーダブルコードとは
・読みやすさ、理解しやすさを追及したコードのことです
・読みやすいということはメンテナンス性も高いということです。
・理解しやすいコードはコードレビューも楽になります。
・理解しやすいコードはバグも少なくなります。
・短いほうが優れていることが多いですが、必ずしも短いほうがいいとは限りません。
俺ルール
・書き方の勝負であり、言語の勝負をしないでください。
・標準、非標準に限らずライブラリを使いましょう。
・なければ自分で関数を作りましょう。関数はなるべく汎用的に。
こういうコードを読みやすくするにはどうすればいいでしょうか？
というようなことを語るスレ。需要ありますかね？

2 ：

コスト感も癖にテストテスト叫ぶガキはまずリーダブルなコード書けてから言えといいたい

3 ：

最近、メインのコードから汎用的なコードを関数化していって
汎用的なコードはまあテストするが、
そうするとメインのコードが凄くシンプルになって、
それをテストするって意味あるのか？って思えてきた。
むしろテストしにくいコードをテストしなくて済むように
複雑なものを極力追いだすというか。そんな感じ。

4 ：

テストコード自体にもリーダブルさは必要だからなぁ。
リーダブルなコードを書けない人間がテストコードを書いても
ごみの集まりにしかならない。
テストのメンテナンスが大変になるだけ。

5 ：

>>1
汎用的なコードの羅列は読みにくい。コードはできるだけ個別的に書くべき。
ライブラリの使用も極力避けるべき。

6 ：

>>2
リーダブルなレス頼む

7 ：

>>5
荒らしは無視ですね。

8 ：

テストが面倒だから、テストしやすいコードを書くと簡潔になるな。
同じテストを繰り返したくないから、DRYの原則を守るようになってたり。

9 ：

>>7
pure Prolog は書き手が書いたことだけが真であって、
読み手との間で誤解の生じる余地がありません。
組込述語(ライブラリ)が無いのですから、個別的であり、
書き手と読み手の間の抽象能力の差から生じる不理解が
生じません。

10 ：

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

11 ：

>>9
問題はそれがリーダブルかどうかです。
試しにライブラリも関数も使わずにMySQLに接続して
select文を発行するコードを書いてみてくれませんか？
リーダブルコードというのは
実用的でなければなりません。

12 ：

例えばPerlでは要素が重複しないリストを返す関数はないわけ。
言語仕様だけで実装すればこんなふうになるけど、
my %count;
@array = grep( !$count{$_}++, @array ) ;
見ての通り明らかに、リーダブルではない。
List::MoreUtilsという有名なライブラリには
これをやってくれる関数がある
@array = uniq @array;
こっちの方が明らかにリーダブル。
実際の開発において、ライブラリを使わずに実装するなんてことは
腐った現場以外ありえない話なので、
リーダブルが目的の現実的な開発ではList::MoreUtilsのuniqを
使うという選択が一番正解なわけだよ。

13 ：

>>11
pure Prologではなく普通のPrologですが、
http://nojiriko.asia/prolog/fukakusa_no_shoushou_1_1.html
のようなコードを念頭に置いています。
あなたが意識されているのは読みやすさではなく実用性ではありませんか。
さすがにPrologからMySQLへのインターフェイスはないと思いますが、あれば、
　　mysql :: かやうに(_かやうに),
のように質問することになるのでしょう。

14 ：

>>13
だから実用性を考えないリーダブルに意味は無いんだって。
読んだってたかが知れてる量だとリーダブルにする意味は無いだろ。
何百、何千行にもなるような実用レベルのコードを
読みやすく構築するのがリーダブルの目標
実用レベルではMySQLを使うのは当たり前の話で
それをライブラリを使わないで書いてもリーダブルといったのはお前じゃんか。
こちとら何百、何千行もあるコードを数行に収めることを目標にしてるんだ。
だから当然ライブラリを使うし、ライブラリを作る他ないだろ。
リーダブルはあくまで実用性を念頭に置いて考えなさい。
サンプル程度の短いコードの話なんて要らないのよ。

15 ：

>>13
横レスする
もしもそのリンク先コードがリーダブルであると主張するならば、
同サイトのPrologで書かれたクイックソートのコード：
　　http://nojiriko.asia/prolog/quick_sort.html
よりも、以下のコードのほうがリーダブルであることを認めねばならない
　　クイックソート [] = []
　　クイックソート (中心軸:残りのリスト) =
　　　　　　クイックソート
　　　　　　　　中心軸未満の部分リスト ++ 中心軸:(クイックソート 中心軸以上の部分リスト)
　　　　ここで
　　　　　　(中心軸未満の部分リスト, 中心軸以上の部分リスト) = リストを分割 (< 中心軸) 残りのリスト
　　リストを分割 関数_f = foldr 関数_g ([], [])
　　　　ここで
　　　　　　関数_g X (部分リスト_Y, 部分リスト_Z) =
　　　　　　　　もし 関数_F x ならば
　　　　　　　　　　(X:部分リスト_Y, 部分リスト_Z)
　　　　　　　　さもなくば
　　　　　　　　　　(部分リスト_Y, X:部分リスト_Z)
なお、ここでは以下を仮定した(関数型言語Haskellを元にする)架空の言語を想定している
・識別子として日本語文字(UTF-8等)が利用できる
・予約語「where」の代わりに「ここで」が利用できる
・構文「if ... then ... else ....」の代わりに「もし .... ならば .... さもなくば ....」が利用できる

16 ：

クイックソートのコードがリーダブルかなんてどうでもよくね？
qsort()
これが一番リーダブルだ。
そう難しいロジックは関数に隠蔽してしまう。

17 ：

>>16
関数抽象を言い出せば、あらゆるプログラムなんて、
program()
これが一番リーダブルだ、ってことになる
つまり>>16は、何も言明していないに等しい

18 ：

なんのプログラムかわからんだろ
頭悪すぎ

19 ：

まったくだｗ
もし>>17みたいなのがあったら、それは一つの関数で
何でもやってるリーダブルではないコードになってるだろうな。
リーダブルってのはバランス感覚が重要。
何を関数にして、何を関数にしないか。その見極めが重要。
優れた技術者は関数を汎用的なものにして
一度作ればメンテナンスを不要なレベルにする。
アプリのライフサイクルにおいて、修正が必要な箇所を極力減らす。
それがリーダブルなコードになる。
ソート関数なんてアプリの機能が変わったとしても、
一度作ればメンテナンする必要は殆ど無い。
だから関数にする。これがバランス感覚というもの。
>>17みたいなのは、結局program()の中をメンテナンスする
必要があるわけでなにも解決していない。

20 ：

それが真実とすると、整数のソート関数を作った後、文字列のソートをしたくなる。
そんな時、テンプレートが使えると理想的。
結果、C++のような変態言語が実は理想なのか？ってなってしまう。

21 ：

>>20
うん、各型ににおいて最速のコードを
生成するならC++が理想的だよ？
別にそこまでパフォーマンスが必要ないなら、
比較関数さえ入れ替え可能にしておけば
どんな型にでも対応できるけど。

22 ：

void*はリーダブルコードなのか？とか新たな疑問がわいてくる。

23 ：

void*でリーダブルかどうかなんて分かるわけがないだろ。
そもそも型であり、コードでないのだから
リーダブル”コード”の範疇外だ。

24 ：

そういうレベルまで下りてくると、関数名を適切に付けましょうとか
その程度の話になってくる。

25 ：

ちなみに俺はfunction_10000()まであと少しだが、十分リーダブル。

26 ：

>>24
重要な事なんだがねぇ。
関数の名前、関数の引数。関数の使い方。
これらがリーダブルコードの大きなカギ。
いかにメンテナンスが必要なコードを
シンプルにかつ柔軟にかけるようにするかを
提供するライブラリの構築は極めて重要な作業。

27 ：

コメントを適切につけましょう。
関数名を適切につけましょう。
当たり前の事をきちんとやりましょう。
以上でスレ終わり。

28 ：

そういう勘所わかんねえガキがすぐ喚き立てるからな。はてなダイアリーwとかツイッターwでな。滅びろガキ共

29 ：

>>28は>>26への共感

30 ：

まず、コードってのは二種類に分かれる。
アプリの仕様の変化によって
メンテナンスが必要なコードと
そうでないコード。
メンテナンスが必要でないコードの例として
フレームワークやライブラリがある。
アプリってのは何千行、何万行ものコードから
なりたっている。そのうちメンテナンスが必要なコードを
極力減らすのがリーダブルコードの重要な点。
メンテナンスが必要ないコードは汎用的であり一度覚えればよく、
中身を見る必要はないか一度だけ見れば良い。
見る必要がないコードが多ければ、コードレビューも楽になる。
見なくて良いコードを増やして、
見なくてはいけないコードを減らしていくのが
大規模アプリをリーダブルにするコツ。

31 ：

>>28
ひとつひとつのツイートをシングルクォートで囲み最後にピリオドを
付ければ、全部 Prolog プログラム。

32 ：

ﾋﾟｺｰﾝ！
関数に分ければ読む必要ないからリーダブル！
program()

33 ：

ソートが必要な場合、sort()に切り分ける。
関数名をわかりやすくsortにしておく。
ここ重要。
中身は知る必要なし。
一目で何をやってるかわかるリーダブルの完成。

34 ：

引数なし戻り値なしの関数の占める割合を見ればわかる

35 ：

>>34
お、それに気づいたか
引数なし戻り値なしの関数が
多いものは読みにくいコードであることが多い。

36 ：

んなもんただのgotoだからな

37 ：

>>15
Haskell風コードの方が当然リーダブルのように思うが、違うのか？

38 ：

>>36
いや、gosubだ

39 ：

インスタンス変数を直接触る関数は自分で書いてて分かりづらいなって思ったからやめた

40 ：

思ったよりおもしろい

41 ：

関数にすると処理があちこちに飛んで見難くなる。
だから関数を使うな。
というとんでもない意見があるが、
100%間違っているというわけでもない。

それは関数＝サブルーチンになっている場合。
コードが長いからという理由だけでその一部分を関数
（という名のサブルーチン）にした所でコードは読みやすくはならない。
なぜなら、関数の中まで読まないと何をやっているかわからないから。
ではなくて、関数というのは中を読まなくてもわかるようにするべき。
標準ライブラリの関数とか通常の開発で中を読むことはまずない。
中を読まなくていいということは、その分読む量が減るということ。
サブルーチンにした場合、その中を読まなくていいということはまずないので、
結局、あちこちに飛んで見難くなるだけ。
正しい関数の作り方を知らないからこうなる。

42 ：

1箇所からしか呼ばれないものは関数化しない、という方針は、そんなに間違ってもいないが、
絶対でもないぞ。
極端な話、初見では少々読みづらいコードになったとしても、上位レイヤと下位レイヤに
分けて実装しないと、あとあと全体の構造がメンテ不能になったりすることもある。

43 ：

>>42
レイヤ分けも「中を読まなくていいようにする」行為の一つだよ。
正しいレイヤ分けをしていれば、引数と戻り値のみがわかっていれば
そのレイヤで何を行うのかわかってるので、中のコードを読む必要がなくなる。
関数にするときは、中を読まなくていいように
なっているかどうかを意識しよう。
中を読まないといけない状態では
リーダブルにはならないことが多い。

44 ：

標準ライブラリ関数のソースは読まないけど、ドキュメントは読まないと使えないよね
>>41のいう"正しい関数の作り方"をすれば、それすらも必要ないの？
それとも、コメント書いとけっていうことを、わざわざ長文にして書いたの？

45 ：

>>44
ドキュメント≒コメントな。
同じようにコメントがあったとしても、
コードを毎回のように読まなくてはいけないものと
コードを（初回レビュー以外）読まなくても大丈夫なもの
二通り有るだろ？

コードを読まなくても大丈夫なものは、
標準ライブラリの関数などのように、
それ自体の役目が小さくサブルーチン（処理のまとまり）ではなく
しっかりと関数になっているもの。
サブルーチン（処理のまとまり）なんかだとコメントが有ったとしても
結局コードを読まないと、具体的なことは何もわからない。
どんな時だって、コメントがあれば問題解決するわけじゃないんだよ。
関数の中を毎度毎度読んでるようなら、
それは関数ではなくサブルーチンになっているということさ。
そういうのを減らせと言ってる。

46 ：

>>45
>コードを毎回のように読まなくてはいけないものと
>コードを（初回レビュー以外）読まなくても大丈夫なもの
>二通り有るだろ？
コメントでカバーできないような関数にはするなっていうこと？

47 ：

>>46
読まないといけないコードを減らして
読まなくても良いコードに置き換えろということ。
読まなくても良いコードの割合が増えれば
それだけコードレビューの時間も減る。

コメントでカバーとかそういう発想をそもそもしていない。
コメントがなくてもコードでわかるのであれば、コメントすら不要。
コメントを書きたくなる時点で、コードがリーダブルでないという証拠でしかない。

48 ：

つまりは　なでしこで書かれたプログラムが
一番リーダブルなんじゃね？

49 ：

噛み合ってないスレ

50 ：

関数名と言うのは、巧いコードだと処理の概要を物語るコメントとしても機能する。
例えば void BubbleSort( int *p, int n ) という関数が何をするのかは容易に推測できる。
(ただしこんな名前でクィックソートしてるなら糞コードだが。)
一方、下手なコードだと関数名は単なる識別子としてしか機能しない。
内部で何をやっているかは関数内のコードやコメント、ドキュメントを追う必要がある。
例えば　void HogeMoge() という関数が何をするのかは中身を見なければまず分からない。
と書いてみる。

51 ：

他人のコードを読む難しさは、”作者が暗黙にイメージしてる図”を推論することの難しさにある。
f(x+d) - f(x) / d
作者自身は「これは微分するためだ」という暗黙のイメージがあるので簡単に理解できる。
一方、他人はコードのみから「これは微分が目的か？」と推論する必要がある。
コードを推論だけで読むには、作者と同等かそれ以上のコードを書けるだけの基礎が必要となる。
これら推論を補助するには、ホワイトボードによる図説が有効である。
イメージ図が有ると無いとではコード理解の難易度が大幅に変わる。

52 ：

>>51
それこそ、 >>26 が言っている関数名の付け方の問題で、
関数名を xxxを微分する() にすれば良い。微分という
概念なら共有できるのだとすれば。
問題はこのように概念化、言語化できない(し難い)アルゴリズムの
場合、関数名では解決できないケースがあること。

53 ：

・・・
問題は、アルゴリズムと呼ばれているものの中には、
このような概念化、言語化できない(し難い)ものが
あり、この場合は関数名では解決できない。・・ですね。

54 ：

「微分ってなに？」って奴に対してリーダブルにするにはどうすればいいかってことが問題になるな

55 ：

ある位置の傾き

56 ：

>>54
それはそれで「こういう処理を微分と呼びます」でいいんじゃないの
例え新たな用語であろうと、それに対しての厳密かつ具体的な処理が示されて「こういう処理をそう呼ぶんだな」と思えないなら
プログラマとしては、数学以外の分野でもかなり困ることになるぞ

57 ：

>>54
それは勉強すればいいことなので微分のままでいいよ。
リーダブルというのは知識不足を補うためにあるんじゃない。
会社特有の知識とか、会社やめたら無駄になるようなものは
覚える必要はまずないから、それに関するドキュメントが必要。
でも世間一般の知識は、勉強しろの一言で終わり。
それが技術力ってものだからね。
技術者である以上、自分には技術がないのでわかりません。は恥だと思え。
俺にはわからんから高度な書き方をするな。みたいなことを言ってる奴は
技術力ねぇんだなと思えばいい。自分より技術の低いやつに合わせる必要ない。
足を引っ張ってる奴が悪い。

58 ：

道具が使えるだけの奴は三流。
技術・知識も使いこなせて二流。
人も使いこなせてこそ一流。

59 ：

ここまでオライリーの「リーダブルコード」への言及なし。
この本のいいとこ悪いとこの話題とか、
もっと深い議論があるスレを期待した俺がバカ。

60 ：

>>59
お前がすればいいじゃん。
他人任せなのはやめろ。
自分から行動しろ。

61 ：

>>57
それでは足を引っ張られる一方だろ。
自分が楽をするためには
どんな馬鹿にでも判るようなやり方を使って
どんな馬鹿をも楽に使えるような環境を整えるしかない。

62 ：

>>61
馬鹿は切り捨てるか育てるしかない。
技術者は技術があるもののことだ。
素人を基準にしてどうする？
自分が楽をしたいんだろう？
馬鹿用のやり方で楽になるわけがないだろう。

63 ：

>>62
人事権があるならやってる。

64 ：

じゃあ、それは人事権がないのが問題ということで。

65 ：

リーダブル関係ねえ

66 ：

そうそう、リーダブルというのは
プロがプロのために読みやすいコードとはという話であって、
馬鹿でもわかるコードのことではない。
関数さえ理解できない馬鹿がいるんだしな。
だからそいうヤツのことを考えるのは
リーダブルとは無関係。
”リーダブルではないが”馬鹿用に仕方なく書いている。
という状態になるだけ。

67 ：

馬鹿なんて言葉が出てくる時点でどうかと思うけどね。

68 ：

馬鹿は切って捨てろというのは同意したいところだが、あまり理想が高すぎると誰もついて来なくなる。
そもそも原著からして「シンプルで実践的」を掲げてるわけで。

69 ：

>>68
> 「シンプルで実践的」
って、馬鹿^H^Hプログラミング初心者に迎合しろって意味ではないだろ

70 ：

思うにコードを読むのにごく一部の天才しか知らない・理解できないような知識を要したり、
ごく一部の馬鹿の為に特別なルールが設けられているなどの背景についての理解を要するのは
どちらもリーダブルではない罠。
一般的なPGの大多数が、予備知識を一切持たずにすんなり読めるコードこそリーダブルと言うべきではなかろうか。

71 ：

> 思うにコードを読むのにごく一部の天才しか知らない・理解できないような知識を要したり
なんでそんなのを使うと思うんだ？
プログラミング言語が備えている機能を
普通に使ってるだけだぞ？
えとさ、例えばプロの技術者が、自分の使っている道具を
使いこなせてないとしたらどう思うよ？

72 ：

> 予備知識を一切持たずにすんなり読めるコード
そんなものはない。
技術職なんだから技術がない人間が
読めるわけ無いだろ。
反対に言えば、技術職なんだから
素人が出来ないことをできるようになれよ。

73 ：

「PGの大多数が」を省いて我田引水おいしいです

74 ：

お前が言うPGの大多数って馬鹿のことだろう？
具体的に言えば、入社一年未満レベル。
違うのか？
本物のプログラマが普通に読めるレベルなら
プログラミング言語の機能はどれを使っても
読めるはずだが。

75 ：

>71-72
最後に「一般的なPGの大多数が」と書いてるのに、何故そんな解釈するのさ。
言語が備えている機能を普通に使っているコードが読めないレベルが一般的で大多数だとでも?
だとしたら他を見下しすぎ。
あと「予備知識を持たずに」とは書いたけど、「勉強せずに」とは書いてないからね?
例えば余程難解な代物でも無い限り(この条件を見落とさな用に!)、コメントに「〜参照」とでも書いておくだけでも
予備知識を持たずに読めるコードになるでしょ。

76 ：

>74
>本物のプログラマが普通に読めるレベルなら
>プログラミング言語の機能はどれを使っても
>読めるはずだが。
アセンブラでフルスクラッチできるレベルなんでしょうなぁ。
トグルスィッチでミスせず入力しきった真のPGも居ますが。

77 ：

一般的なPGの大多数がどの程度のものを指しているのかしらないけど、
例えば、プロジェクトがオープンソースプロジェクトで
多くの人が参加しているとしよう。
その予備知識を一切持たずにすんなり読めるコードに
書き換えましょうと提案して通るレベルならいいよ。
まあ少数の初心者のために書きなおすことはないだろうね。

78 ：

>>74
PGの大多数が入社一年未満レベル？
なに言ってんの？

79 ：

ユニバーサルデザインの考え方だな。
より一般的な、説明が不要な方法で実装したほうが、
結局はみんなが幸せよ。
例えば売掛買掛とかいう概念にしがみついてんのは、
自分の立場を守ろうとする老害よ。
専門性に逃げ込むような輩は先細っていくよ。

80 ：

おいおい、みんな結局同じことを言ってるぞ。
リーダブルコードというのは、
初心者プログラマでも読めるレベルで書くことじゃない。
プロがプロとして読みやすいコードを書くということだ。
言語の機能には時として使わないほうがいいとされる機能もあるが、
そういうものないのなら、すべて使って良い機能だ。
言語の機能を知らないのは、初心者が頑張って技術をつけろという話であって
初心者のレベルに下げようということではない。
だろ？

81 ：

>>79
> より一般的な、説明が不要な方法で実装したほうが、
より一般的な、説明が不要な方法ってなんだよ？
俺らは技術者だぜ。
技術的な方法で実装するのは問題ない。
わからないのは技術が低いからなだけだろう？

82 ：

そもそも「初心者」っていう言葉を使ってるの一人だけっぽいが…。
我田引水っ子が混じってる気がするから気持ちよく話に参加できない。

83 ：

どんな技術でも使うことに正当な理由があれば使うし、
使うべきでは無いという正当な理由があれば使わないよ。
ただ「周りがわからないから使わない」は
正当な理由にはなりえないな。妥協した理由だ。

84 ：

>>83
なるほど。正当な理由と
妥協した理由ね。
つまりはリーダブルコードの話をする時
正当な理由のみで語るべきということ。
そこに妥協した理由を持ってきてはいけない。
妥協したいならお前の周りだけ妥協すればいいだけじゃん。
技術のなさを恥じながら妥協しておけよ。

85 ：

>79
>より一般的な、説明が不要な方法で実装したほうが、結局はみんなが幸せよ。
この「説明が不要」と言うのはうまい表現かもね。
専門知識・用語を駆使して「説明を省く」のとはちょっと違う。

86 ：

>>85
具体的に言ってよ。
専門知識・用語を使えば簡単なのに、
使わないほうがいい例を
プログラミング技術の話でたとえてみて。

87 ：

>>81
> より一般的な、説明が不要な方法ってなんだよ？
分からないの？
それは技術が低いから？

88 ：

>>87
いいから説明しろよ。
みんなエスパーじゃないんだからさ。
お前の考えだろ？

89 ：

>>88
頑張って、技術をつけてくださいね;)

90 ：

>>89
くだらない煽りはいらん。
さっさと寝てろ。

91 ：

説明を求められて説明できない人って
何のために意見を言ったんだろうかね。

92 ：

>86
>専門知識・用語を使えば簡単なのに、使わないほうがいい例
例えばC++ではないC言語で、「オブジェクト」という単語が出てきたとしよう。
本当にCをよく理解しているならそれが何を意味してるのか分かると思うが、
なまじC++等を知ってるプログラマを混乱させる元になる。

93 ：

> 例えばC++ではないC言語で、「オブジェクト」という単語が出てきたとしよう。
その場合それは専門用語ではない。
誰かが勝手に作った用語だろう？
そういう人こそちゃんと勉強して
正しい専門用語を使えと思うんだが？

94 ：

>>63-65
合ってるだろ、leaderぶる話で

95 ：

ぐんもー☆ぞうをなでなで

96 ：

>>88 みんなエスパーだよ?

97 ：

関数型言語であるような、mapとかfilterとかは、
知らないと読めない典型だけど、いったん知ってしまえば
とても便利だよね
これがリーダブルなのかそうでないのかは
読み手によるとしか答えようがないなあ

98 ：

技術の高さに頼らなくても読めないと駄目だろ

99 ：

その言語の典型的な書き方、イディオムは、読めて当然と考えていいんじゃないか？
それをはずれた書き方は読むのをストップさせるリーダブルじゃないコードだろ。
イディオムを覚えていない初心者はこの議論の範疇外だよ。

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

【漏れは】猫でもわかる質問スレ【猫以下です】 (496)
【初心者歓迎】C/C++室 Ver.87【環境依存OK】 (371)
Git 7 (190)
【漏れは】猫でもわかる質問スレ【猫以下です】 (496)
【C++】高速化手法【SSE】 (884)
Androidプログラミング質問スレ Part37 (214)
--log9.info------------------
どこがいいんだかさっぱりわからない演奏 (250)
本仮屋ユイカ応援スレ (447)
大曲はお好き？【一時間以上】 (141)
文豪ゲーテとクラシック (702)
趣味は？　クラシックです・・・ (140)
フリッツ・クライスラー (614)
ＣＤ所有枚数を申告するスレ (149)
ベル助くんと語り合おう！【隔離室】 (128)
Rー・フィルハーモニー管弦楽団 (200)
おまいらが好きな日本人指揮者･演奏家は？ (186)
使用済み半券でコンサート７回不正入場懲戒免職 (464)
ブックオフで買ったCDを報告するスレ (156)
【作曲家】聴けば聴くほどイヤになる【作品】Ver.2 (862)
東急ジルベスターコンサート　2012-2013 (279)
【ホルンは】金管楽器の協奏曲【木管楽器じゃない】 (144)
新盤旧盤比較スレ (181)
--log55.com------------------
Uber Eats（東京）のデリバリー255【ﾜｯﾁｮｲなし】
山崎製パン工場　part119
【AEON】イオン Part148
【治験】創薬ボランティア Part.25
ポスティング　パート5
西友ミッドナイト・Part30
【最低賃金】マクドナルドでアルバイトPart239
バイト先のむかつくババア Part.4