5 ms·
Tabs do work as long as they aren't fixed width (I don't know what you mean by "custom"). For instance, in many languages, one will sometimes have to split a f
by fstrthnscnd 5y ago
Tabs do work as long as they aren't fixed width (I don't know what you mean by "custom").
For instance, in many languages, one will sometimes have to split a function call to many lines, and in most languages function names aren't of fixed length, thus in order to get a correct alignment for parameters, the tab width at that point will have to match the function name length.
#include<stdio.h>
int main(int argc, char* argv[]) {
printf("%s %s %s %s\n",
__FILE__,
__LINE__,
__DATE__,
__TIME__);
return 0;
}
I agree with your idea of storing a normalized version of the code in the repo: it wouldn't then matter whether that version contains characters to align the code properly, it would just be inserted by the editor/linter as needed. The difficulty is that sometimes linting isn't enough, and some manual formatting is needed. Or perhaps the formatting rules are under specified?
Another issue with AST diffing is when languages allow some form of syntactic sugar as preprocessing: the compiler might just see the simplified tree, not the one with the "sugary" forms. A tool capable of parsing such languages should also be able to handle these extensions.
- Asraelite 5y ago> the tab width at that point will have to match the function name length. This is a non-issue. Use tabs for indentation and spaces for alignment.
- njharman 5y agoThat is the kind of problem solution that ends up with you now having 2 problems. New problem(s); having tabs and spaces, having to think when to use them, having to train/document everyone in usage, having to debate that usage, having to correct code and chastise people who get usage wrong. Use a automatic code formatter with minimal options. Automate either running code formatter on commit or denying commits that change when code formatter is run on them.
- Asraelite 5y agoAbsolutely, I wouldn't dream of doing any kind of fancy alignment by hand, only with an auto-formatter. If I had to break arguments onto multiple lines without an auto-formatter I would just keep it simple and use another level of indentation instead of aligning them with the function name.
- Latty 5y agoBetter yet, just never do alignment. Obviously readability is subjective, but personally I find alignment is never valuable outside of tables of data, and I'd argue generally having tables of data embedded in your code isn't ideal. #include<stdio.h> int main(int argc, char* argv[]) { printf( "%s %s %s %s\n", __FILE__, __LINE__, __DATE__, __TIME__ ); return 0; } Reads better to me and avoids the issue entirely. It also plays more nicely with traditional diff tools anyway.
- fstrthnscnd 5y agoYes, that was more or less the argument I was trying to do by the end of my comment: diffing is meant to be space agnostic (the -B option of diff(3)), but since code is committed with formatting, formatting will interfere.
- fstrthnscnd 5y agoInteresting idea. This will work with C (for now), but it will fail with language like C++ where you can have lambdas. When a lambda is a function parameter, it will need to be aligned to other parameters, but the lambda body will require indentation. Of course, there are ways of avoiding the problem, eg. by using a variable for the lambda, yet isn't this sweeping things under the rug?