Both proposals sound good to me. As for the issue with _ _ being reserved (I was aware of *leading* _ _ being reserved, but not _ _ anywhere in the name); I guess I'm not too concerned since I've never heard of a problem with our usage. Although 0 files do it already, we could switch to a single trailing _. Does that sound reasonable to you Nick? It's hard to have a strong opinion on the subject other than wanting consistency :)
Cheers, Luke ----- Original Message ----- > Hi, > > The standardization of our #ifndef wrappers came up in bug 881579. > Here are some examples: > > - jsapi.h: jsapi_h___ > - gc/Barrier.h: jsgc_barrier_h___ > - vm/Stack.h: Stack_h__ > - ion/Ion.h: jsion_ion_h__ > > Observations: > - Omitting the directory is dangerous if we ever have two files with > different directories but the same name. > - Decapitalizing filenames seems odd. > - Adding the |js| prefix for files that don't have a |js| prefix > seems odd. > - The first two end with three underscores, and the last two end with > two underscores. (We have 149 headers that use 2, and 99 that use > 3.) > > I propose that we do the following: take the full path within > js/src, > replace '/' and '.' with '_', and add two underscores to the end. > For > example: > > - jsapi.h: jsapi_h__ > - gc/Barrier.h: gc_Barrier_h__ > - vm/Stack.h: vm_Stack_h__ > - ion/Ion.h: ion_Ion_h__ > > Thoughts? > > ---- > > Relatedly, we sometimes omit header directories. E.g. instead of > #include "ion/Ion.h", we do #include "Ion.h". This only works for > headers that are in the same directory, e.g. in ion/AsmJSLink.h we > have > > #include "AsmJSModule.h" // |ion/| omitted because AsmJSLink.h > is in ion/ > #include "frontend/BytecodeCompiler.h" // |frontend/| present > > (Also, we add -I($srcdir)/yarr and -I($srcdir)/assembler for some > reason. which allows those prefixes to be omitted.) > > I propose that we require the directories, and get rid of the yarr > and > assembler -I options. This increases consistency of the #include > lines, and makes putting them in sorted order easier. Thoughts? > > ---- > > I figure Luke has final say on these matters. I'll update the style > guide with whatever we decide. Thanks. > > Nick > > ps: if you're worried about enforcement of the style, I'm working > towards a #include-checking script in > https://bugzilla.mozilla.org/show_bug.cgi?id=880088. > _______________________________________________ > dev-tech-js-engine-internals mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals > _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
