Page 2 of 2

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

PostPosted: Wed Oct 18, 2017 1:15 am
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.

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

PostPosted: Thu Oct 19, 2017 12:08 am
by tonyw
Agreed, tabs are more versatile in formatting the text for differing tastes. The AmigaOS devs use a tab spacing of 4.

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

PostPosted: Fri Oct 20, 2017 1:18 am
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.

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

PostPosted: Fri Oct 20, 2017 8:22 am
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.

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

PostPosted: Fri Oct 20, 2017 8:12 pm
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

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

PostPosted: Sat Oct 21, 2017 10:22 am
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.

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

PostPosted: Mon Jul 09, 2018 7:53 am
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. :-)