Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CodingStyle: add .clang-format and the derived changes #394

Closed
wants to merge 1 commit into from

Conversation

pboettch
Copy link
Contributor

@pboettch pboettch commented Aug 7, 2017

This commit adds a .clang-format-file which helps to automate
the code-formatting. This file is as close as it gets to the existing
style. Some things are not supported by clang-format yet
(mainly PreProcessorIndent - currently under code-review).

This commit does not necessarily needs to be merged, but it
helps to show inconsistencies.

I'm using clang-format-5.0 (5.0.0-svn305653-1) on Debian.

src/modbus-rtu.c Outdated
@@ -84,8 +83,7 @@ static const uint8_t table_crc_lo[] = {
0x99, 0x59, 0x58, 0x98, 0x88, 0x48, 0x49, 0x89, 0x4B, 0x8B,
0x8A, 0x4A, 0x4E, 0x8E, 0x8F, 0x4F, 0x8D, 0x4D, 0x4C, 0x8C,
0x44, 0x84, 0x85, 0x45, 0x87, 0x47, 0x46, 0x86, 0x82, 0x42,
0x43, 0x83, 0x41, 0x81, 0x80, 0x40
};
0x43, 0x83, 0x41, 0x81, 0x80, 0x40};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, at this point I would prefer having the closing bracket on the next line.
We could also reformat the whole block having 8 or 16 bytes on each line...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no way (I know of) telling clang-format to put the closing brace on the next line on intitializers.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with @mhei

@@ -137,8 +138,7 @@ static unsigned int compute_response_length_from_request(modbus_t *ctx, uint8_t
/* Header + nb values (code from write_bits) */
int nb = (req[offset + 3] << 8) | req[offset + 4];
length = 2 + (nb / 8) + ((nb % 8) ? 1 : 0);
}
break;
} break;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is already "special", I find your version with the break on the same line a bit more difficult to read and understand. I'd prefer to leave it as is...

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm agree with @mhei too

BUG_REPORT(_cond, _format, ##__args); \
goto close; \
} \
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know it's only reformatted, but the trailing semicolon should not be part of define, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These kind of defines you normally put between do { ... } while (0)-loops, without the semicolon as you pointed out.


int req_length;
uint8_t rsp[MODBUS_TCP_MAX_ADU_LENGTH];
int tab_read_function[] = {
MODBUS_FC_READ_COILS,
MODBUS_FC_READ_DISCRETE_INPUTS,
MODBUS_FC_READ_HOLDING_REGISTERS,
MODBUS_FC_READ_INPUT_REGISTERS
};
MODBUS_FC_READ_INPUT_REGISTERS};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here too, the previous formatting looks better IMHO...

@pboettch
Copy link
Contributor Author

pboettch commented Aug 7, 2017

The intention of this commit is to propose a way to impose a common code-formatting all contributors have to respect. A perfect tool does not exists for automation. I actually was surprised that most of the code is coherent. Which is a great sign for this library as it means that code-reviews are really done.

In regards to the tool I chose, it's clang-format because it is integrated into my editor and I can use it to format only a part of the file (the selected lines). What I want to say is, that the .clang-format-file can be present even without changing any line of the existing .c and .h files right now. But future contributions could be indented and aligned with this tool. Should save some time reviewing and integrating.

This commit adds a .clang-format-file which helps to automate
the code-formatting. This file is as close as it gets to the existing
style. Some things are not supported by clang-format yet
(mainly PreProcessorIndent - currently under code-review).

This commit does not necessarily needs to be merged, but it
helps to show inconsistencies.
@pboettch
Copy link
Contributor Author

pboettch commented Aug 8, 2017

I updated my branch to restore the trailing }; on a new line (as it was before).

@mhei
Copy link
Contributor

mhei commented Aug 8, 2017

Please don't get me wrong - I'm not familiar with clang-format, so I was not sure whether this could be configured or not. See my comments to express my personal preferences. I agree that having a tool to check/ensure a nice formatting is very helpful and your PR is really appreciated and 👍 for merging it. Maybe it's possible to extend the functionality of clang-format to match the desired coding style for the two corner cases? (I know this could be a long-term goal 😄 )

@pboettch
Copy link
Contributor Author

pboettch commented Aug 9, 2017

Don't worry, I didn't get you wrong and, just to be sure, neither I felt offended nor do I want to offend.

There is only coherence and the limits of tools trying to maintain this coherence.

@pboettch
Copy link
Contributor Author

pboettch commented Nov 1, 2017

@stephane what about merging this one? Or at least the .clang-format-file. Having one commit will simplify the life of reviewers.

@stephane stephane closed this in dd45f19 Oct 18, 2022
epsilonrt pushed a commit to epsilonrt/libmodbus that referenced this pull request Jun 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants