Linter?
-
I treated you how you treated me. Enough of your garbage kid.
Jeremy Falcon
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're just in attack mode now. It's not professional. I'm done with you.
To err is human. Fortune favors the monsters.
No, I'm treating you like you treat me. You just don't like it. Btw, I noticed your profile too and to not surprise you don't even have a real profile picture. Guess you haven't reached that level of maturity and think you're special because of the articles. Guess what... you're wrong. Deal with it.
Jeremy Falcon
-
No, I'm treating you like you treat me. You just don't like it. Btw, I noticed your profile too and to not surprise you don't even have a real profile picture. Guess you haven't reached that level of maturity and think you're special because of the articles. Guess what... you're wrong. Deal with it.
Jeremy Falcon
My profile picture is in fact me. Now find a hobby that doesn't involve me.
To err is human. Fortune favors the monsters.
-
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.
I was polite. That's how it works right? You can argue but say you're polite and then magically you're polite... right? That's your logic, never admit wrongdoing and just double down on arguing. Then just blame the other. So, I was polite. Don't get mad at me for doing what you did. This is the part where you do deny being upset. May as well add one more lie to the conversation.
Jeremy Falcon
-
My profile picture is in fact me. Now find a hobby that doesn't involve me.
To err is human. Fortune favors the monsters.
Well, then that's a cool filter. Props for at least doing that.
Jeremy Falcon
-
Well, then that's a cool filter. Props for at least doing that.
Jeremy Falcon
Thanks! The filter is called "webcam, in my living room"
To err is human. Fortune favors the monsters.
-
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.