ここに真実を返す理由はありますか？

Question

このタイプの構造は、私のプロジェクトのほとんどのjavascriptファイルに表示されます。私の質問は、あるsetElements後に真を返すようにそこに理由ですので、のような文の「if」でそれを呼び出す：

App.ModuleName.setElements = function() { 
    App.ModuleName.el = { 
     title: $("#title") 
    } 
    return true; 
}; 


App.ModuleName.init = function() { 
    if (App.Common.checkDependency('ModuleName')) { 
     if(App.ModuleName.setElements()) { 
      //do something 
     } 
    } 
}; 

真のリターンを削除し、ちょうどやってとは対照的に、：

if (App.Common.checkDependency('ModuleName')) { 
    App.ModuleName.setElements(); 
    //do something; 
} 

？

Answer 1

提供されたコードによれば、それは必要ではありません。そのコンテキストを考えると、わかりやすいように、コードのバージョンが優れています。

しかし、実際にリファクタリングできるかどうかを判断するには、プロジェクト内の関数のすべての用途を確認する必要があります。

何らかの種類のSQLトランザクションを実行しているが、SQLトランザクションに含まれていない処理が完了しているかロールバックされている状況を想像してください。例外はsetElementsがtrueを返したときに前にどこかにスローされた場合elementsWereSetはfalseなること

App.OtherModuleName.init = function() { 

    bool elementsWereSet = false; 

    Transaction transaction = new Transaction(model); 

    try { 
     // Do some processing 
     DoSomething(model, transaction); 

     elementsWereSet = App.ModuleName.setElements(); 

     DoSomethingElse(model, transaction); 

    } catch (Exception ex) { 

     transaction.rollBack(); 

     if (elementsWereSet) { 
      manuallyRollBackElements(); 
     } 
    } 
}; 

は注意してください。

例外が発生した場合、boolは手動で何かをロールバックする必要があるかどうかを判断します。

このダイナミックを達成する他の方法がありますが、私はこのパターンをソフトウェアの大部分で少なくとも1回は使用しています。

Answer 2

詳細を説明する場合、trueを返す理由はありません。私はそれがあなたがコードを開発するのに使った請負業者のコーディング規約だと思う。呼び出しが成功したことを検証できるようにするのは実際的であり、複雑な呼び出しでは悪い考えではありません。