Here are my notes from Brandon Rhodes's talk in RuPy 2013 about duck typing and names. His talk was in the context of Python but it's really generally applicable.
- Python people use the adjective "Pythonic", meaning not the syntax, but additional rules programmers follow. Indentation, formatting, in a standard called PEP-8.
- "The Elements of Typographic Style" has a rule similar to PEP-8 about line length, 45-75 characters as a satisfactory length for a single-column page, 66 characters as ideal.
- When formatting code, we're basically graphic designers. We may ignore design, but we're still designers of some sort.
- PEP-8 could be thought of as "Elements of Pythonic Style".
- But it gives bad advice, generating ugly code. For example, method calls with many arguments and how that's broken that into lines.
- Python programmers break these "bad" rules independently in the same way, as if by following some logic.
- With a two-line method call, why not pull some arguments out and give them a name as a local variable? (From XP: "Destroy all Comments" and use descriptive names instead).
- A previous PyCon Canada talk involves coding as graphic design more.
- "The naming of cats is a difficult matter", T.S. Eliot
- "The naming of ducks is a difficulta mtter" also. No type annotations -> The name is the only thing that exists for communicating what something is.
- What has the internal Pythonic logic taught us about naming?
- Well-Factored Nouns - Each discovery should be pushed across the code. Learning that a name was imprecise is knowledge and that same knowledge shoud be distributed everywhere. Refactor exuberantly.
- Relentless Verbs - For stuff that does something, use a verb. Explicit is better than implicit. Plain old functions should, in almost all cases, be verbs. Methods are an exception to this, because they have parens (
document.md5()). Another exception is "new" - in OO language it's always considered a verb for construction.
- The Sin of Synechdoche - Occurs when we confuse a name with what it names. The name of a song is not a song. The path to a document is not a document. Rather,
song_path. Naming the part is mandatory, naming the whole is optional because it may be supplied by the context (just
urlmay be fine). PEP-8 gets this right.
- Short, unqualified names are great because the caller can later decide whether to qualify them.
- Plurals are not always unique. Plurals are also used for counting.
- The relational database best-practice is to use singular names for tables. Singular is also used in linear algebra (x for a large amount of x:s).
Always default to safety: Not "load" and "safeload". The unsafe is what you should be explicit about, "load" and "dangerousload".
The biggest mistake is thinking you're done when the program works. The moment the program work is better to say it barely works. Now's the time to make it better and clean it up (at least as much work still ahead)
Good Python programming is often more about what you ought to do rather than just what you can. Writing good Python is an exercise in propriety.
Know Your AngularJS Inside Out
Build Your Own AngularJS helps you understand everything there is to understand about AngularJS (1.x). By creating your very own implementation of AngularJS piece by piece, you gain deep insight into what makes this framework tick. Say goodbye to fixing problems by trial and error and hello to reasoning your way through them
- RuPy 2013: Programming Diversity
- RuPy 2013: OpenStack Development: How We Build It And ow You Can Help