Coding standard enforcement at compiler level

[sebastian.bu...@gmail.com]

Problem definition: Most projects have a document called 'Coding standards' that represent rules for how the programmers should use C++. Most of these documents basically define a subset of C++ that is enforced for that project. But the enforcement is usually done at the code review level where people point out when some C++ usage violates the rules. Since these code reviews aren't always as thorough as they should be, or there aren't any code reviews due to other constraints, wouldn't it be nice if the compiler could enforce these rules and wouldn't let a piece of code compile when the rules of the coding standard have been violated?

Solution (proposed): Since C++ has object oriented support, I thought of something similar. You have a base class that represents the full set of the C++ standard. In order to enforce this class you don't have to do anything, so all C++ projects out there can choose to implement this enforcement in their own time if they choose to. This base class can be derived to add rules: for example you add the rule that goto is banned. Then, you add something that would look like a preprocessor #ifdef - #endif block that means that for that part of code the subclass rules are enforced, thus any goto gets flagged and not allowed. These subclasses can be derived further and more and more rules be enforced. With each derivation, more things from the C++ standard are removed. So you only substract with each derived class, you cannot add a new rule that goto is allowed after its superclass banned it.

But, at the code level, the subclassing is not enforced, you can have a block that bans goto and inside have a subblock that allows it temporarily. The basic idea isn't to have a million of these classes enforcing a billion rules but to be able to divide the codebase in things like high-level code and low-level code. In the high level portion you aren't allowed to use things like pointer hacking, or naked pointers, while in the low level portion everything, or most things, are allowed. This way, if somebody is trying to modify some piece of code that he has never seen before, he doesn't need to guess the way that code should be written in that module just by looking at the neighbouring code, but can actually jump to the class that defines the rules and can read and follow them from there. And if he doesn't follow them he can't compile. If he chooses to create a subblock where he allows himself to do what he pleases, that is something that can be seen easier in the repository. Since creating new rules is basically creating new headers (or maybe a new type of file, special for these rules), it's easier to control who creates the rules in a team so that not everybody can use and create whatever rule he wants whenever he wants (that would defeat the purpose of trying to enforce the coding standard). 

Since I've heard that the module concept is coming to the next version of C++, maybe this would be a good idea to enforce the coding standard at the module level.

Right now I am only interested to see the reaction for this proposal as I haven't mapped out the nitty gritty details and see what corners this design would force you into, so what do you think about the idea of finding a way to enforce a subset of C++ at the compiler level?

[Jonathan Coe]

This feels more like a tooling issue than a language issue to me.

I've used clang-tidy 

http://clang.llvm.org/extra/clang-tidy/ to enforce (parts of) in-house style guides with great success. Would that do what you need?

clang-tidy config files can be set in different places in the code to apply different checks in different places.

Regards

Jon

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7b9f1b29-cd23-4a12-9711-90d69de78669%40isocpp.org.

[sebastian.bu...@gmail.com]

I know tools like static analysis and lint work, but they are not universal. Of course, keeping it outside the compiler is neater because it separates things, but what I was proposing was a universal lint of sorts. Microsoft has a linter, Clang has one, but the problem is learning each of these tools when switching projects and also that I am not sure that you can enforce these hierarchies depending on modules like I am talking about. It would make C++ more 'portable' in a way.

[Peter Koch Larsen]

As Jonathan pointed out, this is a tooling issue. I do not see any
reason to let this be part of the C++ standard.
Imagine the amount of work needed by the standard committee to sort
out what is good and what is not a good part of C++. Do we really want
the committee to focus on stuff like that - unlikely to be agreed upon
before 2026 - instead of using its time on valuable stuff such as
coroutines, modules and concepts?
And frankly, what is the value of such a feature? Just use clang or
other tools (for goto, grep comes to mind) to detect violations of a
coding standard.

/Peter

> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/be2c389a-4624-43d3-8205-72c364e1c632%40isocpp.org.

[sebastian.bu...@gmail.com]

Nobody is asking the committee to sort what is good or what is bad in C++. The whole idea is to allow the user to select that for himself what he considers valuable. goto was just an example, the idea was to have something more general. grep wouldn't help since it would select all instances without knowing which should be accepted and which shouldn't. Just use clang? Not everybody uses clang. Not everybody considers clang good. The tools can't detect if a particular thing from the coding standard is allowed in some piece of code or not. They only detect at project level. And that was my whole idea, give more granularity at code level. Which would require the thing to be implemented in the compiler. Which probably would mean that it should be in the C++ standard.

[Ricardo Fabiano de Andrade]

I think the only way to sort of achieve what you're asking in a way that could be part of the standard and verified by compilers would be a form of annotations.

One kind of "annotation" present in the language are the attributes which gives the compiler more information about a piece of code, such as [[noreturn]], [[fallthrough]], [[nodiscard]], [[maybe_unused]], etc.

Maybe you could propose a new set of attributes or even extended that idea to be actual language annotations (as present in C#, Java).

However, there's a limit to what can be done using attributes according to the current standard, you should check that before proposing anything.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9a3ddbb7-346e-434e-98bd-c2440bae630d%40isocpp.org.

[Brittany Friedman]

If you think this would be a cool feature to standardize, then please focus on making an actual implementation inside an existing compiler. It is a very bad idea to try and standardize something that doesn't exist and has had no user experience. There is a large design space to consider here and arguing over the details won't be very fruitful when all we have to work with is our imagination.

[Arthur O'Dwyer]

On Wednesday, January 25, 2017 at 1:28:06 PM UTC-8, sebastian.bu...@gmail.com wrote:
>

> The tools can't detect if a particular thing from the coding standard is allowed in

> some piece of code or not. They only detect at project level.

This sounds like a tooling issue.

> Just use clang? Not everybody uses clang. Not everybody considers clang good.

This sounds like a clang-specific tooling issue. If you can point to a specific way in which clang-tidy is suboptimal for your use case, the clang bugzilla is thataway -->. Or if it's just a generalized "I feel uncomfortable about Clang monoculture and wish there were some other really good toolsets out there," I suppose there's nothing stopping you from implementing a "competitor" toolset today. (There's also some very innovative static-analysis stuff coming out of MSVC lately, and PVS-Studio, and surely other things I'm not personally aware of. You could try out those tools for your use case and again, if you find specific shortcomings, file bugs or feature requests.)  Anyway, you should try the existing tools before asking for completely new things that may or may not be any better.

On Wednesday, January 25, 2017 at 1:37:50 PM UTC+2, Peter Koch Larsen wrote:
> Imagine the amount of work needed by the standard committee to sort
> out what is good and what is not a good part of C++.

Technically, they're doing that all the time; and if there are any "bad parts" of C++, someone's failing at their job. /tongue-in-cheek

(If there were actually no reason to use goto, the standard would get rid of it. Compare goto's situation to that of C++03 auto and auto_ptr, which were undone in C++11 and C++17 respectively. Quality control is being done.)

–Arthur

[Klaim - Joël Lamotte]

To me it looks a lot like proposing another standard, that could or not be adopted by several tools.

But maybe it's too early for that, or maybe some format (clang-format?) is already a defacto-standard.

Any way, the C++ standard should probably focus exclusively on the language that have semantic,

while providing precise information and extension points for tools reading it (like annotations).

Joël Lamotte

--

You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cd5ca87d-1f4a-4d78-a9b7-f4fafdabf5a2%40isocpp.org.