[prev in list] [next in list] [prev in thread] [next in thread]
List: helix-open-discuss
Subject: RE: [Open-discuss] Coding standards document
From: <Alan.Blaylock () nokia ! com>
Date: 2005-05-10 15:32:27
Message-ID: 456943D540CFC14A8D7138E64843F853971B01 () daebe101 ! NOE ! Nokia ! com
[Download RAW message or body]
Concur completely with this.
In Series60, guidelines are very strict for us regarding warnings. Anything we can \
do to encourage reduction of, as opposed to hiding of, warnings in code prior to \
check-in is a Good Thing. While the rest of the Helix world is not being held to \
Series60 coding standards, we are. The relevant text from our Coding Conventions \
document follows.
"Code should pass compilation without warnings.
There must be a well-known and very good reason to ignore warnings. Warnings that \
should genuinely be suppressed throughout the system should be suppressed by a common \
header file. Use PC-Lint or similar source code checker to make additional checks on \
code to catch some of the bugs, inconsistencies, and oversights in it."
Regards,
A-
-----Original Message-----
From: open-discuss-bounces@helixcommunity.org
[mailto:open-discuss-bounces@helixcommunity.org]On Behalf Of ext Eric
Hyche
Sent: 10 May, 2005 08:23
To: 'Ryan Gammon'; open-discuss@helixcommunity.org
Subject: RE: [Open-discuss] Coding standards document
I agree with Ryan and Greg - we should probably open
up the firehose for most warnings to come through
on most platforms. If we find really really nitpicky
warnings that we decide to ignore, we should be
able to selectively turn those off on particular
platforms.
The more warnings we see on the most-commonly-developed-on
platforms, the more warnings will get fixed before
they even get checked in.
Eric
> -----Original Message-----
> From: open-discuss-bounces@helixcommunity.org
> [mailto:open-discuss-bounces@helixcommunity.org] On Behalf Of
> Ryan Gammon
> Sent: Monday, May 09, 2005 10:24 PM
> To: open-discuss@helixcommunity.org
> Subject: Re: [Open-discuss] Coding standards document
>
> Part of this is tool configuration.
>
> Our win32 command line options for warnings are:
> /W3
>
> ... on win32, and on linux/gcc:
> -Wall -Wreturn-type -Wno-ctor-dtor-privacy --permissive
>
> There's a fairly big gap between the two.
>
> Eg, if we turned on:
> C4265 - class has virtual functions but destructor is not virtual
> C4018 - signed / unsigned mismatch (should already on with /W3?)
> C4100 - unreferenced formal parameter
> C4101 - unreferenced local variable
> C4061 - enumerate 'identifier' in switch of enum 'enumeration' is not
> explicitly handled by a case label
>
> ... and, with gcc, turned off:
> -Wno-reorder (or figured out how to turn something like this
> on in msvc)
>
> ... we'd be a little closer to living in the same world on cl & gcc.
>
> Rob Lanphier wrote:
>
> > The problem with "go with the flow" can be found by
> following how we got
> > here in the first place:
> >
> > 1. The folks at Dextratech has been stumbling into a bunch
> of problems
> > extracting the compiler warnings from the code, scattered
> all about the
> > codebase
> > 2. They worked with Eric to come up with this document:
> > https://porting.helixcommunity.org/WarningAvoidance
> > 3. Now a lot of us are wondering "why isn't this part of the coding
> > standard?" (answer: because there isn't a published coding standard)
> >
> > There are certain things that are always a good idea. Perhaps my
> > mistake is trying to take a "coding style" document and turn
> it into a
> > "coding standard" document. I have no desire to burn a lot of time
> > quibbling over which line the opening angle bracket belongs
> on, but if
> > there are things we can prominently document that actually makes our
> > code more likely to build on more platforms, that seems like a more
> > productive exercise.
> >
> > Rob
> >
> > On Mon, 2005-05-09 at 17:41 -0700, Greg Wright wrote:
> >
> >
> > > Ryan Gammon wrote:
> > >
> > >
> > > > Rob Lanphier wrote:
> > > >
> > > >
> > > >
> > > > > I think you may have misunderstood my question. Where
> and how would
> > > > > this be documented? For example, I plan to add a link to
> the document
> > > > > from the "Policies" page (off the right nav of the home
> page). I'm also
> > > > > planning on referencing it in the Patch Submission Guidelines.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > Maybe make rule #1 of the helix coding style "go with the flow"?
> > > >
> > > > eg, from other style specs:
> > > >
> > > > Use the prevailing style in a file or module, or ask
> the owner, if
> > > > you are on someone else's turf. Module owner rules all.
> > > >
> > > >
> > > Modifications to existing files will be the majority of all
> submissions
> > > I would guess. If there really is going to be a major piece of new
> > > work (new files created ect) then we will probably have
> been talking about
> > > it on the lists for a while (SOD talk and the like) so I
> don't think there
> > > will be much confusion.
> > >
> > > So, I like the idea of adding a 'go with the flow' bullet point.
> > >
> > > --greg.
> > >
> > >
> > >
> > >
> > > > http://www.mozilla.org/hacking/mozilla-style-guide.html
> > > >
> > > > Where there are slight stylistic differences, the style in the
> > > > surrounding code should be followed. These are
> guidelines; use your
> > > > own best judgement.
> > > >
> > > > http://gnome.org/projects/evolution/patch.shtml
> > > >
> > > >
> > > >
>
>
> --
> Ryan Gammon
> rgammon@real.com
> Developer for Helix Player
> https://player.helixcommunity.org
>
>
> _______________________________________________
> Open-discuss mailing list
> Open-discuss@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/open-discuss
>
_______________________________________________
Open-discuss mailing list
Open-discuss@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/open-discuss
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic