Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "nesting hell"
-
A sidebar.
Literally just a sidebar.
And yes, this was in Hell.
Its code was spread across at least 40 files, and it used a bunch of freaking global variables to unfurl accordion sections, hide other sections/items, highlight the active item, etc. These were set (and unset!) in controller actions, so if you didn’t unset one, it remained open and highlighted until another action unset it.
Some of the global variable checks (and permissions checks) were done in the individual views, some outside of the `render` statements that include them. Some of them inherited variables from the parent, some from the controller, some from globals. Getting a view to work was trial and error. Oh, and some had their own inline css, some used css classes.
Subsections were separate views, so were some individual items, both sometimes rendered using shared templates, and all of the views and templates had the exact. same. filename. (They were located in different directories, and thus located automagically via implicit relative paths.) So, it was a virtually endless parade of`render partial => “sidebar”`. Which file does that point to? Good luck figuring it out!
Also, comments in several places said adding a new section required a database migration. I never did figure out why.
Anyway, I discovered this because I had an innocuous-sounding ticket to rearrange the sidebar, group some sections/items under different permissions, move some items to another menu, and nest some others differently.
It took me two bloody weeks, and this was when I was extremely productive every day.
Afterward, I was so disgusted by it that I took a day and removed every trace of the sidebar I could find, and rewrote it. I defined the sidebar in a hash, and wrote a simple recursive builder to generate the markup. It supported optional icons, n-level nesting, automatic highlighting of the current item and all parent nodes, compound and inherited permissions, wrapping of long names, hover and unfurl animations, etc. Took me a couple hundred lines of Ruby at the most, plus about the same of css.
Felt so good to remove that blight.5 -
when you have to use one language inside of another, and you basically have to call functions allowing you to call the other's language function within it, and you get the hell confused, since it gets harder and harder to see what is what and who can call who and how, and the compiler ofc. won't say anything about it since it only cares about the main language you are in and not the nesting of the other...
I just have no idea what I'm doing right now, or if my thought process and understanding of this is even close to where it is supposed to be.
D: I'm just confused and insecure about this right now....
time for experiments to figure this out, and get the hang of it13 -
That moment where you see code of someone who riddles their code with nested if-else and if-elseif statements.
I don't remember writing an else statement for years. It almost always can be avoided (and the rare cases where it makes sense I prefer the switch statement).
Yet I never grasp why people do:
```
if(someCondition) {
// huge nested code block
} else {
throw new Error();
}
```
Instead of
```
if (!someCondition) {
throw new Error();
}
// continue in the normal scope
```
And then we have experts that like doing:
```
if(someCondition) {
if (bar) {
$foo = 'narf';
} else {
$foo = 'poit';
}
// huge code block
if($foo == 'narf') {
if(yetAntherCondition) {
// huge code block
} else {
throw new Error();
}
// huge code block
} else {
throw new Error();
}
} else {
throw new Error();
}
```
Help!
If ever was to design a programming language, I'd forbid the `else` and `elseif` keywords. I have yet to find an instance where I could not replace some `else` by either a guard or an early return or introducing some polymorphism.1 -
Not loving the implicit return statement within Scala. I like to avoid else statements to keep the level of nesting low and do early return yet Scala doesn't allow that.
(I am aware that I should flatMap that shit though in some cases I just want a simple if not foo then throw exception line. And continue with the next block until I return something.)
So you either have to create if-else-nesting beats or use pattern matching. The latter seems overly complicated for this use case (though it has its moments).
I know that I can make the return explicit yet the linter warns against that. It feels so verbose and I currently do not see any benefits and would argue that the code becomes both harder to read and maintain.3 -
So I have been migrating my website from AngularJS to Vue as an experiment. I'm late to the party.
It has a navicon that opens a dock, a bar that drops down when you scroll, and some insane particle effect that is first drawn to a canvas and then pushed into a div's background image in real time. Seems nesting Vue instances isn't an option, so I made it into a component.
After two days I finally got it working... and it spazzes the hell out. It's literally the exact same code, but now the canvas starts to flicker like crazy the moment you scroll the page.
Not only have I been doing really filthy stuff like 'var self = this', I have no idea where even to begin debugging this nonsense.4