Message ID | 1326486589-12326-1-git-send-email-peter.maydell@linaro.org |
---|---|
State | Accepted |
Commit | e3c52bf2e59a1caa7a8f4d1eb069cc1406075d10 |
Headers | show |
Since nobody seems to have disagreed, perhaps we should just commit this? -- PMM On 13 January 2012 20:29, Peter Maydell <peter.maydell@linaro.org> wrote: > Clarify that enum type names and function type names should follow > the CamelCase style used for structured type names. > > Signed-off-by: Peter Maydell <peter.maydell@linaro.org> > --- > During a conversation on IRC with Anthony, I realised that the coding > standard isn't entirely clear about what convention should be followed > for enum and function types. This patch resolves that by saying they > should be CamelCase like structured type names, based on Anthony's > suggestion. I've tagged this as an RFC in case anybody would rather > we went the other way instead... > > CODING_STYLE | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/CODING_STYLE b/CODING_STYLE > index 6e61c49..7c82d4d 100644 > --- a/CODING_STYLE > +++ b/CODING_STYLE > @@ -44,7 +44,8 @@ Rationale: > 3. Naming > > Variables are lower_case_with_underscores; easy to type and read. Structured > -type names are in CamelCase; harder to type but standing out. Scalar type > +type names are in CamelCase; harder to type but standing out. Enum type > +names and function type names should also be in CamelCase. Scalar type > names are lower_case_with_underscores_ending_with_a_t, like the POSIX > uint64_t and family. Note that this last convention contradicts POSIX > and is therefore likely to be changed. > -- > 1.7.1 > >
Ping^2 and cc'ing trivial. -- PMM On 23 January 2012 14:12, Peter Maydell <peter.maydell@linaro.org> wrote: > Since nobody seems to have disagreed, perhaps we should > just commit this? > > -- PMM > > On 13 January 2012 20:29, Peter Maydell <peter.maydell@linaro.org> wrote: >> Clarify that enum type names and function type names should follow >> the CamelCase style used for structured type names. >> >> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> >> --- >> During a conversation on IRC with Anthony, I realised that the coding >> standard isn't entirely clear about what convention should be followed >> for enum and function types. This patch resolves that by saying they >> should be CamelCase like structured type names, based on Anthony's >> suggestion. I've tagged this as an RFC in case anybody would rather >> we went the other way instead... >> >> CODING_STYLE | 3 ++- >> 1 files changed, 2 insertions(+), 1 deletions(-) >> >> diff --git a/CODING_STYLE b/CODING_STYLE >> index 6e61c49..7c82d4d 100644 >> --- a/CODING_STYLE >> +++ b/CODING_STYLE >> @@ -44,7 +44,8 @@ Rationale: >> 3. Naming >> >> Variables are lower_case_with_underscores; easy to type and read. Structured >> -type names are in CamelCase; harder to type but standing out. Scalar type >> +type names are in CamelCase; harder to type but standing out. Enum type >> +names and function type names should also be in CamelCase. Scalar type >> names are lower_case_with_underscores_ending_with_a_t, like the POSIX >> uint64_t and family. Note that this last convention contradicts POSIX >> and is therefore likely to be changed. >> -- >> 1.7.1
On Fri, Jan 13, 2012 at 08:29:49PM +0000, Peter Maydell wrote: > Clarify that enum type names and function type names should follow > the CamelCase style used for structured type names. > > Signed-off-by: Peter Maydell <peter.maydell@linaro.org> > --- > During a conversation on IRC with Anthony, I realised that the coding > standard isn't entirely clear about what convention should be followed > for enum and function types. This patch resolves that by saying they > should be CamelCase like structured type names, based on Anthony's > suggestion. I've tagged this as an RFC in case anybody would rather > we went the other way instead... > > CODING_STYLE | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) Thanks, applied to the trivial patches tree: https://github.com/stefanha/qemu/commits/trivial-patches Stefan
diff --git a/CODING_STYLE b/CODING_STYLE index 6e61c49..7c82d4d 100644 --- a/CODING_STYLE +++ b/CODING_STYLE @@ -44,7 +44,8 @@ Rationale: 3. Naming Variables are lower_case_with_underscores; easy to type and read. Structured -type names are in CamelCase; harder to type but standing out. Scalar type +type names are in CamelCase; harder to type but standing out. Enum type +names and function type names should also be in CamelCase. Scalar type names are lower_case_with_underscores_ending_with_a_t, like the POSIX uint64_t and family. Note that this last convention contradicts POSIX and is therefore likely to be changed.
Clarify that enum type names and function type names should follow the CamelCase style used for structured type names. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> --- During a conversation on IRC with Anthony, I realised that the coding standard isn't entirely clear about what convention should be followed for enum and function types. This patch resolves that by saying they should be CamelCase like structured type names, based on Anthony's suggestion. I've tagged this as an RFC in case anybody would rather we went the other way instead... CODING_STYLE | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)