The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I was also disappointed with it. It did find a few things, but I had to disable various errors and warnings just to find them amongst all its drool. It was a while ago that I used it, but I seem to recall that it was obsessed with using smart pointers and tagging functions noexcept. I think it's a plug-in that Microsoft took from a third party. In any case, I'd already written one[^], though it only understands the subset of C++ that I use.
And, even worse, if you are writing a large, multi-platform system, where different compilers/tools are going to be used, and they will all have their own error/warning codes, it will just be a mess. Creating a macro to hide the suppression mechanism won't help with the error codes.
I guess you could say that only one platform will get code analysis but that doesn't seen practical.
multi-platform system, where different compilers/tools are going to be used
That's exactly the situation I'm in (building for Linux with gcc, Windows with MSVC 2017 - and thanks to WSL, I can do them both from the same session - yay for progress!). I'm using clang-tidy for static analysis and finding it pretty painless. I have it set to run every time I build for Linux build, with only warnings I'm interested in and it's OK. Combined with gcc sanitisers (turned on for debug builds and unit tests), I feel happier that my code's safer than it might otherwise be.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Well yes, but also no.
I'm now doing a VB.NET WinForms project.
I get naming conventions and that we should be using PascalCasing for methods.
But controls are still often named "btnSave" or "txtName", and the VS default for events is btnSave_Click.
ERROR! btnSave_Click is not according to conventions (then again, nothing in this project is).
Even if I named it SaveButton, VS still generates the _ and I'm not going to change that kind of generated code.
The original developer didn't care one bit about conventions and had code as follows (comments added here by me):
Dim SomeVar ' This is possible as Options Strict is Off, making it late bound/loosely typedDim _anothervar As Entities
Private yetanothervar AsInt32 = "0"' Again, option Strict is OffDim theListGoesOn AsInteger
I don't know how many rules this breaks and the lack of consistency is alarming (and I wish I was overdoing it here, but I don't).
The code analyzer did help me to clean things up though.
Another thing the analyzer doesn't get is that a shown form should NOT be disposed!
Doing so will immediately close the form, learned that the hard way some years back
So while I was able to resolve literally 100's of possible bugs and inconsistencies it also leaves me with 100's that I cannot or will not fix!
It's a double edged blade
I just did an analysis on a piece of WPF code I wrote recently (which runs fine, BTW), and it found two variables that weren't used (which I had already pragama'd around, and seven instances of CA2214 (Do not call overridable methods in constructors), which involved having forms derived from a base form class that implemented INotifyPropertyChanged. I'm not changing my code...
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
I have a big codebase and think CA helps a lot! If you don't like the default rules set - make your own or customize it. I normally would go for local supressions directly on the code in Question - but for your case a global supression could do (or in Project-Settings). I think it's not OK to say the CA "sucks" - if you have special needs customize it - you can, and it's not difficult.
If you are coding in C++, perhaps you should really examine you code, for example, using assert -- you might want to use the Google Test Framework and use their ASSERT_ macros along with gMock so you don't have to pollute your code with something that is normally reserved for debugging and not for a release version. I am wondering if you are a "C-style" developer, which might be causing some of your angst.
Ummm... No. I've been a hard core C++ developer for 30+ years and have a 1.1M line personal code base. So it's safe to say I'm not a C style developer. I have my own test framework and my own asserts my own standard library and my own everything, so none of that would be applicable to me. My asserts are appropriately used for things that would represent coding errors, not input errors (obviously no one is 100% consistent in such a large code base.) And of course I can choose to have them on in release if I want, or have separate ones for release vs. debug.
I never use any form of code analysis tool, though I have tried a few in the past. Such tools, as you pointed out, merely throw up a voluminous amount of errors and warnings, most of which are meaningless. And I have never found such an issue that I would rewrite my code in such a fashion.
I have been coding for nearly 5 decades and if by that time you have not developed a clean, efficient style of development, you are not going to. And a code analysis tool will not help you much.
What code analysis tools find are those issues applied against the set of paradigms a the vendor of a particular tool want you to follow. Such paradigms are neither correct or incorrect. If you want to follow them that is perfectly fine.
However, most developers do their work from a very personal standpoint and take pride in their work from such a position. As a result, such development will often find the issues that you found with Visual Studio's Code Analyzer tool.
And again, mist such issues are meaningless.
There are some exceptions to this however where such tools demonstrate the more efficient method of developing your logic. However, a lot of this is all relative. For example, I still use ArrayLists quite heavily in my code. Why would I do this when it is already known that List<t> collections are more efficient as the following description from StackOverflow demonstrates?
> Yes, pretty much. List<t> is a generic class. It supports storing values of a specific type without casting to or from object (which would have incurred boxing/unboxing overhead when T is a value type in the ArrayList case). ArrayList simply stores object references. As a generic collection, List<t> implements the generic IEnumerable<t> interface and can be used easily in LINQ (without requiring any Cast or OfType call).
ArrayList belongs to the days that C# didn't have generics. It's deprecated in favor of List<t>. You shouldn't use ArrayList in new code that targets .NET >= 2.0 unless you have to interface with an old API that uses it.
Because whether you use an ArrayList or a List<t> is one, a personal preference, and two only efficient in the amount of data being processed. So for example, if I use an ArrayList to process 50 stored structures in a for-each loop, do you really think that by using a List<t> collection it will make such a process more efficient to the end user? Highly unlikely, since all such processes are done in milliseconds and people who insist that others follow the List<t> protocol when there is no need to are merely wasting everyone's time.
Of course, if you plan to process several thousand objects in such a loop than the use of the List<t> collection makes a
lot more sense.
But for me, the amount of data I process in an ArrayList is just as efficient as if I had used a List<t> collection type.
And finally, all of my code can be read and understood by a person less experienced than I than if I had coded it with modern or current standards that have added levels of such obscurity as to make most such such code rather arcane in my view.
Given this, then using a code analyzer serves its purpose if you are intent on developing using current paradigm approaches to your development. And in most such tools, you can turn off a lot of the rules they go by. However, this can be a lot of work and almost to the point of not making it worth the effort. And trying to enter the rules listing in Visual Studio 2019 to review the number of settings that should be able to modified appears to keep crashing the IDE.
Sr. Software Engineer
Black Falcon Software, Inc.
So I went back and figured I'd give it another try, just to be fair. I did ultimately find a legitimate though unlikely issue. But, I introduced a bad bug in the process of trying to get rid of warnings, and spent a couple hours trying to figure that out.
A lot of the raft of issues it was whining about were just the same ones over and over, because they were in templates and it would spit them out for each use of the offending bit of code. So it was somewhat easier to get rid of them than I thought initially. Though, it's annoying that you don't see the errors until someone uses the code, since it means constantly going back and having to tweak fundamental headers that cause big rebuilds. I have all of these collections set up to pre-instantiate and export for some common element types, but that doesn't seem to enough to make it complain.
So it's a bit of a tedious and time consuming process to deal with all of the warning i n those fundamental collection template classes.
Anything that is unrelated to elephants is irrelephant Anonymous - The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944 - Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
Yep, a picture of person who can complete a sentence. Oi! these puns have felon hard times.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle