![rw-book-cover](https://readwise-assets.s3.amazonaws.com/static/images/article4.6bc1851654a0.png) --- > It’s actually easy to name things. The hard thing is naming them *well*. Maybe if it were harder to name them we’d spend longer choosing good names. - [View Highlight](https://read.readwise.io/read/01h4dktbywf3fes0x1vhhsjthm) --- > I’m a [strong advocate](https://benhoyt.com/writings/python-api-file-structure/) of designing your module to be used with the module name as a dotted prefix. Requests follows this: `get()` wouldn’t make much sense on its own, but `requests.get()` is clean and clear. You don’t get name clashes, because the module name is right there to disambiguate. - [View Highlight](https://read.readwise.io/read/01h4dkwtveyg4xz0wtj1m4pfc6) --- > don’t name things to explain everything they do; **name things so the meaning is clear in context.** - [View Highlight](https://read.readwise.io/read/01h4dkx3vsmpttta0kwmy46hx1) --- > I’ll finish with a quote from Russ Cox, tech lead of the Go project, who states [his variable naming philosophy](https://research.swtch.com/names) this way: > > *A name’s length should not exceed its information content.* … Global names must convey relatively more information, because they appear in a larger variety of contexts. Even so, a short, precise name can say more than a long-winded one: compare `acquire` and `take_ownership`. Make every name tell. - [View Highlight](https://read.readwise.io/read/01h4dkzmmgzt6f8jq6wr6wbg4h) ---