|
Message Closed
modified 27-Oct-22 17:22pm.
|
|
|
|
|
Wow, that escalated. Maybe you should take your own advice and shouldn't post here.
I'm not the one attacking other commenters for simply disagreeing, insulting their professional skills, and generally being a nuisance.
I had to look at your profile to make sure you weren't a troll on a temporary account.
*I* bring the site down? Again, some self awareness might do you some good.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Message Closed
modified 27-Oct-22 17:21pm.
|
|
|
|
|
You're just in attack mode now. It's not professional. I'm done with you.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Message Closed
modified 27-Oct-22 17:21pm.
|
|
|
|
|
My profile picture is in fact me.
Now find a hobby that doesn't involve me.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Message Closed
modified 27-Oct-22 17:21pm.
|
|
|
|
|
Thanks! The filter is called "webcam, in my living room"
To err is human. Fortune favors the monsters.
|
|
|
|
|
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.
|
|
|
|
|
i agree. using a linter for suggestions is great, being bound to its 'rules' isn't.
code reviews would be better, some type of paired programming would be better. If the code compiles, then a linter may interfere with the writer's intentions. If the code compiles and it wasn't the writer's intention, then having a second eye is better than a linter. AND if someone is writing code that requires linting I would think that person shouldn't be writing code.
I've never been happy with linters; they force you to write code according to someone else's style. If we're just using linters to 'teach' people how to write code then that person probably shouldn't be writing code.
like the quote from Ratatouille cartoon, "Anybody one can cook, but not anyone should cook"
|
|
|
|
|
😶all my software without already has a bunch of warnings about async no await, and none reachable code, why would I want to add to that list
and then c#10 is used, and gives more warnings about shortening and rewriting things to be even more compressed then before
......I think I might fix some of these warnings first then add linter 😞
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Yes, I use a linter in some circumstances, usually just to provide a quick check on my code. I don’t assume I know and write everything correctly, so I’ll employ a tool to give it a ‘once over’ before testing or committing. I don’t always agree with the alerts/suggestions, but it makes me aware so I can make a conscious decision about it.
I also use Jet Brain’s ReSharper when using the Visual Studio IDE, as it does real-time code evaluation (when I don’t agree with a rule, I just modify the configuration)
Whether to use a linter or other code-analysis tool seems more like a personal preference: keep it in your toolbox, know how to use it, and use it when you want.
Time is the differentiation of eternity devised by man to measure the passage of human events.
- Manly P. Hall
Mark
Just another cog in the wheel
|
|
|
|
|
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-format to 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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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!
|
|
|
|
|
Wordle 493 6/6
⬛⬛🟨⬛⬛
⬛⬛⬛🟨⬛
⬛🟩⬛⬛⬛
⬛🟩⬛⬛🟩
⬛🟩⬛⬛🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 493 4/6
⬜⬜⬜⬜⬜
⬜🟩⬜⬜⬜
⬜⬜⬜⬜🟩
🟩🟩🟩🟩🟩
Yay for eliminators!
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Wordle 493 4/6
⬛⬛⬛⬛⬛
⬛⬛🟨⬛⬛
🟩⬛⬛⬛⬛
🟩🟩🟩🟩🟩
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
