参考文献

http://www.atmarkit.co.jp/fjava/column/andoh/andoh35.html

人気のAPIにするための26カ条

1. 利用するために覚えることが少なくて済むこと

2. 頻繁に使うものは、デフォルト値で簡単に使えること

3. 頻繁に使うものは、できるだけコンパクトにまとめること（多機能になり過ぎないように）

4. 頻繁に使うものは、できるだけ短い名前で。あまり使わないものは、逆に長い名前でもよい

5. 頻度の低い細かな機能や、詳しい人は深いところまで細かく設定して使えること

6. できるだけ簡単に。できるだけソースコードを書く量は少なくて済むこと

7. 無駄な繰り返し、設定などを記述しなくても良いようにする

8. 同じ機能を持つものが複数個所にあると混乱する。統一・統合を考える

9. 統一された設計思想の下に作られ、少し慣れると、使い方が予想できること

10. 各API、メソッドの名前に統一感がある。欲しい機能名が予想できること

11. 規格を網羅しようとするために、複雑になり過ぎてはいけない。よく使われる機能は2割程度

12. UNIXコマンド名や、Javaのクラス名など連想しやすい機能名を付けるのも1つの方法

13. 必要な機能がそろっていること。重要な機能が未完成だと、以降、使ってもらえなくなる

14. 大量のソースコードの中でも読み取りやすい（あるAPIの一部であることが認識しやすい）こと

15. コードが読みやすいことが第一。文字数を少なくするために読みやすさを犠牲にしてはならない

16. 何がデフォルトであるのか、が明確に分かること。True／Falseでは、一瞬どちらがどちらだか分かりにくい

17. 内部実装やパフォーマンスチューニングにAPIそのものの機能が影響を受けないこと

18. メソッド名などに、ほかのライブラリと同じ名前が混在すると混乱する。クラス／パッケージの扱いとともに、明確さが重要

19. バージョン管理の一貫性。後方互換、上位互換に関して明確な指針があること

20. 統一されたパッケージでまとめられ、ほかのパッケージ（ライブラリ）と衝突しないこと

21. ある特定のマジックナンバー（1番が何、2番が何、……）を使わないこと。覚えなくてもよいこと

22. 定番の省略形があったり、多少長いと感じても、フルスペルで命名すること。ヘタな省略形を使った命名だと、時間がたつと誤解されたり、訳が分からなくなる場合が多い

23. APIの宣言部分（関数やクラスの冒頭）に必要最低限のAPIドキュメントを記述しておく。ソースコードを見ただけで、ある程度のことを把握できるようになる。多数を拾い読みするときに便利

24. エラーメッセージは、どこで何が起こったのか、原因と思われる事象は何なのかを明らかにする。ダメだったことだけをエラーレポートするのでは、意味がない

25. 開発者が記述しなければいけないエラー処理用のコードは最低限で済むように

26. 例外処理用のコードは、開発者が記述しようとする例外を阻害しないように