Introduce cpplint check

[mathieucarbou]

Wit hsome filters that are not impacting a lot the current code

[vortigont]

it removed all override and explicit keywords, even in comments :)))

[mathieucarbou]

it removed all override and explicit keywords, even in comments :)))

for explicit, this is my mistakes.

Also, I disabled the explicit check: runtime/explicit : I do not know how much it is relevant to put explicit on ctors who need it ?

About override, this is not necessary when final is there. If final is there it implicitly means override.

cpplint justs check: I did the cleaup.

[mathieucarbou]

FYI, please review / approve but please do not merge yet: I would prefer to do the release first and merge after. Thanks!

[vortigont]

OK, if it's only with finals.
For explicit it could be useful sometimes for constructors having non-default args to ensure it accepts only specified type.

[vortigont]

looks Ok'ish )

[me-no-dev]

why relative? chance to have another header with the same name elsewhere?

[mathieucarbou]

no - that's just a cpplint request to have path indications when using "..." instead of <...> in order to have the includes formatted the same way everywhere. I think this one is ok, but we can disable this check if we want.

[me-no-dev]

it's not the same though. Well it will point to the same file, but not in the same way. "literals.h" is file in one of the include paths, while "./literals.h" means file in the same folder as the file which includes it that way

[mathieucarbou]

yes I know the difference...

I think cpplint uses this programming convention:

• "./path/to/include.h"
• <from/compile/path/include/h>

They "ask" devs to follow this convention (if we keep the flag).

I am personally not against this convention since it adds more clarity when reading the code.
Currently, this is a mess in our code base for the includes. There is no strict conventions.

[me-no-dev]

it will work either way in this case (relative or not), but just last few days we've been dealing with some relative paths in ESP-IDF too and they've proven to be messy. Anyway, I just wanted to know why did you opt for relative path. Otherwise, my understanding is that "header.h" is library/project local include, while <header.h> is something that comes from elsewhere (another library)

[mathieucarbou]

Otherwise, my understanding is that "header.h" is library/project local include, while <header.h> is something that comes from elsewhere (another library)

Yes the rational comes from that.
And that's also the convention cpplint is enforcing with this check.
So if OK we can go with that for the project from now on, and maybe on day take the opportunity to cleanup the existing includes.

[me-no-dev]

LGTM