|
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
⬛⬛⬛⬛⬛
⬛⬛🟨⬛⬛
🟩⬛⬛⬛⬛
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 493 4/6
⬛⬛⬛⬛⬛
⬛🟩⬛⬛⬛
⬛⬛🟩🟨⬛
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 493 4/6
⬜⬜⬜⬜⬜
⬜🟩⬜⬜⬜
⬜🟩🟩🟩🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 493 4/6
⬜⬜🟨⬜⬜
⬜🟩⬜⬜⬜
🟨🟩⬜⬜🟩
🟩🟩🟩🟩🟩
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Wordle 493 5/6
⬜⬜⬜⬜⬜
⬜🟩⬜⬜⬜
⬜🟩⬜⬜⬜
⬜🟩⬜⬜⬜
🟩🟩🟩🟩🟩
|
|
|
|
|
⬜⬜⬜⬜⬜
⬜⬜🟨⬜⬜
⬜🟩🟨⬜🟩
🟩🟩⬜⬜🟩
🟩🟩🟩🟩🟩
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
Wordle 493 X/6
⬜⬜⬜⬜⬜
⬜⬜⬜⬜⬜
⬜🟩⬜⬜⬜
⬜🟩⬜⬜🟩
⬜🟩⬜🟩🟩
⬜🟩⬜🟩🟩
Didn't make it today 
|
|
|
|
|
Wordle 493 3/6*
🟩🟩⬜⬜⬜
🟩🟩⬜⬜⬜
🟩🟩🟩🟩🟩
Happiness will never come to those who fail to appreciate what they already have. -Anon
|
|
|
|
|
Wordle 493 6/6*
⬜⬜⬜⬜⬜
⬜⬜🟨⬜⬜
⬜🟩⬜⬜🟩
⬜🟩⬜⬜🟩
⬜🟩⬜🟨🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 493 4/6
⬛⬛⬛⬛🟩
⬛🟩⬛⬛🟩
🟨🟩⬛⬛🟩
🟩🟩🟩🟩🟩
Get me coffee and no one gets hurt!
|
|
|
|
|
Wordle 493 X/6
⬜⬜⬜⬜🟩
⬜🟩⬜⬜🟩
⬜🟩⬜⬜🟩
⬜🟩⬜⬜🟩
⬜🟩⬜⬜🟩
⬜🟩🟩🟩🟩
ends my streak at 24
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Yesterday, for some reason I backed up all my user data on my Ubuntu 22.04.1 LTS installation --- my main desktop that I use for daily work.
Today, there was a Kernel update that I installed & ruined my installation.
I have 2 screens running on a NVidia 1660 video card but after the kernel update the drivers wouldn't be recognized. So my screen was at 1024x768  and only 1 screen even worked. Crazy!
I even booted off a USB stick with an only slightly older version of Ubuntu (without those kernel updates) and it all worked fine running from the stick!!!
I wrote it up (to no avail) at AskUbuntu[^].
I wasted over 3 hours trying to get the drivers to work with the new kernel and/or attempting to back up to previous kernel.
Finally I did a complete reinstall of Ubuntu and restored my data. About 1 hour later I was all back working again. Can't really believe I was able to do that so fast.
This kind of catastrophic failure shouldn't happen...but it does.
|
|
|
|
|
Yeah, sadly (even in 2022) Ubuntu specifically (Linux generally) has problems with proprietary video drivers. It reminds me of Windows pre-2005. I blame the use of a monolithic kernel... 
|
|
|
|
|
I have had good luck with the Nouveau drivers, if I do install from Nvidia, I stay one level back. But, I only have one monitor (34"). It has been like forever since I had non-self-inflicted problems. I stay with either Debian or LMDE (Mint based on Debian, not Ubuntu). Ubuntu is based on Debian but your pals at Canonical and Microsoft add the salt and pepper.
>64
Some days the dragon wins. Suck it up.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
