How do you find missing brackets/braces?

[Tduck]

I've been searching for hours in my code, and I simply can not find where the missing closing bracket is. There are 58 { open brackets, but only 57 } closed brackets; one is missing and I can't seem to pinpoint it. Are there any methods to finding the missing brackets.

https://docs.google.com/document/d/1oZ8YEeVq5lYz7yCNpxt4mptzwjo1ildlmaE2PwZiSeo/edit?usp=sharing
The code is too long to post here so I've made a shareable link if anyone is up to the challenge of sifting 300~ lines of code for a 58th bracket.

[kbw]

By using correct short blocks and consistent indentation.

[DrewRiddles]

If you are using visual studios, the error generated is clickable. Clicking on the error will show you exactly where the bracket is missing. Other than that, I can’t really help you. Sorry!

[Tduck]

I'm on my chromebook right now, but I will defenitley try to click on the error when I get back to my computer and visual studio.

[lastchance]

                    {
                        cout << "You dodged the Gelatinous Cube!" << endl;
                    }
                }    // <===== Should be here
                else if(turnType == "potion")
                {

[doug4]

In situations where your code blocks are fairly lengthy and nested, not only is consistent indentation absolutely critical, but you should add a comment to each closing brace to indicate what it is closing. Then you can more easily match up opening and closing braces to find what is missing, or where braces have been misplaced.

I would recommend either using tabs or spaces for your indentation, not both. When you post code to a forum with a different tab size, the indentation becomes out of whack

[JLBorges]

> the challenge of sifting 300~ lines of code for a 58th bracket.

20. Avoid long functions. Avoid deep nesting.

Summary

Short is better than long, flat is better than deep: Excessively long functions and
nested code blocks are often caused by failing to give one function one cohesive re-
sponsibility (see Item 5), and both are usually solved by better refactoring.

Discussion

Every function should be a coherent unit of work bearing a suggestive name (see
Item 5 and the Discussion in Item 70). When a function instead tries to merge such
small conceptual elements inside a long function body, it ends up doing too much.
Excessive straight-line function length and excessive block nesting depth (e.g., if,
for, while, and try blocks) are twin culprits that make functions more difficult to un-
derstand and maintain, and often needlessly so.

Each level of nesting adds intellectual overhead when reading code because you
need to maintain a mental stack (e.g., enter conditional, enter loop, enter try, enter
conditional, ...). Have you ever found a closing brace in someone's code and won-
dered which of the many fors, whiles, or ifs it matched? Prefer better functional de-
composition to help avoid forcing readers to keep as much context in mind at a time.

Exercise common sense and reasonableness: Limit the length and depth of your
functions. All of the following good advice also helps reduce length and nesting:
• Prefer cohesion: Give one function one responsibility (see Item 5).
• Don't repeat yourself: Prefer a named function over repeated similar code snippets.
• Prefer &&: Avoid nested consecutive ifs where an && condition will do.
• Don't try too hard: Prefer automatic cleanup via destructors over try blocks (see
Item 13).
• Prefer algorithms: They're flatter than loops, and often better (see Item 84).
• Don't switch on type tags. Prefer polymorphic functions (see Item 90).

Alexandrescu and Sutter in 'C++ Coding Standards: 101 Rules, Guidelines, and Best Practices'

[keskiverto]

I would recommend either using tabs or spaces for your indentation, not both.

A decent editor would have a function to reindent code systematically (and support systematic formatting in the first place).

Even that helps only little, if the error lurks somewhere in long and deep function. In worst case the code looks syntactically correct, apart from the trailing missing/surplus }.

[jonnin]

This is why I really hate the book format :

void bookish(){
  there is 
  a lot of code in between
{
  making it hard to see 
} //misaligmed brace?  where is the matching opening brace?

vs
void clean()
{
  code
{ //this isnt good, but I can see it
  more code
  stuff
}//I can see the alignment now.  

The biggest help for me has been 'defensive coding practice' though.
if I type { then I must immediately type } and back up to fill in between.
Same for <> () etc pairs. The stuff in between may be wrong, but the various enclosing marks will never be off.

[TheIdeasMan]

If one is using an IDE, then it should be possible to get the IDE to automagically do closing braces or pairs of <> etc for you.

[Duthomhas]

Yes, get a decent editor and use the editor’s ‘find-matching-brace’ powers to comb through your code.

I also like AStyle (http://astyle.sourceforge.net/) for fixing random code people post here before I look too hard at it.