WIKI errors for sift.c example in IFFParse Library docs

Report errors, omissions, etc. regarding the AmigaOS Documentation Wiki here.

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

Postby xenic » Wed Oct 18, 2017 1:15 am

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
xenic
 
Posts: 1148
Joined: Sun Jun 19, 2011 1:06 am

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

Postby tonyw » Thu Oct 19, 2017 12:08 am

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
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 1321
Joined: Wed Mar 09, 2011 2:36 pm
Location: Sydney, Australia

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

Postby LyleHaze » Fri Oct 20, 2017 1:18 am

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
LyleHaze
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 511
Joined: Sat Jun 18, 2011 5:06 pm
Location: Georgia, USA, just North of the Florida border

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

Postby tonyw » Fri Oct 20, 2017 8:22 am

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
User avatar
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 1321
Joined: Wed Mar 09, 2011 2:36 pm
Location: Sydney, Australia

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

Postby dstastny » Fri Oct 20, 2017 8:12 pm

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
dstastny
 
Posts: 42
Joined: Fri Dec 16, 2016 7:31 am
Location: Atlanta GA

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

Postby tonyw » Sat Oct 21, 2017 10:22 am

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
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 1321
Joined: Wed Mar 09, 2011 2:36 pm
Location: Sydney, Australia

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

Postby Hypex » Mon Jul 09, 2018 7:53 am

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. :-)
User avatar
Hypex
Beta Tester
Beta Tester
 
Posts: 382
Joined: Mon Dec 20, 2010 3:23 pm
Location: Vic. Australia.

Previous

Return to AmigaOS Documentation Wiki

Who is online

Users browsing this forum: No registered users and 0 guests