Linter?
-
I use plpgsql_check which is a linter for PostgreSQL. It's been amazingly helpful in reviewing code for mistakes and other warnings (like applying a conversion to an indexed column, as opposed to the other variable! The former (it tells you) will prevent the index from being used!) NICE! Of course, working with converted code... I was not thrilled with the first 35,000 errors, warnings and hints! LOL But after clearing them, I feel MUCH better about the converted code!
Careful now, honey the codewitch is on here trolling if you mention anything besides C/C++.
Jeremy Falcon
-
Thanks! The filter is called "webcam, in my living room"
To err is human. Fortune favors the monsters.
:laugh: Must be a combination of the resolution and lighting then. Made it almost look like a painting from a quick glance on a small screen. At least we can agree it's an interesting effect.
Jeremy Falcon
-
jschell wrote:
Static analysis tools do not provide any value in modern programming. When they were first invented compilers had almost zero effective error reporting so using a second tool with pattern matching to find those before compilation seemed like a good idea.
Strongly disagree. I've learned a ton about the quirks of a language, etc. just by using them. Here's an example in JavaScript, always explicitly setting the radix for
parseInt. A static analyzer will tell you why you should do that.Jeremy Falcon
Jeremy Falcon wrote:
I've learned a ton about the quirks of a language, etc. just by using them.
Myself learn languages by using the language. I believe that in a professional environment junior programmers might be helped by this. But they would be helped far more with mentoring and code reviews. And throwing junior developers at a project without mentoring is a failure of management. As a senior developer working on a project requiring passing static analysis is nothing but annoying. I have seen it lead to logic errors when someone just accepted the analysis and then attempted to work around it producing code that the analyzer passed but which actually introduced runtime and logic errors into the application.
-
You are not polite.
Jeremy Falcon
-
in my opinion, it's one of the greatest ideas. in the spirit of non-standardized C, from the original K&R book: "For those situations where strong type checking is desirable, a separate version of the compiler is used. This program is called lint, apparently because it picks bits of fluff from one's programs. lint does not generate code, but instead applies a very strict check to as many aspects of a program as can be verified at compile and load time. It detects type mismatches, inconsistent argument usage, used or apparently uninitialized variables, potential portability issues, and the like." this is the ultimate separation of concern. you can have original C type checking: "Existing compilers provide no run-time checking of array subscripts, argument types, etc." or you can have strong type checking (as strong as it gets), but it's up to you. more in a hippie manner, than in a ____ wing political manner, telling you what is good (therefore allowed) and what is evil (therefore forbidden). cheers
Martin ISDN wrote:
in the spirit of non-standardized C, from the original K&R book:
Err...except of course that when C was created.... Compilers were not doing strong error detection. The C compiler specifically did not do a lot of that. And of course lint originated in use with C itself. And from Bell labs itself where C was also invented. So as I said it was to correct for the abilities lacking in that compiler.
-
We use linters&static code analysis for C++, Go and Python. I love them all. For all three they increase readability. For C++ they even catch potential bugs, such as memory leaks. For C++ we also have
clang-formatto remove hand editing."If we don't change direction, we'll end up where we're going"
megaadam wrote:
For all three they increase readability.
Doubt it. Given that people often toss that term around to rationalize some specific way of writing code in a way that they prefer I once looked for any study anywhere that demonstrated anything could be made more "readable". I found one single study which was based on marketing materials and it was related to the fonts (font faces) that one should use. I believe the conclusion was no more than four.
megaadam wrote:
For C++ they even catch potential bugs, such as memory leaks.
Some very specific limited and likely easily identified problems. Run time analysis (not static analysis) tools can be used to track down the ones with the most impact. And it is better to be diligent about using pointers at all when writing code in the first place.
-
Jeremy Falcon wrote:
I've learned a ton about the quirks of a language, etc. just by using them.
Myself learn languages by using the language. I believe that in a professional environment junior programmers might be helped by this. But they would be helped far more with mentoring and code reviews. And throwing junior developers at a project without mentoring is a failure of management. As a senior developer working on a project requiring passing static analysis is nothing but annoying. I have seen it lead to logic errors when someone just accepted the analysis and then attempted to work around it producing code that the analyzer passed but which actually introduced runtime and logic errors into the application.
That's just nonsense. Let's not play the senior card. Even if you honestly believe you know everything on the planet that a linter can provide zero value, they do help automate out the tedious and help with gated check-ins, etc. In my vast, vast, vast experience every time I hear a developer pretend to know everything... they usually don't.
Jeremy Falcon
-
Jeremy Falcon wrote:
I've learned a ton about the quirks of a language, etc. just by using them.
Myself learn languages by using the language. I believe that in a professional environment junior programmers might be helped by this. But they would be helped far more with mentoring and code reviews. And throwing junior developers at a project without mentoring is a failure of management. As a senior developer working on a project requiring passing static analysis is nothing but annoying. I have seen it lead to logic errors when someone just accepted the analysis and then attempted to work around it producing code that the analyzer passed but which actually introduced runtime and logic errors into the application.
Also, you've been around here long enough to know I'm not new to this game at all man. What gives?
Jeremy Falcon
-
Considering your reply was condescending too, I do not value your opinion at all. This is the part where you deny it, while showing those of us who do get... that you just don't get it.
Jeremy Falcon
-
megaadam wrote:
For all three they increase readability.
Doubt it. Given that people often toss that term around to rationalize some specific way of writing code in a way that they prefer I once looked for any study anywhere that demonstrated anything could be made more "readable". I found one single study which was based on marketing materials and it was related to the fonts (font faces) that one should use. I believe the conclusion was no more than four.
megaadam wrote:
For C++ they even catch potential bugs, such as memory leaks.
Some very specific limited and likely easily identified problems. Run time analysis (not static analysis) tools can be used to track down the ones with the most impact. And it is better to be diligent about using pointers at all when writing code in the first place.
You seem to be rather determined to misunderstand the arguments brought forward, but please allow me to try again. Take e.g. the two styles
A/B:Door* HouseManager::getDoor(Key* key)
{
// ...Door *HouseManager::get_door(key *key) {
// ...I happen to prefer one, but: the point of a linter is not that one style is superior. The point is: to avoid an elephanting mess of mixed styles
A&B(&C,D,E ...)Because dealing with such a mess in a large code-base is rather painful on the eyes. I am talking out of 30+ years of experience and not based one some trendy blog-post."If we don't change direction, we'll end up where we're going"
-
The thread is there for everyone to see. I'm satisfied with my estimation of this exchange. You were the one attacking other people here. Not me.
To err is human. Fortune favors the monsters.
-
You seem to be rather determined to misunderstand the arguments brought forward, but please allow me to try again. Take e.g. the two styles
A/B:Door* HouseManager::getDoor(Key* key)
{
// ...Door *HouseManager::get_door(key *key) {
// ...I happen to prefer one, but: the point of a linter is not that one style is superior. The point is: to avoid an elephanting mess of mixed styles
A&B(&C,D,E ...)Because dealing with such a mess in a large code-base is rather painful on the eyes. I am talking out of 30+ years of experience and not based one some trendy blog-post."If we don't change direction, we'll end up where we're going"
Just curious, what IS your preference on pointers? And why? I like Type* varName; My brain digests pointers better as a meta type. A variable is always just a variable. A variable must have a type. You can manipulate the type via address operator and dereference operator.
-
@Honey I am imagining a sock puppet on each of your hands flaming each other during this exchange.
Yeah I really didn't want it to get to that point.
To err is human. Fortune favors the monsters.
-
@Honey I am imagining a sock puppet on each of your hands flaming each other during this exchange.
Oh, I see what happened. The other commenter seems to have deleted their account or all their posts - not sure which. It makes the whole thing weird.
To err is human. Fortune favors the monsters.
-
Martin ISDN wrote:
in the spirit of non-standardized C, from the original K&R book:
Err...except of course that when C was created.... Compilers were not doing strong error detection. The C compiler specifically did not do a lot of that. And of course lint originated in use with C itself. And from Bell labs itself where C was also invented. So as I said it was to correct for the abilities lacking in that compiler.
jschell wrote: Err...except of course that when C was created.... Compilers were not doing strong error detection. have you tried PL/I, Algol68 or Pascal? now, that is strong error detection. each of those languages predates C. forcing strict rules doesn't depend on the year of creation of the language, but on the nature of it's creators. Dennis MacAlistair Ritchie (et al) did not create C to defeat the evils of the world, nor to purge the wicked. what he did has it's place on the list of things that helped humanity. and help he did... "C is a general-purpose language that features economy of expression" "But it's absence of restrictions make it more convenient and effective for many tasks than supposedly more powerful languages" 1978 Brian W. Kernighan Dennis M. Ritchie ps - "where strong type checking is desirable, a separate version of the compiler is used. This program is called lint" it's up to you, how you make use of it
-
You seem to be rather determined to misunderstand the arguments brought forward, but please allow me to try again. Take e.g. the two styles
A/B:Door* HouseManager::getDoor(Key* key)
{
// ...Door *HouseManager::get_door(key *key) {
// ...I happen to prefer one, but: the point of a linter is not that one style is superior. The point is: to avoid an elephanting mess of mixed styles
A&B(&C,D,E ...)Because dealing with such a mess in a large code-base is rather painful on the eyes. I am talking out of 30+ years of experience and not based one some trendy blog-post."If we don't change direction, we'll end up where we're going"
megaadam wrote:
I happen to prefer one, but: the point of a linter is not that one style is superior
You introduced the subjective word "readablity" not me.
megaadam wrote:
Because dealing with such a mess in a large code-base is rather painful on the eyes.
Subjective for several reasons. The real problems with large code bases (hundreds of thousands or even millions of lines of code) are many. Being able to read the code doesn't even show up on the list.
megaadam wrote:
I am talking out of 30+ years of experience and not based one some trendy blog-post.
And I am talking about 40+ years. I started with C Lint. I have also been a principal reviewer for more than 20 years along with 15 years as a principal process control participant. I have worked on completely new code bases and code bases more than 20 years old. And I spent about 15 years reading every actual study I could find which attempted to actually measure (objective measurements) ways which lead to actual code improvement. Again pretty code was never in those lists.
-
jschell wrote: Err...except of course that when C was created.... Compilers were not doing strong error detection. have you tried PL/I, Algol68 or Pascal? now, that is strong error detection. each of those languages predates C. forcing strict rules doesn't depend on the year of creation of the language, but on the nature of it's creators. Dennis MacAlistair Ritchie (et al) did not create C to defeat the evils of the world, nor to purge the wicked. what he did has it's place on the list of things that helped humanity. and help he did... "C is a general-purpose language that features economy of expression" "But it's absence of restrictions make it more convenient and effective for many tasks than supposedly more powerful languages" 1978 Brian W. Kernighan Dennis M. Ritchie ps - "where strong type checking is desirable, a separate version of the compiler is used. This program is called lint" it's up to you, how you make use of it
Martin ISDN wrote:
have you tried PL/I, Algol68 or Pascal? now, that is strong error detection. each of those languages predates C
Perhaps you are confusing the semantics of the language and how the compiler found and reported on errors which it found during the compilation process. Finding and reporting on errors consumes most of the work and code in a compiler. These days I suspect a lot of compiler code goes into optimizations. But nothing did that back then. But other than that... C was the follow on to B. And it was developed in 1971 Pascal was from 1970 PL/I was in 1966 Not surprisingly Algol 68 was in 1968 So they are contemporaries.
Martin ISDN wrote:
Dennis MacAlistair Ritchie (et al) did not create C to defeat the evils of the world, nor to purge the wicked.
I didn't claim that he did.
Martin ISDN wrote:
"where strong type checking is desirable, a separate version of the compiler is used. This program is called lint"
And I am rather certain that compilers now do almost if not all of the same checks that the early lint did. And apparently others agree with that assertion. "Even though modern compilers have evolved to include many of lint's historical functions" Lint (software) - Wikipedia[^] I believe I remember using C lint which detected unbalanced parens. The C compiler would just fall over and report nothing useful when that happened.