Re: [edk2-devel] [edk2-CCodingStandardsSpecification PATCH 1/1] Update the Name Space Rules page examples to follow the coding standard

["Michael D Kinney" <michael.d.kinney@intel.com>]

Pushed 

https://github.com/tianocore-docs/edk2-CCodingStandardsSpecification/commit/0d88b4742209c162c37f5dab282a1c5990e15aa8

Mike


> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek
> Sent: Monday, December 7, 2020 6:32 PM
> To: devel@edk2.groups.io; rebecca@nuviainc.com; Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Leif Lindholm <leif@nuviainc.com>; Andrew Fish <afish@apple.com>
> Subject: Re: [edk2-devel] [edk2-CCodingStandardsSpecification PATCH 1/1] Update the Name Space Rules page examples to
> follow the coding standard
> 
> Hi Rebecca,
> 
> On 12/07/20 03:25, Rebecca Cran wrote:
> > The examples in the 45_name_space_rules.md files doesn't follow the
> > coding standard in the following ways:
> >
> > - Only use UEFI data types. Use of standard C data types is prohibited.
> > - Identifiers shall contain mixed upper- and lower-case text.
> >
> > Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > ---
> >  4_naming_conventions/45_name_space_rules.md | 14 +++++++-------
> >  1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/4_naming_conventions/45_name_space_rules.md b/4_naming_conventions/45_name_space_rules.md
> > index 1234250756cc..ecdebbe28339 100644
> > --- a/4_naming_conventions/45_name_space_rules.md
> > +++ b/4_naming_conventions/45_name_space_rules.md
> > @@ -53,9 +53,9 @@ tags may be reused only for union types.
> >
> >  ```c
> >  typedef struct MyStruct {
> > -  int  one;
> > -  int  two;
> > -  int  three;
> > +  UINT32  One;
> > +  UINT32  Two;
> > +  UINT32  Three;
> >  } MY_STRUCT;
> >  ```
> 
> Style-wise, the update looks good.
> 
> Code wise, I can't tell from this context whether changing from int to
> UINT32 makes any difference. I guess using INT32 rather than UINT32
> would fix the style, and also keep the C language meaning identical.
> 
> So please consider going with INT32, but if it doesn't matter (again, I
> can't tell from this context), then feel free to keep the UINT32.
> 
> Either way:
> 
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
> 
> Mike, can you please push this?
> 
> Thanks!
> Laszlo
> 
> >
> > @@ -68,14 +68,14 @@ Exceptions are structure member and union member names.
> >
> >  ```c
> >  typedef struct StructOne {
> > -  INT32             one;
> > -  INT16             two;
> > +  INT32             One;
> > +  INT16             Two;
> >    struct StructOne  *MySelf;
> >  } STRUCT_ONE;
> >
> >  typedef struct StructTwo {
> > -  INT16             one;
> > -  INT8              *two;
> > +  INT16             One;
> > +  INT8              *Two;
> >    struct StructTwo  *MySelf;
> >  } STRUCT_TWO;
> >
> >
> 
> 
> 
> 
> 
>