-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Conversation
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}; |
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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; \ | ||
} \ | ||
}; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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}; |
There was a problem hiding this comment.
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...
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.
I updated my branch to restore the trailing |
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 😄 ) |
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. |
@stephane what about merging this one? Or at least the .clang-format-file. Having one commit will simplify the life of reviewers. |
Thank you @pboettch for initial proposal.
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.