5 ms·

> 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 ago
That 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 ago
  Absolutely, 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 ago
Better 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 ago
  Yes, 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 ago
Interesting 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?

njharman 5y ago

That 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 ago
Absolutely, 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 ago

Better 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 ago
Yes, 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 ago

Interesting 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?