Coding Rules & Assumptions
Overview
This section of wiki.larrymg.me is a truncuated Markdown re-presentation of the data on the main site's Coding Rules & Assumptions page.
Visit the main site for additional data associated with each rule and assumption, including justifications & concrete rule cases.
Build Tools
I love Markdown, but creating tables in Markdown can be a real pain!
I used the Tables Generator web app to quickly tabulate this collection of rules & assumptions.
Coding Rules
| Rule | Source |
|---|---|
| Refactor code into lots of small independent components whenever & wherever you can. |
B. Sourer |
| Don't change a UI to accomodate Box Model issues that are easily avoided. |
B. Westfall |
| Always look for patterns when solving problems. | B. Westfall |
| First make it work; then make it better. | B. Sourer |
| Optimize for delete-ability. | B. Holt |
| Commit frequently & only do one thing per commit. | M. Fowler |
| When starting a new side project, create the site locally first then purchase the domain name. |
Mise Mé Féin |
| Set sensible default font sizes before declaring a fluid calc() expression. |
M. Riethmuller |
| GUI tools are useful but it's better to learn command line tools from the beginning. |
C. Schafer |
| One should look at a test and get the intent instantly. | Y. Goldberg |
| The best way to build design intuition is to ask designers you work with questions. | J. Comeau |
Coding Assumptions
| Assumption | Source |
|---|---|
| We build the web for everyone, not ourselves and our peers. |
B. Sourer |
| Almost every bug rests on a bad assumption. | B. Sourer |
| By choosing to be a developer, you are choosing to learn. |
S. Drasner |
| It only takes one instance of losing a few hours of work to know that slow & steady is the way to go. |
Anonymous |
| People that computer science is the art of geniuses but the actual reality is the opposite: just many people doing things that build on each other, like a wall of mini stones. |
D. Knuth |
| If you write it, you don't have to learn it. | Syntax Podcast |
| The first 90% of your code accounts for the first 90% of development time; the remaining 10% of the code accounts for the other 90% of development time. |
Anonymous |
| CSS knowledge helps create elegent & robust solutions; it is an often underrated resource. |
J. Perals |
| The best way to learn is to build. | J. Quick |
| CSS is a visual language at the end of the day: make the visual punch you in the face so you really understand what's going on, then tone things down. |
K. Powell |
| Although we use several different langauges when putting together websites CSS is the only one that had to deal with the "webiness" of the web. That's the primary challenge of working with CSS. |
K. Powell |
| If something is delete-able, it's modular; and if it's modular, it's great. | B. Holt |
| The best devs deeply understand how the languages & frameworks they use actually work (vs. how they think they work). |
B. Sourour |
| Master code skills & concepts (e.g. HTML, CSS, & Vanilla JS) allows devs to hold the tools built on top of those skills lightly, learn quickly, and switch easily. |
R. Andrews |
| Computing new values is less error-prone than changing existing values. |
M. Haverbeke |
| A test should feel like a friendly assistant, there to help you, and should never feel like a hindrance. |
Y. Goldeberg |