Incorporate PR feedback for link icon change

[malxau]

This is addressing the feedback in #304 :

1. Use ATTR_SYMBOLIC | ATTR_JUNCTION to test whether something is a link, since a reparse point is not always a link; it could be a virtual git file, store app, onedrive placeholder, all kinds of things;
2. Use braces around if conditions. There was a commit for this in the original PR but it wasn't included in the merge.

[schinagl]

The braces which I added were merged.
The questions is where braces should be put.
From trying to understand the coding conventions and mimic the current situation in this project, there should be braces when there is more than one statement after an if/else/for/while/...
E.g

if (5 == 4) {
  x = 2;
  y = 3;
} else
  x = 42;

But I could be wrong, and basically I am fine with any convention.

[malxau]

Right, the convention of a lot of this code is inconsistent - not just about brace location, but tabs/spaces and indent depth. There's some conversation about it in #88 . Reading it now, I overlooked this comment from Craig:

+1 on the "keeping with the spirit of the codebase". That said, we should probably go with one spacing/bracing style. If we can agree on one, I would be fine with one big PR to fix it all one way.

Unfortunately I'm not sure how to get to one PR for this without relying on a tool of some kind - the way some code indents with three spaces vs four for example is really hard to address manually. Braces are at least more visually obvious. I know some teams at Microsoft use clang-format now, although I've never found a set of options that really conform to the principles that humans find natural.

[schinagl]

But I doubt, that reformatting the whole source has an extra value at this stage of the project.
So my plan is to smell the very local coding convention, and mimic it as best as possible for my changes, so that my diffs are small and esay to review.

[craigwi]

This is the Allman style.

[craigwi]

This is K&R style.

[craigwi]

So my plan is to smell the very local coding convention, and mimic it as best as possible for my changes, so that my diffs are small and esay to review.

Agreed. This PR actually has two styles mixed together. I made comments on one case. Can we do one or the other?

[malxau]

I think the challenge we have is trying to conform to neighboring code when the neighboring code is so inconsistent. Each function has examples of each style. Since this PR was already changing coding style of existing code, I tried to make the entire functions consistent.

This commit attempts to use Allman, since that's what you'd expressed a preference for in #88 . It also uses spaces for indentation, using a shift width of 4. I think this is the style we're moving towards (right?)

When reviewing the changes in Github, under the "files changed" tab there's a gear icon, and that allows the change to be viewed with or without whitespace. The whitespace changes are about using a shift width of 4; hiding these shows the bracing style changes.

[schinagl]

This project was written in K&R/3 spaces indent. Some changes are in Allman, but 90% are still in K&R now.

With reformatting even partially to Allman/4 spaces you cause conflicts with all private builds, and open PRs.
And it does not stay with a few methods, this spreads.

I personally favour Allman, and all my other stuff is Allman, but for this project I switched to K&R/3 spaces, and my 2 cents is, that it should stay as close to the original stuff. This simply is the spirit of Winfile, written some time in 198x.

Changing the source formatting to Allman/4 spaces in my opinion has no benefit, and only introduces risk and problems.

[craigwi]

Short of a massive reformatting, staying with K&R/3 makes sense. Thanks!

[schinagl]

It seems we are stuck here a little bit.
To get us out of this I made a proposal branch, which has @malxau changes in, but has very little reformatting in, so that it would fill in smoothly (at least I guess:-))

See schinagl:link_icon_feedback_proposal

If this is fine four you @malxau, take it, push it and I guess @craig will sign it?

[malxau]

Thanks @schinagl and sorry for going quiet. I looked at your change, and it doesn't include the addition of braces which I thought was something that needed doing. If we're not doing that, we also don't need to go over code formatting at all. So here's a brutally minimal change instead...