WIKI errors for sift.c example in IFFParse Library docs

[xenic]

I copied the sift.c example in the WIKI "IFFParse Library" docs, removed some binary codes from the sources and attempted to perform a simple compile with "GCC sift.c -o sift" and found the following errors:

sift.c:(.text+0x220): undefined reference to `OpenClipboard'
sift.c:(.text+0x4e0): undefined reference to `CloseClipboard'
sift.c:64: warning: assignment from incompatible pointer type

I had to make the following changes:

Changed 'OpenClipboard' to 'IIFFParse->OpenClipboard'
Changed 'CloseClibboard' to 'IIFFParse->CloseClipboard'
Changed 'IIFFParse = (struct IFFPaseIFace*)' to 'IIFFParse = (struct IFFParseIFace*)' [missing an 'r' character]

The sift program works with the above corrections in the source but the output could be made a little clearer with the findings on seperate lines. The bugs in the source are minor but it wouldn't hurt to fix the sift.c source so that it will compile correctly.

[trixie]

Fixed the errors, thanks for reporting.

[salass00]

Anyone else think the indentation style of those iffparse examples should be changed to something more easily readable?

I'm fine with either:

Code: Select all

if (expression) {
    blah();
}


or:

Code: Select all

if (expression)
{
    blah();
}


The current style gives me a headache just from looking at it.

[xenic]

Anyone else think the indentation style of those iffparse examples should be changed to something more easily readable?

I find that having braces on seperate lines easier to read and follow:

Code: Select all

if (expression)
{
    blah();
}


That is also the method recommended at openamiga.org Guidelines/Code Styleguide.

It would be nice if the examples in the WIKI could be downloaded as source files. Whenever I copy & paste code from the WIKI, I end up removing some binary codes and reformatting the code.

[tonyw]

Don't get me started on code formatting. I have been involved in many formal and informal projects over the years, and those that have laid-down standards usually have little in common. Such rules as indenting, variable/function names, order of function parameters, use of white space and format of comments all vary from one project to another. Then, of course, there are the local rules for documentation. It all takes up valuable time adapting one's habits to a new set of rules each time.

Two things that annoy me particularly (for purely aesthetic reasons) are:
1. variable names all in lower case, the words joined by underscores (such as "engine_water_temperature"); and
2. braces not matched vertically (as Fredrik quoted above).

I agree with xenic on this one. When reading someone else's code, I don't like having to search earlier rows of text to find the start of this block. I like to be able to see the opening brace, at the same indent as the close.

[salass00]

1. variable names all in lower case, the words joined by underscores (such as "engine_water_temperature"); and

I don't really have a preference either way regarding variable naming, but in my own code I usually use all lower case letters for local variables and reserve use of capitalised names for global variables to keep them somewhat separate.

2. braces not matched vertically (as Fredrik quoted above).

Personally I find it just as easy to match the closing brace to the corresponding if, while, for, do or switch statement.

In fact one might argue that having the opening brace on the same line as the if, while or whatever makes it more clear that it's not just a solitary block for limiting the scope of variables defined in it.

Also you didn't say what you think of the style on the wiki which is:

Code: Select all

if (expression)
    {
    blah();
    }


[tonyw]

Ye gods, I didn't notice that one. Looks awful. In my view, the outside of the opening brace is at the same level as the preceding statement. Inside the brace is one level higher, so it should (IMHO) read:

Code: Select all

if (expression)
{
    blah();
}


[broadblues]

Also you didn't say what you think of the style on the wiki which is:

Code: Select all

if (expression)
    {
    blah();
    }


That gets my down vote too!

Cooincidentally I just worked through some code, which whilst other well written used that indenting style, and I was twitching like madman by the end of it

There seem a wide slection of style in that wiki article.

There tools for fixing suich things in src code not sure you could easily apply them to the wiki though.

[broadblues]

It would be nice if the examples in the WIKI could be downloaded as source files. Whenever I copy & paste code from the WIKI, I end up removing some binary codes and reformatting the code.

Indeed, it's because the wiki code converts spaces to nonbreaking spaces to preserve the code layout, would be useful to be able to download or copy unmodified src clips to the clipboard, I guess a different wiki "code plugin" might be required for that.

[OldFart]

@Thread

[LURKINGMODE=OFF]
It's been a while since I last posted anything on any Amiga-related thread: due to circumstances I've become a lurker por the past one-and-a-half year. In that timespan I've changed address more often then in the preceding 6 decades and hence, I don't care to unpack and setup my X5000 again or any time soon.

However, Tony wrote and this piqued my interest:

Two things that annoy me particularly (for purely aesthetic reasons) are:
1. variable names all in lower case, the words joined by underscores (such as "engine_water_temperature"); and
2. braces not matched vertically (as Fredrik quoted above).

I couldn't agree more and, being a stickler for coding style, I'd like to take the opportunity to add some more:
3. Function names all in lower case, the words joined by underscores (such as "_all_i_wanted_to_know_about_sex_"). This seems a bit of a trend in places like Github. I'm all for a style ressembling an oral command as "<Command>_<Subject>", like "Get_Record", or "Calculate_NettResult". Function names in Amiga's libraries look quite like this.
4. braces not only matched vertically, but utilising the odd columns (1, 3, 5, etc., etc.), while text starts on even columns.
5. Allways use braces! Even if it encloses only one line of text.
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.

Ok guys, that's it. Back to:
[LURKINGMODE=ON]