Here is a real world example of what i am talking about, from a code base i currently work with, and don't dare touch: http://i.imgur.com/fMlvoRS.png
The idea of maintaining legacy sass with heavy embedding in years to come makes me shudder.
That one you mention is a huge problem. Hence the documentation states "Don't nest more than 3 layers deep".
Most sites don't need variables and nestings of CSS.
I would rather see duplicate class names like this in CSS.
.wrapper1 .header {}
.wrapper1 .header h2 {}
.wrapper1 .body {}
.wrapper1 .body .article {}
.wrapper1 .body .article .blurb {}
.wrapper1 .body .article .quote {}
.wrapper1 .footer {}
Repetition doesn't bother me. In fact, it is surprisingly helpful.
if wrapper and header:
...
if wrapper and body:
...
if wrapper:
if header:
...
if body:
...
Consider the case below. If I want to understand what conditions are necessary for body, that code is now offscreen. I generally consider overly-nested conditions as code smell.
if wrapper:
... 30 LOC ...
if header:
... 30 LOC ...
if body:
... 30 LOC ...If ~25 years of doing programming for money taught me something, it's that the code is written to be read and maintained by humans, and having really short, clean, one-purpose, composable functions makes your life easier both long-term and short-term.
"Fit all functions on one screen."
At that time that was roughly 22 lines depending on editor used.
Two If statements, no nesting
vs.
Three If statements, 1 level deep nesting
The problem I foresee with repeat conditions is that during a change, I might forget to update one or more of the repeat conditions.
Also, I wonder, do gcc and/or clang recognize repeat conditions and produce the equivalent of what nested statements would?
The most useful one, and the one that drives me crazy when I see it, is when people write code like this:
if something:
value = do something
else:
value = do something else
return value
if something:
return do something
return do something else
This isn't the same as "show all conditions at once" -- instead it's "ignore the conditions that have already been satisfied."
Seeing that we already returned out in condition #1 lets me focus more on condition #2.
I think the main reason returning early works so well is that often times, when you're returning different values, it's because you quickly have an answer (often times that something is invalid) for particular inputs. Generally though, there is "real work" to be done after validating or normalizing your inputs.
If that's not true, you're probably trying to do too many things at once, and the different pieces should be broken into separate functions.
> The most useful one, and the one that drives me crazy when I see it, is when people write code like this:
But... your example doesn't show any ways to avoid nesting. There's just as much nesting after as before.
Your change makes the code less tall, which is a problem I've had with Python, but it has nothing to do with nesting at all.
I'm actually fond of a third approach:
if something:
return do something
else:
return do something else
return something
? do_something ()
: do_something_else(); if something:
value = do something
else:
if something_else:
value = do something else
else:
value = do a third thing
if something:
return do something
if something_else:
return do something else
return do a third thing
if some_function(arg, arg2):
result = True
else:
result = False
return result
return some_function(arg, arg2)
if a:
if b:
if c:
if d:
if e:
if f:
if g:
if a and b and c:
if a and b and d:
if a and e and f:
if a and e and g:
if a and b and c:
if d and b and a:
if e and a and f:
if g and e and a:
if e and f and a:
if c and b and a:
if g and a and e:
if d and a and b:
Also, it does force you to write CSS more efficiently because if you work with pre-processor language, you often don't see the bloat.
if wrapper:
do_thing_to_wrapper(wrapper)
def do_thing_to_wrapper(wrapper):
...It's not the nesting in the SASS that's the problem per se, its the fact that it makes it easy to create the kind of code that you list that's the problem.
Modern good practice suggests a single classname for each item, so you're not fighting with specificity too much.
The original "bad" example doesn't even do that, its just using :before and :after etc. not nested selectors.
Alternative is to create descriptive, but potentially very lengthy class names that is single level.
Every modern CSS codebase attempts to use 1 location agnostic class per element. Usually when warning against 3 levels of nesting in preprocessors it is to maintain readability on pseudo selectors but not an encouragement to nest classes.
Maybe context.
What that guy posted is fine (only if you have SOME sort of rules around nesting - our team has been getting along great ever since using rscss.io methodology)
Doesn’t firefox even support in-browser viewing and editing of SASS?
And I think the benefit of the ease-of-writing is minimal (especially if you're using something like BEM where you're trying to avoid cascading anyway), whereas the drawbacks in terms of understandability are super duper high.
I think it's always ok to use them for pseud-oclasses and I think in general if you've nested something more than 2 levels deep you probably have a sign you might need to refactor something.
No right or wrong answer here, just genuinely curious.
.myclass { ...30 loc ... } /* .myclass */
I really don't see this enough.