Still it is nice to know that missing parenthesis and missing curly brackets might be the source of hard to read code. I can always do a markup for just my personal comprehension.
Loopy
Three notes to keep in mind.....
A missing parenthesis will cause a compiler error. Parenthesis(s) are used in pairs - parentheses. In many instances, parentheses can sometimes be omitted, but are often added to comparisons and equations to make the code easier to read.
A missing bracket will cause a compiler error. Brackets are used in pairs. In some instances, brackets can be omitted, such as after a conditional statement, when the condition is followed by one line or extended line of code, ending with ( ; ) . Omitting brackets produces faster code writing, but reduces readability.
Yes indeed. I do read and resolve the compiler errors.
But it is the code that compiles without errors and doesn't work right that has got me stuck. One really has to study what is going on and run down every item for flaws.
Currently I compile without errors,
But the calls to G1 don't seem to do anything. (I suspect that I have got a problem in the parser and maybe my fdserial configuration is wrong.)
And I have the setup() initiate all the enables to High. I confirm that they are HIGH when it starts after the first load directly from the compile. But when I reset the Propeller, the 4 LEDS that are tracking the HIGH state won't light again... yet that should. (I suspect something in the way macros are compiled)
But it is the code that compiles without errors and doesn't work right that has got me stuck. One really has to study what is going on and run down every item for flaws.
As you say, "Yes indeed". Tracking down errors when the code compiles, can be a real bear, especially if it is someone elses code and has conditional compilation. You are a braver man than me.
When you work in a group you want the minimum changes implemented per change as it assists in maintainence. If you change formatting as well as actual code you're increasing the complexity of managing changes by an order of magnitude because as an upstream maintainer I now have to grok BOTH your code additions AND your formatting change.
idbruce - re-formatting code for your own understanding and edification is a great way to understand how code flows because it forces you to understand the code flow in order to get your formatting correct.
Lastly, as a maintainer if I accept a re-formatting patch then "git blame" will blame you for all bugs.
If I was the maintainer for openssl that might be an advantage ;-)
Speaking of changes... I have gotten into a muddle with my Tonokip_with_serial clean up.
To progress further I need to use DIFF or one of its successors to try to find out why my code is behaving so oddly.
Heater likes kdiff3, but the three file comparison feature may cause more problems to a new user than it is worth. In Linux, you have a huge choice of utilities... starting with the original DIFF that is a big awkward to use across directories and demands everything be typed at the command line.
The is ColorDIFF that is a bit better than the original. But I wanted a GUI version to make things easier. So far I have loaded flDIFF as it just compares 2 files in a GUI and I'll see if I can make any progress. I also loaded kdiff3 just to see what it is like.
The main thing here is that some sort of DIFF utility is considered an important tool in coding in C and C++. I am not sure what Mircosoft provides for free or sells to do the job.
++++++++++++++
In general, the basic utility has been around for many decades. So there are a lot of variations that better fit personal preferences.
Character based utilities require the user to type the paths exactly right, so a GUI update may be more pleasant to use. But too many bells and whistles can be distracting.
Comments
Loopy
Three notes to keep in mind.....
A missing parenthesis will cause a compiler error. Parenthesis(s) are used in pairs - parentheses. In many instances, parentheses can sometimes be omitted, but are often added to comparisons and equations to make the code easier to read.
Incorrect: ((((code))) produces compiler error
Incorrect: {{{{code}}} produces compiler error
But it is the code that compiles without errors and doesn't work right that has got me stuck. One really has to study what is going on and run down every item for flaws.
Currently I compile without errors,
But the calls to G1 don't seem to do anything. (I suspect that I have got a problem in the parser and maybe my fdserial configuration is wrong.)
And I have the setup() initiate all the enables to High. I confirm that they are HIGH when it starts after the first load directly from the compile. But when I reset the Propeller, the 4 LEDS that are tracking the HIGH state won't light again... yet that should. (I suspect something in the way macros are compiled)
Details, details, details............ Think, think, thing.
As you say, "Yes indeed". Tracking down errors when the code compiles, can be a real bear, especially if it is someone elses code and has conditional compilation. You are a braver man than me.
When you work in a group you want the minimum changes implemented per change as it assists in maintainence. If you change formatting as well as actual code you're increasing the complexity of managing changes by an order of magnitude because as an upstream maintainer I now have to grok BOTH your code additions AND your formatting change.
idbruce - re-formatting code for your own understanding and edification is a great way to understand how code flows because it forces you to understand the code flow in order to get your formatting correct.
Lastly, as a maintainer if I accept a re-formatting patch then "git blame" will blame you for all bugs.
If I was the maintainer for openssl that might be an advantage ;-)
To progress further I need to use DIFF or one of its successors to try to find out why my code is behaving so oddly.
Heater likes kdiff3, but the three file comparison feature may cause more problems to a new user than it is worth. In Linux, you have a huge choice of utilities... starting with the original DIFF that is a big awkward to use across directories and demands everything be typed at the command line.
The is ColorDIFF that is a bit better than the original. But I wanted a GUI version to make things easier. So far I have loaded flDIFF as it just compares 2 files in a GUI and I'll see if I can make any progress. I also loaded kdiff3 just to see what it is like.
The main thing here is that some sort of DIFF utility is considered an important tool in coding in C and C++. I am not sure what Mircosoft provides for free or sells to do the job.
Not sure what windiff does.. seems to be GUI driven, but there is a link to a FREE GUI diff for Windows.
http://www.componentsoftware.com/products/csdiff/screenshots.htm
++++++++++++++
In general, the basic utility has been around for many decades. So there are a lot of variations that better fit personal preferences.
Character based utilities require the user to type the paths exactly right, so a GUI update may be more pleasant to use. But too many bells and whistles can be distracting.
Of course, you can explore the 'all and everything'
http://en.wikipedia.org/wiki/Comparison_of_file_comparison_tools