10 Rules for writing Good SDKs
- Document everything, but don't rely on documentation to explain things
- Test your assumptions, don't just crash on bad data (e.g. handle null pointers gracefully)
- Don't assume your users are professionals, or experts in a domain.
- Use the same terminology in the SDK as that used in the software itself and don't use abbreviations. Most people have tools that do auto-completion nowadays.
- Make common tasks easy and intuitive (e.g. single function calls, or throught helper functions)
- Make things strongly typed: don't just use integers everywhere. Use types to distinguish different kinds of values.
- Provide multiple template projects that people can build from
- Use your own SDK as much as possible. When adding new features to the application, first look to see if the SDK can be used.
- Don't directly expose implementation details: the SDK requires an extra layer of abstraction that makes the steps for developing basic plug-ins easy and obvious.
- Make it obvious how to achieve a desired outcome: reduce ambiguity and complexity. In other words: don't give the users enough rope to hang themselves (or your application) otherwise they will.
|To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.|
Best of the Web
The earliest known C compiler by the legendary Dennis Ritchie has been published on the repository.
HTML5 Mobile Development: Seven Good Ideas (and Three Bad Ones)
All you need to know to get up and running... and programming on ARM
Amazon Web Services CTO says promised land of cloud computing requires a new generation of applications that follow different principles.
Eventually, the vast majority of Web applications will run on a platform-as-a-service, or PaaS, vendor's infrastructure. To help sort out the options, we sent out a matrix with more than 70 decision points to a variety of PaaS providers.