freeDSP / freeDSP-aurora

freeDSP ADAU1452 with 8 analog input, 8 analog outputs, S/P-DIF I/O, ADAT I/O, USB Audio Class2, WiFi, Bluetooth
Creative Commons Attribution Share Alike 4.0 International
176 stars 55 forks source link

Major code style refactoring for better code readability and maintenance. #124

Closed exislow closed 1 year ago

exislow commented 1 year ago

As described in #117 I have done some code style refactoring. as you can see it complies with a majority of current C code style guidelines. The code is way more easier to read and maintain. Tell me what you think about it. Looking forward for acceptance of this PR, so I can continue pushing some features / ideas of mine. Thanks!

dspverden commented 1 year ago

Thank you! I will have a review now asap.

exislow commented 1 year ago

Do you have any comments or can we even merge it?

dspverden commented 1 year ago

I did review it. Did you make it by a formatter? I would prefer to have a layout style that comes closer to Stroustrup’s and STL, Boost coding styles. Therefore, for a function I would do void do_something(void) { blalblabla }

instead of

void do_something(void) { blalblabla }

Can you setup that in your formatter? Please, see this guide for details: https://style-guides.readthedocs.io/en/latest/cpp.html

I really would come closer to Stroustrup’s style. I know, there is a lot of Hungarian notation. My fault. Call it evolution... ;-)

exislow commented 1 year ago

The code style refactoring was assisted by a formatter indeed.

You have mentioned Stroustrup’s coding style guide as well as https://github.com/povilasb/style-guides (https://style-guides.readthedocs.io/en/latest/cpp.html), which actually has 0 stars on GitHub. This seems to be not a very popular style. It is also awkward to have, e.g. a 8 spaces tab indent and function braces on a separete line but class braces on the same line.

A lot of more popular code styles have slightly better approaches. Maybe those code style guidelines (huge indents, braces on separate lines for readibility etc.) have been beneficial in the last decades, but with the vast majority of today's IDEs and it's highlighting techniques code readibility is better, if the code is not bloated by spaces / new lines. This fact is also supported by the default settings of different code formatters.

I would vote for braces on the same line instead of bloating up the code.

dspverden commented 1 year ago

Can you provide me a link to the GitHub rating of code styles?

exislow commented 1 year ago

What do you mean exactly? Here are the very first results of https://www.google.com/search?q=GitHub+rating+of+code+styles

All of them suggest to keep it like this:

void do_something(void) {
    blalblabla;
}
dspverden commented 1 year ago

Ah I think I was confused by your story with the zero stars on GitHub. ;-) Actually I am totally fine with that what you made. The only point I would change is insert a newline before the opening brace of a function (and only of a function). This just taste. I am used to that. But if the majority is fine with the way you did it, then ok. I am not a fundamentalist.

exislow commented 1 year ago

Okay, cool. Thank you for your effort. Then I would appreaciate it, if you could just merge it this way.

Spoiler: I am already on some PRs regarding better UI/UX for the standard plugins incl. some easy importing functions for REW output.