Pedantry: can we call it "guilt.css" instead? In psychological literature, guilt is defined as the "I did something bad" emotion, shame is the "I am bad" emotion. The crucial difference between them is that guilt can be fixed by making amends. That seems like exactly the mindset you want to encourage with this: guilt.css implies that you feel guilty about all the hacks you have and want to make amends, while shame.css implies that your codebase is a steaming pile of shit.
I don't know about psychological literature, but in common usage where I'm from, "guilt" is what you feel when you know you've done something you shouldn't, whereas "shame" is what you feel when you believe others either do or will frown on something. In that context, I think "shame" is more appropriate — essentially, it's a collection of code that brings some degree of shame to the project, not code that you should feel guilty for writing. Think, "It's a shame I had to resort to this."
At where I work, we call it chance_2_buy_lunch.scss
Every Friday, we pick 3 random lines from chance_2_buy_lunch.scss (and another 3 from chance_2_buy_lunch.coffee) and the writers of those lines have to buy lunch for the rest of the team.
I also don't know the psych lingo, but I thought right away of the anthropological distinction between cultures of shame[1] (external disapproval from other people) and guilt[2] (internal disapproval from self). On that score, either could work: shame is certainly appropriate here since devs shame each other all the time.
Interesting. The anthropological and psychological definitions aren't really at odds with each other. When you face primarily external disapproval, it's natural to feel "I am bad", because people's outside opinions are not something you can control. When you face internal disapproval, the natural response is "I did something bad", because you know your own reasoning, you have control over it, and you can resolve to do better next time. Same basic principle as "growth mindset vs. fixed mindset". [1]
I'd argue that if devs shame each other all the time, something about your culture is broken. Why? Because the normal response to shame is to want to hide it. You see that in the description of shame vs. guilt societies in the links you provided, where "Shame cultures are typically based on the concepts of pride and honour, and appearances are what counts, as opposed to individual conscience in guilt cultures." Shame is positively correlated with depression, addiction, violence, aggression, bullying, and all sorts of other nasty stuff; guilt is inversely correlated with all of them. [2]
On that line, I agree, but I think the delineation is more precisely between personal and socially induced "feeling bad". I feel like "shame" connotes a social, or at least, public feeling of ostracizing or sadness.
Regardless, I would agree that guilt.css would have less of a deterrent effect (think chocolate), and illustrate the premise more effectively.
Or perhaps we could use i18 to detect whether the coder lives in a Guilt- or Shame-based culture, and dynamically load guilt.css or shame.css based on the results!
yea it's common to say guilt is feeling bad for _something you did_ while shame is feeling bad for _something you are_. But I actually like the use of shame here because it's a light hearted self-deprecating jab announcing "I'm a bad coder." I also think the externalization aspect lies in favor of shame i.e. "hide your shame!"
We have the same thing in Javascript, we call it 'hacks.js'. That's the place you go when things are broken and you're not yet ready to pay down tech debt.
One key difference here for me is that the word "hacks" might imply that the addition of hacks to that file are acceptable; where as the word "shame" implies that the hacks are less than acceptable and should be used as a last resort.
I would normally agree with you, but the term "hack" in css already has a relatively well defined meaning as "goofy piece of CSS to work around a browser bug"[1]. While I do think it's appropriate to isolate such things so you can remove them when you stop supporting a browser, I don't think they'd belong in a shame.css file. Then again, maybe that's just getting too fetishistic about organizing code.
I find that I rarely fix things marked with FIXME comments. I've had much better success with a 'throwaway.css' file. The idea that a client would load a file with that name on a finished product is distasteful enough for me to want to revisit those hacks.
I don't think it's either indirect or complicated. It's just a file concentrating the FIXME instances that would otherwise be scattered and require a project-wide search.
Simple and elegant imho. That said, I wouldn't use something like that in a project without a build step that merge stylesheets together.
This is particularly easy to do in CSS because it is built up out of a set of rules that have no particular ordering or context. In a way, that's the beautiful part about the CSS. You can concatenate the files however you like and you can also pull out pieces from various components into one place. This certainly isn't possible in most programming where code behavior is highly dependent on the context that it is written.
There might be a subtle difference in the way people think about CSS vs. other programming that would push them to one solution or the other.
There was a similar idea floated by Yehuda Katz by putting a "cruft" file in a source-code repository that lists all the crufty things that need to be taken care of.
Personally I like it, while some people like putting TODOS in the code (and I do it as well) having a specific cruft file (or shame.css) allows you to put in non-code related stuff and comments at a more over-arching level.
The idea itself sounds good and recognizes what tends to happen especially later in a project. There a number of challenges though:
- The name - as already has been raised by others implies that you have done something wrong.
- Adding to the file requires a degree of confidence and maturity among your team and a level of trust among the group.
- The existence of such a file might reduce effort on the part of some. After all if "shameful" hacks are OK, why bother with real solutions?
- Internal refactoring as an separate independent initiative is sometimes difficult to justify from a financial or political perspective.
In a group with self-aware, well educated, and motivated developers, these concerns might be rather small. But in many larger organizations (with practices that sometimes make Dilbert comics appear tame), this would not work as well for these and other related reasons.
Don't get me wrong, I really like the idea. And since css code is relatively "free" to be included in an arbitrary file, calling out questionable code in this way does seem to have its merits. Perhaps its the use of the term shame that tips me off, but that is a concept that is understood very differently by different people and different cultures. So - like many suggestions - it might work well depending on your group, but is unlikely to be adopted as a universal best practice.
This is a great idea and to be honest the only time I ever use hacks is when I am adding in compatibility for IE8. I disagree with the !important declaration though. I use LESS for writing CSS and while it's definitely a valuable asset to have, the ability to nest and have super specific queries generated means when you'e writing media queries, you sometimes don't want to have to replicate the nesting and specificities instead of just going .element and using !important instead saves time and space. Why is everyone so against using !important? Sometimes when you're overriding CSS added to an element via Javascript you have to use !important, regardless of how specific you are.
Cool idea, but considering IE8 support is on its way out from developers what hacks are left we need to use? Using overflow: hidden instead of resolving a problem is just lazy, it's not a hack, it's plain lazy. Cool idea in theory and perhaps might have been helpful in 2008, but it's 2013 and browsers are all at a point now where we can use CSS and not have to worry about consequences or support except for maybe browser vendor prefixes.
Using !important 9 times out of 10 means you're doing something wrong. Many developers rely on it as a lazy tool for various reasons (bloated unmanageable css files, lack of knowledge, etc.) The media query example and overriding third party code you can't edit are the 1 in 10 examples. I would even possibly debate the media query situation as it is being a bit lazy IMHO.
For me shame.css doesn't necessarily contain hacks. In mine you will find less thought out selectors that are added in haste and anything else that doesn't conform to the high standard I set myself.
> The first bits of bad code set a precedent and make subsequent developers feel less bad about using poor code themselves.
This is really just another manifestation of the "Broken windows theory"[1], which I've witnessed in code many times over. I think it's just a fact of human nature, also similar to the "When in Rome..." adage; it doesn't make you feel nearly as dirty to do something awful (whether it's in code or in a run-down urban environment) when there's already lots of problems to begin with.
I don't like this idea since it separates your hack CSS from the CSS it's supposed to hack. It's an even bigger problem when you're using SCSS and you have to reproduce the entire selector tree for your hacks.
This is a great idea. Too bad code can't really be isolated this way. I feel that marking a hack is one of the few legitimate uses for comments in code:
I feel that marking a hack is one of the few legitimate uses for comments in code
I'll take that as an offhand comment you didn't give much thought to, because wow, there most certainly are lots of legitimate uses for comments in code.
I'm pretty firmly in the "code as documentation" camp, what can I say? I think that most of the time, if you can describe an action with two or three words, you probably ought to be extracting that logic into a method by the same name.
IMHO comments are best used in a handful of situations, such as:
1) Marking hacks
2) Explaining unusual, non-obvious sections of code
3) Noting historical reasons for doing something in a non-obvious manner
4) Noting pitfalls to be avoided
5) Making passive aggressive remarks about the "business guy" who made you do something terrible
Not an exhaustive list of course, but I do think that it's best to think twice before writing a comment, asking yourself "how can I make this more obvious with my code?"
Some of this can/should be done via a CSS system like SASS/Compass. If you're littering overflow:auto into a dozen rules, SASS/Compass would probably help you immensely. When you eventually decide IE6 support isn't needed, flip a single variable and poof--those rules disappear.
You could extend this to a _shame.sass file too, of course.
I'll add another vote for SASS/Compass. That system has saved me tons of heartache and hair-rending (and I don't have the hair to spare). SASS makes it easier to organize your CSS than to leave it unorganized. It almost makes CSS fun.
I think he was referring to those instances where you have something which as far as you can tell at the moment should be a certain height but inexplicably (at the moment, because you need it fixed now!) has this weird margin underneath it. With a quick look at the web inspector and your code you can't work out where it's coming from so in the interests of fixing a problem now, you might `overflow-y:hidden` it with the intent to come back later.
It's not that overflow: hidden in itself is a hack, but it's application to counter collapsing due to floats. Already in the first paragraph, your link states that float containment is a side-effect.
While I do use it for this exact reason, it leaves a bit of an aftertaste. And when it comes to css, isn't that the definition of a hack?
I think he was merely saying that it is a hack in the instance where a proper fix, without using overflow: hidden, COULD be found but in order to fix it NOW it was required to be used.
