Timeクラス、Dateクラスを作らない – 命名のアンチパターン紹介

Laravelのコマンド実装で、php artisan time というコマンドを作成した事例を見つけました

<?php

namespace App\Console\Commands;

use Illuminate\Console\Command;
use Carbon\Carbon;;


class Time extends Command
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'time {days=0}';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = '毎時実行されるバッチです';

    /**
     * Execute the console command.
     *
     * @return int
     */
    public function handle()
    {
        $days = $this->argument('days');

おそらく、この作成者は、「１時間に１回行われる処理を書こう」としてこの名づけになったのだと思います
これはアンチパターンで、できれば避けたいです
理由はいくつかあります

• 今は１時間に１回だけど、将来的に頻度が減ったり増えたら、名前も変えないといけない
• コマンドの名前や説明を見ただけでは、どんなことが実行されるかわからない

説明を十分すればいいのではなくて、ソースコードは実行時の役割でもって名づけしていただきたいです
理由は、上の逆で、名前や説明を見て、一発でどんなことが実行されるかわかりたいです
とくに今回はコマンドなので、 php artisan list で見た時に、これはXXを実行するコマンドなんだなとすぐに理解したいです

ですから、例えば1時間に1回のほうではなく、「ユーザーステータスの更新」とか「来店合計時間の集計」とか、実行されたあとにどうなるかっていうことを伝える名づけにしていきましょう！

そして、コマンドをそれぞれの実行時の役割に分類して、上の例でいえば、 UserStatusUpdater クラスとし、コマンドは、 php artisan user-status-update {days=0} のようになれば、コマンド名を見ただけでなんとなーくやりたいことがわかってよいと思います。