カスタムアノテーションを作成してメソッドが読みやすくするだけであることを示す価値はありますか？

Question

現在、Springと連携しています。私はコードの可読性を高めるために使用できるメソッドについて学習しています。複雑な条件を簡単なメソッド呼び出しで置き換える例もあります。たとえば：

private void myMethod(){ 
    //Bad 
    if(userAge < MIN_AGE){ 
     //logic 
    } 

    //Good 
    if(userTooYoung()){ 
     //logic 
    } 
} 

private boolean userTooYoung(){ 
    return userAge < MIN_AGE; 
} 

は、私の質問は：userTooYoungは、読みやすさを支援するだけであることを示すために、カスタムアノテーションを作成しながら、それは価値がありますか？たとえば、次のように

@Assistant 
private boolean userTooYoung(){ 
    return userAge < MIN_AGE; 
} 

私は本当に@Assistant注釈が役立つことができる別の機能を考えることはできません

は、このように、それはそれはそれは本当に価値があるの質問を頼みますか？

EDIT： 私は@Assistant注釈のアイデアで遊んで、次を思い付くしてきた：

定義：

@Retention(RetentionPolicy.SOURCE) 
@Target(ElementType.METHOD) 
public @interface Assistant { 

    enum With { 
     CONDITIONAL_LOGIC, CONSTRUCTION_LOGIC 
    } 

    With help() default With.CONDITIONAL_LOGIC; 
} 

使用法：

@Assistant(help = Assistant.With.CONDITIONAL_LOGIC) 

Answer 1

あなたは意見を求めています。ある時点で、私はtsolakpに同意します。あいまいな名前のアノテーションが多すぎる可読性が低下します。同時に、複数の場所で何かをマークする必要があり、やっていることが明白でない場合は、読みやすくするために単純に使用されるカスタム注釈は意味があります。たとえば、Google Guavaは@VisibleForTesting注釈を提供します。これはプライベートメソッドが何をデフォルトの有効範囲にするべきかを示すために使用されるので、ユニットテストが可能です。私はクライアントが徹底した単体テストを必要とするときにかなり使います。

あなたの場合は、明快さを増すことはなく、その名前はあまり意味がありません。

Answer 2

TL; DRはあなたが行うことができますすべてが

を行うべきではない、私は間違いなく、あなたがそうするべきではありません正直に言うと、そうする価値があるとは思わないが：

• からクリーンなコードのパースペクティブでは、追加の情報なしで混乱を招きます。
• コメントとの違いは何ですか？あなたはそのコメントを書いていますか？いいえ
• ほとんどすべてのプライベートメソッドは、単なる可読性を向上させるためのものです。暗黙の情報を明示的に追加する必要があるのはなぜですか？