Ideally, I use Sass with Compass (http://compass-style.org/). This alone is a great start to keeping things organized. One of the things I love about Sass is that it allows partials and variable declarations, which both help immensely with code organization.
Then, my code is usually organized as follows. Each section can be extracted to a partial if it gets long enough or if more separation is desired.
Framework includes and resets
Variable declarations — colors, possibly specific widths
Universal method declarations
Standard global tags — headings, p, a, ul, li, etc...
Generic form styling, usually in a dedicated partial
Layout — container, header, content, footer
Then to specific section styling
Since Sass uses indentation, I indent everything in each section within a top level tag. This really helps visually distinguish each section and gives a much less uniform look to the stylesheet which makes it a lot more scannable. If a section uses methods exclusively I'll declare them just above the top-level section tag.
I'm pretty happy with this approach. It was formed fairly organically but become more defined as I use it for more projects. It also seems to work well for both large and small projects, since partials can be used when the code starts getting long.
The biggest problem that I have with Sass is that the file/line references in your developer tools point at the compiled CSS files, and so you don't have any real reference to where in your Sass files that style is defined. Any solution for this?
There actually is; SASS has built-in functionality that will actually inject the source filename/line-number in to the generated CSS. Additionally, Nathan Weizenbaum (one of the HAML/SASS maintainers) released a Firefox/Firebug add-on that will read this and display it in Firebug like it does for traditional CSS.
Yes, Sass provides a setting that prints the source line numbers with the compiled CSS for development. I think this is on by default, but you can turn it on in the config file with:
Sass::Plugin.options[:line_comments] = true
# or with compass:
sass_options = {:line_comments => true}
Sass compiles code like this:
/* line 138, sass/screen.sass */
#navigation a:hover {...}
I guess it can be a problem sometimes, but I don't usually have issues with it and find that the organizational benefits outweigh the drawbacks by a long shot.
For me, at least in my rails project using Sass (scss): Development mode also creates inline comments in the generated CSS which describe where, in the original scss, the information can be found.
Then, my code is usually organized as follows. Each section can be extracted to a partial if it gets long enough or if more separation is desired.
Since Sass uses indentation, I indent everything in each section within a top level tag. This really helps visually distinguish each section and gives a much less uniform look to the stylesheet which makes it a lot more scannable. If a section uses methods exclusively I'll declare them just above the top-level section tag.I'm pretty happy with this approach. It was formed fairly organically but become more defined as I use it for more projects. It also seems to work well for both large and small projects, since partials can be used when the code starts getting long.