"oh, the line you are typing is incomplete and therefore the whole file is invalid which means there is nothing to suggest for autocomplete"
Ah, a fellow SSMS user
Reminds me of VB6.
Compiler: you're skating on thin ice there you fucking maverick
Hot doggin and grab assin. Not in my house.
Fuckit, red squiggly.
Meanwhile rust when you try to use a variable before saving.
I DECLARE... VARIABLE!
Oh no you have to say it out loud EVERY time ?
I didn't just say it, I declared it!
...and then there's Go who just won't let you compile at all
Just enable format-on-save. That way gofmt can helpfully delete that variable you just added that you were for sure never going to use. You're welcome!
My thing is imports. Like, why, why do you delete it right after I typed it in and saved?
Even better, it aggressively deletes your variables and imports every time you save. It trains me against every instinct I have working on a computer.
It's a no win situation, because it'll throw a fit if you try to use it before you declare it too.
writing code normally
ocaml-lsp: syntax error
ocaml-lsp: syntax error
ocaml-lsp: syntax error
ocaml-lsp: syntax error
ocaml-lsp: okay, probably okay
ocaml-lsp: syntax error
ocaml-lsp: syntax error
ocaml-lsp: wait, the entire function is wrong
me: WHAT, where
ocaml-lsp: like the entire thing, 20 lines of it,
a -> (b -> c -> d) -> [200 other types] ->gdoesn't match
a -> (b -> c/2 -> d) -> [200 other types] ->g,
cdoesn't matchc/2.I don’t understand?
Notepad likes my html, and filezilla doesn’t complain when I upload it to production. It even passes validation for 4.01 transitional
Sometimes I think it could be easier to just use the variable before its declared and then let the IDE auto fix create it, but I never remember to try it 😂
I turn off LSPs during my train of thoughts. I don't want all red and yellow underline bullshit to disrupt my thoughts. Like, calm the fuck down. I WILL write the correct code eventually; just give me some fucking time.
Well, I use Neovim, so turning off the LSPs or restarting them is sufficiently simple.
When I work on a new project, or on a new feature, I temporarily turn off the LSP, and rely on the compiler to figure out where the code errors. Plain white text gives me the freedom to write whatever the fuck I want without any disruption. Of course, I eventually turn on the LSP again to fix the little issues.
Many languages allow type hole like
_to indicate to the compiler/lsp that this is an expression you will fill in later.So that lsp don't put a squiggle on the entire program, only the type hole
I also leave out little syntax errors and only only focus on the rough idea during my train of thoughts. And the variables, aren't really supposed to be implied as private or unused -- I do eventually meaningfully use them. If I have to prefix all my variables with a underscore to avoid the LSP, I might instead just disable the LSP. When I eventually turn the LSP back on, it tells me the actually unused variables and imports that I can now get rid of.
Because of the LSP, I used to write maybe three hundred lines of code per hour, but now I probably average at least five hundred or more.
#![allow(warnings)]
:)
On the other hand, when my IDE doesn't tell me:
Build Server: "BUILD FAILED! SonarQube says that Roslyn says that you're not using one of your variables!"
Yea okay calm down, and why are you snitching now, Roslyn? Should have told me directly 🙃
What is this? I've never seen it before! Where are you using it?
Just type faster than the LSP needs to check. I don't see an issue.
What IDE is this?
I've seen it with multiple IDE's
In godot engine you can put an underscore at the beginning of a variable to tell the linter to calm the hell down about it. But I don't see why it's such a crisis in the first place.
The underscore is actually used to indicate the variable will not be used.
I agree, if talking about the warning. If talking about the unused var, Go won me over there. Unused vars are absolutely a class of software bug that can have implications in security, resource usage, and maintainability.
