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.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]
WIKI errors for sift.c example in IFFParse Library docs
Re: WIKI errors for sift.c example in IFFParse Library docs
AmigaOne X1000 with 2GB memory - OS4.1 FE
- tonyw
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: WIKI errors for sift.c example in IFFParse Library docs
Agreed, tabs are more versatile in formatting the text for differing tastes. The AmigaOS devs use a tab spacing of 4.
cheers
tony
tony
- LyleHaze
- AmigaOS Core Developer
- Posts: 525
- 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
I thought religious discussions were off-limits.
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:
Now if I accidentally drop an equals, making this an assign instead of a compare:
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.
![Laughing :lol:](./images/smilies/icon_lol.gif)
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();
}
Code: Select all
if(NULL = some_pointer)
{
DealWithNothing();
}
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.
- tonyw
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: WIKI errors for sift.c example in IFFParse Library docs
If you enable all warnings in gcc, any construction like:
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.
Code: Select all
if (totalSectors = 0)
{
}
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
tony
Re: WIKI errors for sift.c example in IFFParse Library docs
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
Regards,
Doug
- tonyw
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: WIKI errors for sift.c example in IFFParse Library docs
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.
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
tony
Re: WIKI errors for sift.c example in IFFParse Library docs
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:
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:
Now when comparing for non-zeros I have been guilty of:
Instead of:
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. ![Smile :-)](./images/smilies/icon_e_smile.gif)
Code: Select all
if (expression) {
then();
} else {
this();
}
Code: Select all
if (expression)
{
then();
}
else
{
this();
}
Code: Select all
if (!expression)
Code: Select all
if (expression == NULL)
![Smile :-)](./images/smilies/icon_e_smile.gif)
Re: WIKI errors for sift.c example in IFFParse Library docs
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.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.
P.S. The compile was done with GCC in the public SDK.
AmigaOne X1000 with 2GB memory - OS4.1 FE