How to make thing more complicated for nothing...
-
in the same header file, 5 lines apart.
#define szSTATUS_DONE "D"
#define cSTATUS_DONE 'D'they represent the same status (and values) (yeah, we use type prefix !! :-( )
CI/CD = Continuous Impediment/Continuous Despair
Maximilien wrote:
they represent the same status (and values)
They may represent the same status but they certainly don't represent the same values. One is a string while the other is a character. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Maximilien wrote:
they represent the same status (and values)
They may represent the same status but they certainly don't represent the same values. One is a string while the other is a character. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
obviously. :-\
CI/CD = Continuous Impediment/Continuous Despair
-
in the same header file, 5 lines apart.
#define szSTATUS_DONE "D"
#define cSTATUS_DONE 'D'they represent the same status (and values) (yeah, we use type prefix !! :-( )
CI/CD = Continuous Impediment/Continuous Despair
-
I had to work on a code base with a static code checker enforcement. And if you used a 'constant' more than twice it would flag it. Static code checkers are absolutely worthless.
jschell wrote:
Static code checkers are absolutely worthless.
You must have encountered an (or several) really bad code checkers. Some of them are really good. On the other hand: The good ones are far from cheap. You get what you pay for. Also, all the ones I have been in touch with, from the very top down to simple lint, has provided mechanisms for suppressing reports on each specific 'defect'. I see no viable justification for treating >2 uses of constant as a defect, so I would disable that test immediately.
Religious freedom is the freedom to say that two plus two make five.
-
Trust me, it's much worse when you go through your own's and go: "What was I thinking!" :laugh:
Mircea
thanks for your information
-
jschell wrote:
Static code checkers are absolutely worthless.
You must have encountered an (or several) really bad code checkers. Some of them are really good. On the other hand: The good ones are far from cheap. You get what you pay for. Also, all the ones I have been in touch with, from the very top down to simple lint, has provided mechanisms for suppressing reports on each specific 'defect'. I see no viable justification for treating >2 uses of constant as a defect, so I would disable that test immediately.
Religious freedom is the freedom to say that two plus two make five.
trønderen wrote:
Some of them are really good
None of them can be that good by their very nature. They can only look for simple problems. And that is only appropriate with a lot of junior programmers and with little, poor or non-existent code reviews. Often the problems are stylistic in nature as well. Complex real bugs originate from execution flow which static code checkers cannot detect at all.
trønderen wrote:
mechanisms for suppressing reports on each specific 'defect'.
However they are put in place in the context of process. So people fixate on the process and will not allow that. As I have encountered multiple times. They fixate on the idea that it is 'better' without understanding what is going on.
trønderen wrote:
down to simple lint,
I worked at hard core linux/unix C and C++ shops along with reading tech journals for years. And far as I recall no one ever considered lint to be a good idea.
trønderen wrote:
You get what you pay for.
It was a paid product.
-
trønderen wrote:
Some of them are really good
None of them can be that good by their very nature. They can only look for simple problems. And that is only appropriate with a lot of junior programmers and with little, poor or non-existent code reviews. Often the problems are stylistic in nature as well. Complex real bugs originate from execution flow which static code checkers cannot detect at all.
trønderen wrote:
mechanisms for suppressing reports on each specific 'defect'.
However they are put in place in the context of process. So people fixate on the process and will not allow that. As I have encountered multiple times. They fixate on the idea that it is 'better' without understanding what is going on.
trønderen wrote:
down to simple lint,
I worked at hard core linux/unix C and C++ shops along with reading tech journals for years. And far as I recall no one ever considered lint to be a good idea.
trønderen wrote:
You get what you pay for.
It was a paid product.
To me, it seems obvious that you never have been in touch with a high quality static code analyzer. It also sounds like you most likely would turn down an offer to try a good one, because you know in advance that no good analyzers can exist. So it is a waste of time. You are in your full right to think so. I am in my full right to disagree with you.
-
trønderen wrote:
Some of them are really good
None of them can be that good by their very nature. They can only look for simple problems. And that is only appropriate with a lot of junior programmers and with little, poor or non-existent code reviews. Often the problems are stylistic in nature as well. Complex real bugs originate from execution flow which static code checkers cannot detect at all.
trønderen wrote:
mechanisms for suppressing reports on each specific 'defect'.
However they are put in place in the context of process. So people fixate on the process and will not allow that. As I have encountered multiple times. They fixate on the idea that it is 'better' without understanding what is going on.
trønderen wrote:
down to simple lint,
I worked at hard core linux/unix C and C++ shops along with reading tech journals for years. And far as I recall no one ever considered lint to be a good idea.
trønderen wrote:
You get what you pay for.
It was a paid product.
jschell wrote:
None of them can be that good by their very nature. They can only look for simple problems.
It seems quite obvious to me that you have never been introduced to a high quality static analyzer. It seems to me that if you were offered an opportunity to try out an advanced code analyzer you might reject it as a waste of time, because you know in advance that such animals do not exist. You are in your full right to think so. And I am in my full right to disagree with you.
Religious freedom is the freedom to say that two plus two make five.
-
trønderen wrote:
Some of them are really good
None of them can be that good by their very nature. They can only look for simple problems. And that is only appropriate with a lot of junior programmers and with little, poor or non-existent code reviews. Often the problems are stylistic in nature as well. Complex real bugs originate from execution flow which static code checkers cannot detect at all.
trønderen wrote:
mechanisms for suppressing reports on each specific 'defect'.
However they are put in place in the context of process. So people fixate on the process and will not allow that. As I have encountered multiple times. They fixate on the idea that it is 'better' without understanding what is going on.
trønderen wrote:
down to simple lint,
I worked at hard core linux/unix C and C++ shops along with reading tech journals for years. And far as I recall no one ever considered lint to be a good idea.
trønderen wrote:
You get what you pay for.
It was a paid product.
jschell wrote:
Often the problems are stylistic in nature as well.
It must be possible to disable a lot of the warnings about "code smells" based on things like the C++ Core Guidelines and MISRA. Some of these act as if everyone started development inh C++20, exaggerate their importance, and lead to so many warnings as to make the tool useless. As you say, it gets out of hand if people focus on process--the metrics that these tools spit out--without assessing whether the code really needs to change.
jschell wrote:
Complex real bugs originate from execution flow which static code checkers cannot detect at all.
Coverity and Sonarcloud both highlight execution flows that could lead to the use of a null pointer. For example, they'll tell you that if the following 6 branches are taken, you could end up using an invalid pointer. In some cases, they even detect it across a chain of function calls. Perhaps you don't call this static analysis, because it actually analyzes execution flows, but both of these are classified as static analysis tools. Some warnings can be false positives for reasons that the tool can't understand, but they're worth investigating.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
jschell wrote:
None of them can be that good by their very nature. They can only look for simple problems.
It seems quite obvious to me that you have never been introduced to a high quality static analyzer. It seems to me that if you were offered an opportunity to try out an advanced code analyzer you might reject it as a waste of time, because you know in advance that such animals do not exist. You are in your full right to think so. And I am in my full right to disagree with you.
Religious freedom is the freedom to say that two plus two make five.
trønderen wrote:
that you have never been introduced to a high quality static analyzer.
Perhaps. You can suggest one if you wish. I have however, as a principle programmer, been tasked with fixing many bugs which have shown up in production and none of which a static analyzer could have detected.
-
jschell wrote:
Often the problems are stylistic in nature as well.
It must be possible to disable a lot of the warnings about "code smells" based on things like the C++ Core Guidelines and MISRA. Some of these act as if everyone started development inh C++20, exaggerate their importance, and lead to so many warnings as to make the tool useless. As you say, it gets out of hand if people focus on process--the metrics that these tools spit out--without assessing whether the code really needs to change.
jschell wrote:
Complex real bugs originate from execution flow which static code checkers cannot detect at all.
Coverity and Sonarcloud both highlight execution flows that could lead to the use of a null pointer. For example, they'll tell you that if the following 6 branches are taken, you could end up using an invalid pointer. In some cases, they even detect it across a chain of function calls. Perhaps you don't call this static analysis, because it actually analyzes execution flows, but both of these are classified as static analysis tools. Some warnings can be false positives for reasons that the tool can't understand, but they're worth investigating.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Trust me, it's much worse when you go through your own's and go: "What was I thinking!" :laugh:
Mircea
Things get complicated when we are not able to understand them clearly. The other possible reason can be Overthinking, which exaggerates a simple situation and makes it appear worse. A person ends up imagining certain situations which in reality won't happen.
