search

lefticus / cpp_weekly

The official C++ Weekly Repository. Code samples and notes of future / past episodes will land here at various times. PR's will be accepted in some cases.
The Unlicense
695 stars 26 forks source link

Introducing static analysis into a C++ code base #130

Open NBlad opened 2 years ago

NBlad commented 2 years ago

Not sure whether this is too big for a 'weekly' episode(s) but cover introducing static analysis into an existing code base. Especially where there is a large amount of legacy code that cannot be touched. So the scenario might be that I want to leave existing code as is but new code adheres to something like "C++ Core Guidelines".

lefticus commented 2 years ago

I think we could discuss this.

I think it would be best if we had some existing open source project to start from.

NBlad commented 2 years ago

Thanks for considering this.

I am not that knowledgeable on open source projects beyond being a user. I guess we would want something that was not too big and ideally digestible for the majority of users e.g. not too much generic code. Something that is simple but not so simple that it doesn’t cover some of the complexities.

I am willing to help although bear in mind that I have almost wholly been Windows (using Visual Studio) based for some time (Unix in the dim and distant past). I can probably apply WD-40 if needed 😊

I work for a company where a number of teams are converging on adopting C++ Core Guidelines as their coding guidelines and as you probably know there is support for doing this from compiler vendors. I have come across the following scenarios in my company (apologies if this is a bit messy, still struggling trying to frame the problem):

  1. New code – apply coding guidelines – easy no brainer.
  2. Existing legacy code with no coding guidelines and where there is negative value (risk of breakage) in updating the legacy code. See options below for this scenario.
  3. Existing code with an old bespoke coding guideline. We still want to ensure that the legacy code is compliant with the old guidelines. I guess a question here is whether the old rules can be expressed in terms of the new rules which would solve this scenario. I would expect this will not be possible in some cases e.g. new guideline effectively deprecates previous guideline. There is potential cross over here with how we addressed #2 above.
  4. Coding guidelines update – I think this is addressed via snapshotting the guidelines and having known configurations of the coding guidelines enforcement. I guess this is just a variant of #3 above.

Applying new code to existing legacy file options:

  1. Apply new code to legacy file using old guidelines. If number of changes exceed certain threshold then update the whole of the legacy file to be compliant.
  2. Update the legacy file to be compliant with new guidelines. I expect this would not be acceptable in my company although #4 may be an option.
  3. Refactor affected code into separate file that is compliant with new guidelines. Could this become messy (over years could get many files per same logical unit).
  4. Verified automatic code update via tooling i.e. update legacy code automatically. Not sure this will be 100% effective e.g. tooling would not be able to convert pointers to smart pointers as I believe this would require deeper knowledge of usage.

When running static analysis we want individual developers to be able to run the static analysis as part of the development cycle prior to pushing back, and as part of CI. We want to minimise false positives unless we can easily mark them as being suppressed.

Note that for a long lived project there will inevitably be iterations of code developed against several C++ standards.

If this beyond the scope in terms of depth and time of what you might consider then I won’t be upset.

Regards,

Nick

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows

From: Jason @.> Sent: 03 September 2022 19:08 To: @.> Cc: @.>; @.> Subject: Re: [lefticus/cpp_weekly] Introducing static analysis into a C++ code base (Issue #130)

I think we could discuss this.

I think it would be best if we had some existing open source project to start from.

— Reply to this email directly, view it on GitHubhttps://github.com/lefticus/cpp_weekly/issues/130#issuecomment-1236174728, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARH4DOT4XX4S2VI6OQ6EJITV4OH3FANCNFSM57KNAG4A. You are receiving this because you authored the thread.Message ID: @.***>