Reads


Chapter 3 - Names That Can't Be Misconstructed

Actively scrutinise your names by asking yourself, “What other meanings could someone interpret from this name?” Example: Filter() Filter is an ambiguous word, it can either mean “to pick out”, or “to remove”. select() is better in the former case and exclude() in the latter. Example: Clip(text, length) Clip() clips the contents of the paragraph. But its unclear whether it: removes length from the end of the paragraph truncates to a maximum length.

Chapter 2 - Packing Information into Names

Packing Information into Names Choose specific words def GetPage(url) doesn’t say much. Maybe FetchPage() or DownloadPage() is more specific? int Size() - is this size the height of an object, numbeer of elements or memory footprint? Maybe Height(), NumNodes() or MemoryBytes() is better. A thesaurus can be useful. send -> deliver, dispatch, announce, distribute, route find -> search, extract, locate, recover start -> launch, create, begin, open make -> create, set up, build, generate, compose, add, new

Chapter 1 - Code Should Be Easy to Understand

Code should be easy to understand. This is the most important guiding principle to use when deciding how to write code. Fundamental Theorem of Readability Code should be writted to minimise the time it would take for someone else to understand it. To understand the code means to be able to make changes to it, spot bugs and understand how it interacts and fits into the rest of the code.

The Art of Readable Code

“Simple and Practical Techniques for Writting Better Code” by Dustin Boswell and Trevor Foucher.

Read more RFCs

Published:

This post introduces a new series of posts commenting on and summarising the RFCs that I enjoyed reading for one reason or another. I couldn’t say when it was that I first discovered RFCs, but I know one thing for sure - the core idea of describing something, usually technical, in great lucidity and opening it up for peer-review impressed me enourmosly. In fact the idea inspired me to create my own set of RFCs, which I called PRFCs, for Personal Request For Comments, the word Personal signifying that they were mostly used internally to document thoughts about solving this or that technical problem (like designing the network in our student house or figuring out how to provide redundant Wifi connection for an old town hall in East London taken over by a bunch of hackers and artists).