C Sources Styles Consistency

[tajmone]

@thoni56,

I've began enforcing consistent code styles for C source, as you can see in the EditorConfig-C-Sources branch of my fork.

My approach is to work one folder at them time, since there are lots of sources and I want to visually inspect them one-by-one to ensure they are being correctly formatted.

The main problem is mixed indentation (tabs and spaces), which I'd like to fix by converting all tabs to spaces, and then enforce spaces indentation (without specifying any width).

After having looked at many .c and .h sources, it seems to me that the original tabs were 8 spaces, because when I set them to that all code aligns perfectly (especially comments). I then proceed to convert all tabs to spaces and inspect each file before committing.

To keep things simple, I'm adding a temporary .editorconfig settings file to each folder, as I reformat it, instead of having a root folder.

Once all folders are done, I'll delete those temporary settings and just add a rule for C files in the main .editorconfig.

Before carrying on with this work (which is quite huge and time consuming) I just wanted to make sure that this is something you're willing to accept a PR for, and (in case yes) whether you'd prefer me to submit a PR for every fixed folder or just submit one big PR once they're all done (with the latter, the risk is that if you update your sources I'll have to redo some files from scratch).

PS: Enable Discussions!

[thoni56]

I can see no reason what so ever to put energy and work into this.

Before carrying on with this work (which is quite huge and time consuming) I just wanted to make sure that this is something you're willing to accept a PR for

If saying no to this question is the only way I can steer your energy back towards the much, much more important Alan project, I will.

This project is unmaintained. There will be no updates, new features, or even fixes (barring blocking the Alan project), There are no other users than the Alan compiler (me). As long as this compiles on any of the modern platforms it will serve its purpose.

The only concern might be #1, in which case only compiler settings and minor tweaks will be necessary.

I know you mean well, and probably are a genuine mender. Sorry, to sound harsh, but could you please go back to the valuable work you are doing in the many facets of the Alan project?

[tajmone]

I can see no reason what so ever to put energy and work into this.

As for the why, there are two reasons, one being technical:

1. Code consistency is always good.
2. Alignments are not showing up properly (i.e. as intended) both on GitHub and locally (this can though be remedied by simply specifying in .editorconfig that tabs should be 8 spaces wide, without disallowing mixed indentations).
3. Many editors will enforce consistent indentation at save time, causing lots of spurious noise changes in the modified source file, making commits harder to track.

As an example of (1), you can see in my initial commit for src/toolmake/spa.h how the source comments look before and after.

The other why has to do with the fact that I'm interested in studying its source and experimenting with it, because I've been allocating part of my free time to studying language designs — this is something I've been doing for years, slowly, in order to compensate my lack of academic training in computer programming.

I know you mean well, and probably are a genuine mender. Sorry, to sound harsh, but could you please go back to the valuable work you are doing in the many facets of the Alan project?

This won't really affect the time slots allocated to ALAN (or any other project). As mentioned, I'm always devoting at least one day of the week to studying parsing, lexing and compiler design (be it reading a book or studying some C sources). Example, I've been studying the Lemon source for quite a while, and maintain a repository dedicated to Lemon and other related projects (especially forks that generate parser in other langs, or ports to other langs):

• https://github.com/tajmone/lemon-grove

I really like Lemon and the Gold parser, much more than Yacc/Bison or ANTLR, partly due to their different philosophies, partly due to the quality of the sources (i.e. Lemon, since Gold sources were never published due to the project having gone stale).

You mentioned that you did attempt to use other (more mainstream) parsers generators for ALAN, that so far none worked out of the box. As you already know, since day one I've joined ALAN I always wanted to create an Italian-specific IF system that would be capable of handling all the complex Italian constructs that are always clumsy to handle in most English systems — e.g. the adjective sometimes following the noun, as in "prendi la mela rossa", other times preceding it "prendi la prima mela").

This project is unmaintained. There will be no updates, new features, or even fixes (barring blocking the Alan project), There are no other users than the Alan compiler (me). As long as this compiles on any of the modern platforms it will serve its purpose.

Well, than it's one more good reason for being able to do the reformatting a bit at the time, since source aren't going to change between one commit and another. When I said "huge and time consuming" work, I rally only meant the visual checking part, for the tabs fixing is actually fast — but again, the problem with tabs, especially with decades old code, is that there's always the risk that different authors with different editors settings might have introduced standards differences in the code.

Let's make this deal:

1. I promise you I'll be dedicating very little time to reformatting the C sources, just a few minutes now and then, whenever I get to actually study the sources.
2. Once all the files are ready in my fork, I'll create a PR — at that point, you'll know for sure that I'll have visually inspected all changes (file by file) to ensure that the newly formatted code looks like it was intended to (i.e. aligning tabs to 8 spaces).
3. If for any reasons you won't merge the PR, it's fine (no harm done, I was warned!) — but at least I'll have my own branch with consistent code, which is a bit easier for me to study and to experiment with.

[thoni56]

I can see no reason what so ever to put energy and work into this.

As for the why, there are two reasons, one being technical:

1. Code consistency is always good.
2. Alignments are not showing up properly (i.e. as intended) both on GitHub and locally (this can though be remedied by simply specifying in .editorconfig that tabs should be 8 spaces wide, without disallowing mixed indentations).
3. Many editors will enforce consistent indentation at save time, causing lots of spurious noise changes in the modified source file, making commits harder to track.

Ok, fair enough. I didn't actually mean that I did not understand the merits of doing this. For those I'm totally committed to pretty and readable code. To me that is more about the actual code, such as naming, structure, responsibilities, etc. but formatting also matters.

And I did not mean that it created work for me either.

What I meant was the value of doing it. As always there is a trade-off and we all have limited time. Again, I would value those "few minutes" more on the Alan project.

But as I can see from your reasoning, much of this is for your own benefit. And for that I won't prevent anything ;-)

the problem with tabs, especially with decades old code, is that there's always the risk that different authors with different editors settings might have introduced standards differences in the code.

That war is still on... But yes, definitely in this project, built piece by piece over at least a decade by different people and before tight collaboration made us aware of how much better it is with a consistent, enforced style in a project.

Let's make this deal:

1. I promise you I'll be dedicating very little time to reformatting the C sources, just a few minutes now and then, whenever I get to actually study the sources.

Yes, we really need you on the Alan project!

2. Once all the files are ready in my fork, I'll create a PR — at that point, you'll know for sure that I'll have visually inspected all changes (file by file) to ensure that the newly formatted code looks like it was intended to (i.e. aligning tabs to 8 spaces).

I'm not sure I concur with your conclusion about 8 spaces, When it comes to trailing comments I'm sure it has to do more with Emacs comment-column and set to prefer tabs. But no matter, as long as it's pretty ;-)

3. f for any reasons you won't merge the PR, it's fine (no harm done, I was warned!) — but at least I'll have my own branch with consistent code, which is a bit easier for me to study and to experiment with.

And that is really the only thing of actual value here.

It's a deal ;-)

[tajmone]

That war is still on...

Indeed, the "Tabs vs Space" Holy War is still live and kicking, and fuelling flame wars all over the place as ever (just like Emcas vs Vim). The good news is that, according to a StackOverlfow report based on data analysis, Developers Who Use Spaces Make More Money Than Those Who Use Tabs! :wink:

Yet (salary benefits aside), it turns out that indentation-agnosticism didn't pay off at all, especially for Makefiles, where tabs are highly recommended, yet spaces are also sometimes mandatory (and will break things up if turned to tabs). That alone (with Make being such a pervasive tool) serves as a good reminder that overlooking small details can come at greatly costs in the long term.