The Little Manual of API Design
Jasmin BlanchetteTrolltech, a Nokia company June 19, 2008
Contents
2.1 Easy to learn and memorize. . . . . . . . . . . . . . . . . . . 82.2 Leads to readable code. . . . . . . . . . . . . . . . . . . . . . 92.3 Hard to misuse. . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Easy to extend. . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5 Complete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1 Know the requirements. . . . . . . . . . . . . . . . . . . . . . 153.2 Write use cases before you write any other code. . . . . . . 153.3 Look for similar APIs in the same library. . . . . . . . . . . 163.4 Define the API before you implement it. . . . . . . . . . . . 173.5 Have your peers review your API. . . . . . . . . . . . . . . . 173.6 Write several examples against the API. . . . . . . . . . . . 183.7 Prepare for extensions. . . . . . . . . . . . . . . . . . . . . . 183.8 Don’t publish internal APIs without review. . . . . . . . . . 183.9 When in doubt, leave it out. . . . . . . . . . . . . . . . . . . 19
4.1 Choose self-explanatory names and signatures. . . . . . . . 214.2 Choose unambiguous names for related things. . . . . . . . 224.3 Beware of false consistency. . . . . . . . . . . . . . . . . . . 234.4 Avoid abbreviations. . . . . . . . . . . . . . . . . . . . . . . . 254.5 Prefer specific names to general names. . . . . . . . . . . . . 254.6 Don’t be a slave of an underlying API’s naming practices. . 264.7 Choose good defaults. . . . . . . . . . . . . . . . . . . . . . . 274.8 Avoid making your APIs overly clever. . . . . . . . . . . . . 284.9 Pay attention to edge cases. . . . . . . . . . . . . . . . . . . . 284.10 Be careful when defining virtual APIs. . . . . . . . . . . . . 304.11 Strive for property-based APIs. . . . . . . . . . . . . . . . . 314.12 The best API is no API. . . . . . . . . . . . . . . . . . . . . . 323
Search History:
Result 00 of 00
00 results for result for
p.
More From This User
Notes
Load more
