Reformat sources

[madebr]

A lot of sources are malformatted: they contain trailing whitespace and/or don't have a final newline.
It would be nice to fix this formatting asap.
There exist utilities to apply editoronfig rules to all sources retro-actively.

So I'm asking when/if there is an opportunity to massively reformat all files.
CC'ing @z33ky as you're working on a Linux port.

[z33ky]

Thanks for the tag.

Inconsistent spacing icks me a bit, i.e. sometimes it's if(thing), other (I think most) times if (thing). But I am a bit wary of automatic reformatting. I imagine it would mess with purposefully aligned things, like I'm doing here for example. I know tooling exists that is somewhat smart about such things, but I have no experience using these.
I've also seen some functions aligning the names of declared local variables, like here, while other times the type and name are just separated by a single space. The alignment is also using tabs instead of spaces!

I would also be happy to abandon the old-fashioned style of declaring all variables at the top of the function. It does give you a decent view of the stack layout the function will have, but I've never worried about that and instead found it a nuisance when you add or remove variables, or need to worry whether you've already initialized a variable.

But I'm all for consistency. Whatever personal opinions I have on code formatting, I've tried to emulate the existing style(s).
I think it at least makes sense to have guidelines on style of any new code written. If existing code is not reformatted then it should be defined to somewhat follow the existing styles.
A debate could be had what to do about style when modifying existing files or functions (keep prevalent style or change to our style), which would be obsolete if the whole codebase is reformatted by a program.

[madebr]

Thanks for the tag.

Inconsistent spacing icks me a bit, i.e. sometimes it's if(thing), other (I think most) times if (thing). But I am a bit wary of automatic reformatting. I imagine it would mess with purposefully aligned things, like I'm doing here for example. I know tooling exists that is somewhat smart about such things, but I have no experience using these. I've also seen some functions aligning the names of declared local variables, like here, while other times the type and name are just separated by a single space. The alignment is also using tabs instead of spaces!

I would do the reformatting in multiple stages.
First remove all trailing spaces + convert all indentation to hard tabs.
In a next stage, let's add a .clang-format file that emulates the original formatting as best as possible.

I would also be happy to abandon the old-fashioned style of declaring all variables at the top of the function. It does give you a decent view of the stack layout the function will have, but I've never worried about that and instead found it a nuisance when you add or remove variables, or need to worry whether you've already initialized a variable.

Declaring the variables at the top is required by the c89 standard. But we're currently using c11.
Being able to e.g. use local loop variables give more safety.
So I agree on letting go this practice.

But I'm all for consistency. Whatever personal opinions I have on code formatting, I've tried to emulate the existing style(s). I think it at least makes sense to have guidelines on style of any new code written. If existing code is not reformatted then it should be defined to somewhat follow the existing styles. A debate could be had what to do about style when modifying existing files or functions (keep prevalent style or change to our style), which would be obsolete if the whole codebase is reformatted by a program.

I Agree.
For the time being, let's follow the current formatting as best as possible.
I propose to, after your linux port is merged, to clean all trailing spaces + replace all space indentation with tabs.
Do you have an ETA on your linux port?
I would wait with this to don't cause any merge conflicts. Unless you have no objections to this.

[z33ky]

I would do the reformatting in multiple stages.
First remove all trailing spaces + convert all indentation to hard tabs.
In a next stage, let's add a .clang-format file that emulates the original formatting as best as possible.

I don't find it all too important, but I'm also not opposed to it.

Do you have an ETA on your linux port?
I would wait with this to don't cause any merge conflicts. Unless you have no objections to this.

That'll depend on how my effort to decode the compressed audio data goes. I'm walking a bit blind here. Or deaf I guess :P
But I could add a macro, off by default, to disable the OpenAL sound backend for now. I should be able to fix the code for proper display mode setup quickly, then I would consider it to be in a mergable state.