[RDY] Refactor path module

[lslah]

No description provided.

[schmee]

Nice! I'm going to move some additional functions into path.c later today. ref #414

[lslah]

This is actually not much yet, but I'd prefer not blowing up PRs and thus would mark this as ready as soon as someone has reviewed the changes.

Also if anyone else wants to proceed on refactoring this module, feel free to do so. It'll probably take some days until I'd continue this.

[schmee]

I'll take a look at this later today! I will look for more refactorings, after all it was my PR that created this mess ;)

[lslah]

@schmee Thanks, that'd be nice. And no, you haven't created the mess, but nicely extracted it in order to make it solvable. ;)

[lslah]

Unfortunately my last git --amend hides this discussion about constant names.

I think the general question is, whether constant names in enums should have a common prefix or not.

A common prefix makes it easier to classify a random constant in the code (i.e. you know which enum type the constant belongs to).
Not having to prefix a constant makes it sometimes easier to find readable, verbose names.

The constants which raised the question are the possible return values of path_full_compare formerly known as fullpathcmp:

kFilesEqual
kFilesEqualNames
kFilesDifferent
kFilesMissingBoth
kFilesMissingOne

vs.

kEqualFiles 
kEqualFileNames 
kDifferentFiles 
kBothFilesMissing 
kOneFileMissing

Maybe @tarruda can decide which way to go?

[schmee]

LGTM 👍

[lslah]

@schmee Thanks for reviewing! I'll just wait until the naming-issue above is solved before I mark this PR as ready.

[schmee]

As soon as this gets merged I'll start moving stuff from os/fs.c into path.c.

[lslah]

Marked as ready, since I don't want to prevent @schmee from introducing further improvements in this module and the naming thing doesn't seem to be such a big issue.

[tarruda]

Merged, thanks

[aktau]

@tarruda @lslah this still had the seperator vs separator spelling error in it. I also think we should still adhere to the style guide, now that we have one and are making changes.

[lslah]

@aktau Sorry for my mistake with separator in the test file. I fixed it in path.c and path.h but somehow overlooked the test-file. I'll fix this in a sepArate PR.
Can you please point out more specific what's wrong with the style in this PR?

[Hinidu]

@lslah In touched lines I see some /* */ comments, absence of curly braces in one-line ifs and not aligned arguments in function calls. Maybe @aktau talked about it.

[lslah]

@Hinidu You probably mean the definition of gettail_dir. I just moved this function to a sensible place near its usage but haven't actually modified the definition itself. Sure, I can also adapt this function to the style guide, but I think that would look as if it's already refactored as well. I also changed the name of four functions and touched therefore a lot of lines where there're called, but didn't adapt these lines to the style guide.

If there are also style issues in the functions I've refactored, I'd be glad if you could add line notes and I'd definitely fix them together with my misspelling.

[Hinidu]

@lslah I don't see style issues in refactored code.