Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>In API design I've always found this keynote very helpful: <br> <a href="http://www.google.nl/search?q=How+to+Design+a+Good+API+and+Why+it+Matters" rel="noreferrer">How to Design a Good API and Why it Matters - by Joshua Bloch</a></p> <p>Here's an excerpt, I'd recommend reading the whole thing / watching the video.</p> <blockquote> <p>II. General Principles</p> <ul> <li>API Should Do One Thing and Do it Well<br></li> <li>API Should Be As Small As Possible But No Smaller<br></li> <li>Implementation Should Not Impact API<br></li> <li>Minimize Accessibility of Everything<br></li> <li>Names Matter–API is a Little Language<br></li> <li>Documentation Matters<br></li> <li>Document Religiously<br></li> <li>Consider Performance Consequences of API Design Decisions<br></li> <li>Effects of API Design Decisions on Performance are Real and Permanent<br></li> <li>API Must Coexist Peacefully with Platform</li> </ul> <p>III. Class Design</p> <ul> <li>Minimize Mutability<br></li> <li>Subclass Only Where it Makes Sense <br></li> <li>Design and Document for Inheritance or Else Prohibit it</li> </ul> <p>IV. Method Design</p> <ul> <li>Don't Make the Client Do Anything the Module Could Do<br></li> <li>Don't Violate the Principle of Least Astonishment<br></li> <li>Fail Fast - Report Errors as Soon as Possible After They Occur<br></li> <li>Provide Programmatic Access to All Data Available in String Form<br></li> <li>Overload With Care<br></li> <li>Use Appropriate Parameter and Return Types<br></li> <li>Use Consistent Parameter Ordering Across Methods<br></li> <li>Avoid Long Parameter Lists<br></li> <li>Avoid Return Values that Demand Exceptional Processing</li> </ul> </blockquote>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload