I keep getting caught out with mismatched Curly Braces, probably with my cr@p programming style and poor skills (still very much a newbie with two weeks under my belt)
Is there any golden rules or tricks I should know about as it is taking me ages to debug my program.
In the Arduino editor, use CTRL-T on the keyboard to autoformat the code. The indentation is a key to the structure, and missing braces usually stand out very well.
Also, if you set the text cursor to a brace, parenthesis, etc. the editor showing you the matching item.
I have trouble with that, too. Every 'open' must have a 'close' so I make sure they are set in pairs, the same number of 'open' as 'close' ones.
Might be a point to count them. If they are on even numbers you're half way there. if they are odd, time for some recreational chemistry (The art of converting Ales, Fine Wines and Spirits into Urine)
Curly braces are used to encompass a block of code that belongs together
Amongst other things they are used for the code belonging to
- functions
- for loops
- while loops
- do loops
- if statements
In addition they are used round values in
- arrays
- enums
There are other uses but they follow the same rule. The major problems occur when the opening and closing braces are not matched as pairs. As suggested, Auto Format in the IDE can show up many problems with misplaced or missing braces.
I find it particularly helpful to put each curly brace on its own line. Then every opening brace should have a matching closing brace at the same level of indentation from the left margin when Auto Formatted
It is also worth compiling at regular intervals so a problem with a recent change is more easily spotted
When working in the IDE, clicking on an open brace { will cause the IDE to hilight the matching }. Saves me hours of time, because counting on my fingers and toes slows me down, because I have to take off my socks!
2 Likes
You can call them curly, but they are just braces.
The editor I use puts out a closing brace when I type an opening brace.
And for other ppls' code I can "balance" braces, brackets and parentheses from within and it will select all that the section contains or demonstrate that it is unmatched.
a7
Very Good !! Ha Ha
So does the Arduino IDE
1 Like
I could just say that's the editor I use but TBH I never noticed that in the IDE!
a7
Even better, if the start of the code block is off the top of the screen when you click on a closing brace the pop-up will tell you what the brace belongs to. Unless, of course, you are using IDE 2.0 where this useful functionality has not been implemented
It also used to be the case that when double clicking on a brace in the IDE that the whole code block was highlighted which really made it stand out and it could be copied easily if required, but this functionality was removed when the classic IDE editor was "improved" many versions ago
I noticed that the IDE editor does add the closing brace but, it is on the next line and may not show on the screen. Often I type a line of code, press enter not seeing the added closing brace and add my own. so now there is an extra one!
1 Like
When typing, I always type {} rather than just the opening brace.
2 Likes
The idea sounds OK but if you do that you have to move the cursor back in order to enter the code which is, at best, annoying
I do too. Same for open close parens on if or for. Also, if I use malloc, the free goes in right then too. Same for opening and closing files.
I take @UKHeliBob's point about inefficiency - my co-workers have pointed it out watching me code but I prefer not to give myself a chance to forget something that will be a debugging nightmare a few days later.
At least with the IDE supplying the closing brace when you type the opening one that is one less thing to worry about
Common compiler errors caused by mismatched brackets:
"does not name a type" or
"expected declaration before" or
"expected unqualified-id before" or
"expected initializer before" or
"expected constructor, destructor, or type conversion before '(' token"
Usually means you forgot a '{' or put in an extra '}' in the previous function. Since all of the open brackets have been closed, the compiler is looking for further global declarations (variables or functions). If it finds something that looks like executable code instead of a global declaration it emits an error. Make sure that the brackets in the preceding function are in matching pairs '{' followed by '}'.
"a function-definition is not allowed here before '{' token"
(can cause: "'functionName' was not declared in this scope")
Usually means you forgot a '}' or put in an extra '{' in the previous function. Since a set of brackets has not been closed yet the compiler is looking for more code to put in the function. You can't declare a function inside a function so if the compiler finds a function declaration it emits an error. Make sure that the brackets in the preceding function are in matching pairs '{' followed by '}'.
"expected '}' at end of input"
Usually means you forgot a '}' or put in an extra '{' in the last function in the sketch. Since a set of brackets has not been closed yet, the compiler is looking for more code to put in the function. When it hits the end of the file instead, it emits an error. Make sure that the brackets in the last function are in matching pairs '{' followed by '}'.
"expected primary-expression before '}' token"
Usually means you have an incomplete statement before a '}'. The block statement (between '{' and matching '}') can only contain complete statements. Complete statements always end with ';' (or '}' for a block statement).
1 Like
A common format that I find helpful is
ISR(TIMER1_COMPA_vect){ //timer1 interrupt
asm ("sbi %0, %1 \n": : "I" (_SFR_IO_ADDR(PINB)), "I" (PINB3)); // Toggle Board Pin 12
for (int i =1; i < 8; i++){
PORTD |= (1 << i);
delayMicroseconds(OnTime);
PORTD = 0x00;
delayMicroseconds(interPulseDelay);
}
}
I start the open brace on the same line as the creating function.
Then put the matching closing brace at the same indent as the opening brace function.
1 Like
IMO, most coding/indention/brace styles including K&R, IndianHill, Whitesmiths, GNU, linux kernel, and others suffer from the inability to visually quickly find / line up matching braces. Some more so than others.
The Haskell style, IMO, is just plain goofy.
IMO, the easiest to see matching braces is the Allman style.
As you can always simply scroll up or down to find the matching brace at the same indention level.
The Allman style is my personal choice and I've been using this style for nearly 40 years.
Allman style always puts the braces on their own line indented to the same level as the associated code starting off the section.
while (x == y)
{
something();
somethingelse();
}
That said, I've seen wars over coding / indention / brace styles, particularly within groups of employees at a company or on projects.
It seems similar to wars about religions.
It seems invoke quite a response and often nobody wants to see any value in the other guys way of doing things.
It is not just bracing styles, it can over using tabs vs spaces and how much an indention level should be. i.e. 8 vs 4 character positions
In my experience through the decades, the only thing I tended to see fairly broad agreement on is to not alter the style within a file when editing it or making changes
. i.e. when you modify a file use the same style even if it makes you barf.
--- bill
1 Like