Go Down

Topic: error compiling (Read 979 times) previous topic - next topic


K&R and Linux kernel standard

Yeah, but if you're programming on a VT100 then reducing the number of lines in your code is important. These days a line saved here or there is pretty irrelevant and the only justification I can see for that style is habit. Putting each { and } on a separate line and indented by the same amount roughly halves the amount of work needed to spot the matching pairs.

If you indent correctly, no work is needed to spot the matching pairs. Any good text editor should highlight matching parenheses/etc as well.


That, I think was one of my most important discoveries, that and placing the cursor at the point of the curly brace to find the matching one. Now If I could only find a translator for the cuneiform output of the compiler error messages... 

--> WA7EMS <--
"The solution of every problem is another problem." -Johann Wolfgang von Goethe
I do answer technical questions PM'd to me with whatever is in my clipboard


Any good text editor should highlight matching parenheses/etc as well.

That works OK if the matching brace/paren/square bracket is in the window. Vertical alignment works even when the curly brace is beyond the top or bottom edge of the screen.

And, of course, no text editor can highlight the braces on the paper that comes out of the printer, while vertical alignment still works.


If you indent correctly, no work is needed to spot the matching pairs.

If you assume that the indentation and the braces match each other, that's true. But in this case you're effectively ignoring the braces and relying on the indentation. And the visual check that you need to perform to verify that the braces and the indentation match is roughly twice as difficult since you have to scan up the page to find which line the brace is expected to be on, and then across to the far end of the line to confirm it's there. And then do the same thing with all the intervening blocks to confirm that the brace you're looking at really is the matching pair of the one you started from.

Relying on a smart code editor to find matching pairs for you is all very well, but only when you have that editor available. For example, most of the Arduino code I look at here, I look at online on a passive web page with no language support. Quite often it's so poorly laid out that I need to copy it out into an external editor to make any sense of it. In my day job I use a wide variety of editors in different environments and they don't all have support for bracket matching. Even when they do, it's a pain to have to do the mouse-move, click, see where the matching bracket was rather than just run your eye up the page to find it. It's better than nothing, but no substitute for getting the code layout right in the first place. There is a definite advantage to putting the matching pairs of braces on separate lines indented by the same amount. It makes it much easier to visual find and pair them up without requiring any tools support.
I only provide help via the forum - please do not contact me for private consultancy.


Oct 14, 2012, 08:00 pm Last Edit: Oct 14, 2012, 08:04 pm by dc42 Reason: 1

first, sorry for my English.
I'm trying to mount a simulated bomb, when compiling I get the error "was not delcared key4 In This scope"
Code many times I've looked and can not find the problem.

There is a line:

Code: [Select]

delay(10);// waits for a secondchar key4 = keypad.getKey();

I think that line should be split like this:

Code: [Select]

delay(10);// waits for a second
char key4 = keypad.getKey();

However, there are lots of other lines that look as if they have been joined together by mistake.

btw the comment is wrong, delay(10) does not wait for a second.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

Go Up