Harry Roberts has written an epic article where he
suggests breaking down classes
into objects (o-), components (c-), utilities (u-),
themes (t-), states (is-, has-) and a couple of others
(_, js-, qa-). He uses this namespacing method to make
the code he writes more readable and maintainable at scale.
I've got a slightly different take on it. I would argue that Harry's method of adding class types adds complexity to our CSS. With BEM naming conventions and Sass I believe
| #!/usr/bin/python | |
| ## gitsh (pronounced like "glitch"), an interactive wrapper for git. | |
| ## | |
| ## gitsh parses the output of "git status" and numbers the files for | |
| ## you, for easy operations on multiple files. | |
| ## | |
| ## $ gitsh status | |
| ## 1) M foo/bar.py | |
| ## 2) M foo/baz.py | |
| ## 3) A blah.sh |
You grok SOLID. You practice TDD. You've read Sandi's book…twice. You rewatch Destroy All Software monthly. You can pronounce GOOS. You know your stuff!
But some of your coworkers say your code is too complex or confusing for them. You might rush to conclude that must be a them problem.
But doubt lingers: what if they're right?
| #leftcolumn > ul | |
| #region-content .menu { | |
| margin: 0; | |
| list-style-type: none; | |
| list-style-image: none; | |
| } | |
| #region-content .menu > li { | |
| display: block; |
| Latency Comparison Numbers | |
| -------------------------- | |
| L1 cache reference 0.5 ns | |
| Branch mispredict 5 ns | |
| L2 cache reference 7 ns 14x L1 cache | |
| Mutex lock/unlock 25 ns | |
| Main memory reference 100 ns 20x L2 cache, 200x L1 cache | |
| Compress 1K bytes with Zippy 3,000 ns | |
| Send 1K bytes over 1 Gbps network 10,000 ns 0.01 ms | |
| Read 4K randomly from SSD* 150,000 ns 0.15 ms |
| """Collect article metadata and associate it with url dimension. | |
| Currently the url dimension includes a domain and url, but there is | |
| a higher level grouping that we care about. What is the outlet, | |
| who authored the article, what kind of site is it, when was | |
| it published, etc. | |
| """ | |
| import os |
| --- django_test_manage.py.orig 2014-10-21 21:50:06.000000000 -0700 | |
| +++ django_test_manage.py 2014-10-21 22:59:51.000000000 -0700 | |
| @@ -2,16 +2,42 @@ | |
| import os | |
| import sys | |
| +import re | |
| from django.core.management import ManagementUtility | |
| [versions] | |
| plone.app.jquery = 1.1.12 | |
| plone.app.jquerytools = 1.7.0 |
“I perfectly understand our CSS. I never have any issues with cascading rules. I never have to use !important or inline styles. Even though somebody else wrote this bit of CSS, I know exactly how it works and how to extend it. Fixes are easy! I have a hard time breaking our CSS. I know exactly where to put new CSS. We use all of our CSS and it’s pretty small overall. When I delete a template, I know the exact corresponding CSS file and I can delete it all at once. Nothing gets left behind.”
You often hear updog saying stuff like this. Who’s updog? Not much, who is up with you?
This is where any fun you might have been having ends. Now it’s time to get serious and talk about rules.
Writing CSS is hard. Even if you know all the intricacies of position and float and overflow and z-index, it’s easy to end up with spaghetti code where you need inline styles, !important rules, unused cruft, and general confusion. This guide provides some architecture for writing CSS so it stays clean and ma
| -e git://github.com/kennethreitz/inbox.py.git@551b4f44b144564504c687cebdb4c543cb8e9adf#egg=inbox | |
| alembic==0.8.3 | |
| amqp==1.4.9 | |
| anyjson==0.3.3 | |
| boto==2.39.0 | |
| braintree==3.20.0 | |
| cairosvg==1.0.19 | |
| celery==3.1.20 |