Skip to content
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

Apply and enforce consistent coding style using clang-format-7 #24

Closed
hannob opened this issue May 3, 2017 · 2 comments
Closed

Apply and enforce consistent coding style using clang-format-7 #24

hannob opened this issue May 3, 2017 · 2 comments
Assignees
Milestone

Comments

@hannob
Copy link
Contributor

hannob commented May 3, 2017

Currently expat has no consistent coding style. See e.g. this piece of xmlparse.c:

static XML_Bool  /* only valid for root parser */
startParsing(XML_Parser parser)
{
    /* hash functions must be initialized before setContext() is called */
    if (hash_secret_salt == 0)
      hash_secret_salt = generate_hash_secret_salt(parser);
    if (ns) {
      /* implicit context only set for root parser, since child
         parsers (i.e. external entity parsers) will inherit it
      */
      return setContext(parser, implicitContext);
    }
    return XML_TRUE;
}

XML_Parser XMLCALL
XML_ParserCreate_MM(const XML_Char *encodingName,
                    const XML_Memory_Handling_Suite *memsuite,
                    const XML_Char *nameSep)
{
  return parserCreate(encodingName, memsuite, nameSep, NULL);
}

The first function indents with 4 spaces for the main function, but 2 spaces for the rest. The second function indents with 2 spaces. Similar examples can be found throughout the code.

I don't have any strong feelings about tabs vs. spaces or any other parts of coding style, but I think the style should be consistent within a project (or at least within a source file). To avoid too much unnecessary changes I'd recommend going for a coding style that's as close as possible to the already existing style.

Ideally the coding style should be documented in the form of a set of parameters for a common style checking tool (like clang-format or GNU indent) and there should be a possibility to check the whole code for compliance.

@hartwork
Copy link
Member

hartwork commented May 3, 2017

True. The question is when to best do that transition because any patch we produce after will give a harder time backporting to distros.

@hartwork hartwork added this to the 2.3.1 milestone Oct 20, 2018
@hartwork hartwork changed the title Consistent coding style (Feature request) Apply and enforce consistent coding style using clang-format-7 Oct 20, 2018
@hartwork
Copy link
Member

Set milestone to 2.3.1 as #220 needs to be merged for 2.3.0, first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants