Check for bad white space before running tests

[eschnett]

No description provided.

[tkelman]

This would break building when git is not present, which we should theoretically support via NO_GIT. I'll modify the check-whitespace target so it gets skipped in that case.

[eschnett]

Maybe we should use find and perl instead of git? This way, we could also look for tabs, could check for trailing empty lines, missing newlines on the last list, tab/space confusion, etc.

[tkelman]

That might make sense, but be careful with what you assume find supports - it's quite likely that the OSX, GNU, and BSD versions are all a bit different.

[eschnett]

I was thinking of using -name ... and -print, maybe augmented by a -type f. But we could also emulate find with perl.

Or, we write the checker in Julia. When we are about to run the tests, there's a functional Julia environment.

[ihnorton]

Realistically this only matters when git is present. If you aren't sending
something upstream, whitespaces are between you and your editor.
On Jan 17, 2015 7:18 PM, "Erik Schnetter" [email protected] wrote:

I was thinking of using -name ... and -print, maybe augmented by a -type f.
But we could also emulate find with perl.

Or, we write the checker in Julia. When we are about to run the tests,
there's a functional Julia environment.

—
Reply to this email directly or view it on GitHub
#9809 (comment).

[tkelman]

There's also no need to search through files that aren't checked in.

[tkelman]

Let's try this out. Any objections to merging?

[timholy]

I guess the idea here is to detect whitespace problems before things get submitted to Travis? Given that we have Travis set to fail, that seems like a good idea.

But just checking: among large, active open-source projects, how common is it to be dogmatic about whitespace? I'm just wondering about the balance between keeping the codebase clean and putting up yet one more barrier (learning git is bad enough) for new contributors.

[tkelman]

We'd have to restrict that search to languages that don't yet have good auto-formatting tools. I think a better long-term solution than failing for nitpicky stuff like this would be to write a jlformat tool that just fixes trivial stuff automatically, and run it on base once a week or so. We could also pretty easily adopt clang-format for the C/C++ source, though it might be fiddly to come up with a configuration that closely matches what we've been doing so far (since clang-format is highly configurable).

Problem is no one has written such a tool for Julia yet, AFAIK. I think it was a suggested GSoC project last year, and presumably will be again this year unless someone implements it before then.

[jakebolewski]

@timholy (my personal) long-term goal was to start a process where we would eventually have automated style / syntax checks against any code submitted to base. Pretty much every large open source project has this. Whitespace was first, it is easy to check for and cleans up diffs, but hopefully more will come later. As @tkelman pointed out, a set of agreed upon standards makes it easier to write automated tools. Maybe the make target should be make check-format to get the point across.

Tools like clang-format don't get written in a vacuum. clang-format was written because the LLVM / Clang project adopted a set of standards that they rigorously enforced. This was painful, so someone initiated the process to enforce those standards automatically.

[timholy]

Thanks for explaining. Since I find it annoying when I run across code that uses tabs rather than spaces, I am persuaded that long term this will be a good thing.