WIKI errors for sift.c example in IFFParse Library docs

Report errors, omissions, etc. regarding the AmigaOS Documentation Wiki here.
xenic
Posts: 1164
Joined: Sun Jun 19, 2011 12:06 am

Re: WIKI errors for sift.c example in IFFParse Library docs

Post by xenic »

OldFart wrote: 6. use of tabs. As a great mind once remarked about not setting the tabwidth to 4 (or was it 8?) is like redefining pi to something different from 3.14. His observation was quite right, but his conclusion did not match mine. My stance on this one is: don't use tabs, but spaces as they are unubiquitous.
[LURKINGMODE=ON]
I prefer tabs. You can change the indentation by changing the tab width in a good editor and it's easy to convert tabs to spaces in most cases. It's just a personal preference.
AmigaOne X1000 with 2GB memory - OS4.1 FE

User avatar
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 1407
Joined: Wed Mar 09, 2011 1:36 pm
Location: Sydney, Australia

Re: WIKI errors for sift.c example in IFFParse Library docs

Post by tonyw »

Agreed, tabs are more versatile in formatting the text for differing tastes. The AmigaOS devs use a tab spacing of 4.
cheers
tony

User avatar
LyleHaze
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 520
Joined: Sat Jun 18, 2011 4:06 pm
Location: North Florida, near the Big Bend

Re: WIKI errors for sift.c example in IFFParse Library docs

Post by LyleHaze »

I thought religious discussions were off-limits. :lol:

I agree well with most of what has been said. I also confess that I am guilty of having no specific format for variable and function names.
It's bad enough that I have asked for a "guide sheet" and I keep it open when writing new code. Also, when taking a break from writing, I often go back over the code looking for missed names.

There is one habit that I picked up deliberately, that is sometimes frowned on by others. It was suggested by a Comp-Sci professor over dinner one night. When comparing a variable to a constant,
I now always put the constant first. This has the rather nice side-effect of throwing an error if I forget the second equals sign. For example:

Code: Select all

if(NULL == some_pointer)
{
    DealWithNothing();
}
Now if I accidentally drop an equals, making this an assign instead of a compare:

Code: Select all

if(NULL = some_pointer)
{
    DealWithNothing();
}
I get an error that I cannot assign a value to NULL.

It's not "earth shattering", but it has removed one frequent flier from my bug list.

I'll lastly say that I try to keep an open mind, my coding style is always evolving, and hopefully always will.

User avatar
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 1407
Joined: Wed Mar 09, 2011 1:36 pm
Location: Sydney, Australia

Re: WIKI errors for sift.c example in IFFParse Library docs

Post by tonyw »

If you enable all warnings in gcc, any construction like:

Code: Select all

		if (totalSectors = 0)
		{
		}
will throw the message:
warning: suggest parentheses around assignment used as truth value

It's not the same as saying "you idiot, you've left out the second '=' sign", but it does obviate the "if (0 == totalSectors)" eyesore.
cheers
tony

dstastny
Posts: 42
Joined: Fri Dec 16, 2016 6:31 am
Location: Atlanta GA

Re: WIKI errors for sift.c example in IFFParse Library docs

Post by dstastny »

I have only recently been back to coding C/C++ and like both those tips. I think the warning one is probably more practical for me as I have always been very OCD about warnings and cringe at the projects(scarily large production projects) I see that happily spew thousands of warnings and the teams are like "what no big deal".

Regards,
Doug

User avatar
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 1407
Joined: Wed Mar 09, 2011 1:36 pm
Location: Sydney, Australia

Re: WIKI errors for sift.c example in IFFParse Library docs

Post by tonyw »

Quite agree, enable all warnings and the "treat warnings as errors" state also. A module that compiles with warnings displays careless workmanship.

Another one of my favourite hates is code that is difficult or impossible to read and maintain. We are not immortal and one day, some other poor bastard is going to have to read this code and maintain it. Let's at least make his life a little easier.
cheers
tony

User avatar
Hypex
Beta Tester
Beta Tester
Posts: 403
Joined: Mon Dec 20, 2010 2:23 pm
Location: Vic. Australia.

Re: WIKI errors for sift.c example in IFFParse Library docs

Post by Hypex »

I'm glad to read this and see people agree with my thoughts about "bracing". In the outside world, or open source world, it is common to split braces so they are out of alignment and the make it a coding rule for any writers. For example:

Code: Select all

if (expression) {
    then();
} else {
    this();
}
Now this may be faster to write but I hate the formatting as it is split up. It's slower to do but I prefer the one below. Mostly for neatness and readability:

Code: Select all

if (expression)
{
    then();
}
else
{
    this();
}
Now when comparing for non-zeros I have been guilty of:

Code: Select all

if (!expression)
Instead of:

Code: Select all

if (expression == NULL)
I am changing my ways there. Aside from ordering of values, I can see the bottom is more clear what it does, but because of my background I imagine the compiler producing poor code that actually checks the variable against zero instead of testing it and using the CPU Z flag. I just don't trust compilers. Which always seem to lack basic optimisation by reloading registers with what they just loaded in there a couple of instructions ago. :-)

xenic
Posts: 1164
Joined: Sun Jun 19, 2011 12:06 am

Re: WIKI errors for sift.c example in IFFParse Library docs

Post by xenic »

Hypex wrote:I am changing my ways there. Aside from ordering of values, I can see the bottom is more clear what it does, but because of my background I imagine the compiler producing poor code that actually checks the variable against zero instead of testing it and using the CPU Z flag. I just don't trust compilers. Which always seem to lack basic optimisation by reloading registers with what they just loaded in there a couple of instructions ago. :-)
Just out of curiosity I wrote a simple program that just contains a single 'if' statement and compiled it to assembler (gcc -S test.c -o test.s) and (expression == NULL), (NULL == expression) and (!expression) all produced exactly the same assembler code. I would agree that (expression == NULL) makes it clearer what's being tested.

P.S. The compile was done with GCC in the public SDK.
AmigaOne X1000 with 2GB memory - OS4.1 FE

Post Reply