Today’s stupid question: are vim and neovim not the same thing? I just type vi (ancient habit) and use whatever it is that executes. (I can go search but interacting here is more fun lol)
Yeah, it doesn’t make a lot of sense. People talk about “when Linus dies”, and obviously that will be devastating, but in my mind Bram just was. I wish I’d made a point of meeting him, or at least sending him an email to say thanks. Not for vim specifically, though I will probably use it until my fingers quit working. As with countess others, Bram inspired me to learn about ICCF Holland, and from there I had the privilege of supporting a child in Uganda through school. That’s what I’d want to thank him for. And vim.
Neovim is a fork of Vim. It uses Lua for configuration instead of the original Vim’s VimScript, but still has a lot of interoperability with original Vim plugins and configuration options.
Neovim is better in many ways, and because it has lua support, it’s so much easier to write plugins for it. So there are thousands of plugins right now, and entire neovim distributions that are configured to work like an IDE, like Lazyvim for example.
I’m a huge fan and I have written plugins myself since it’s easy and rewarding.
But on the server, I don’t bother installing neovim. Ordinary vim is fine for simple editing tasks. But if you want a customized experience to replace VS Code on your computer, you want neovim and not vim.
If you have a common folder that you clone projects to (like OP’s ~/coding), then that checkbox lets you trust that whole folder easily when this pop up comes up.
I have a coding folder “repos”. It’s on a remote machine though and I get this every time I connect to my code folder using a new remote host. So annoying!
Love it , wouldnt work where i live , no flat roads. , Would be a new extreme sport going downhill though :) but I think I am gonna go for the one in the comments perhaps hackaday.io/…/180836-desk-ercising-with-the-exer-…
I started coding with TurboBasic. My favorite thing about TB was that you could have variable names of any length but the compiler only used the first two letters - and case insensitive at that. So “Douchebag” and “doorknocker” looked like different variables but were actually the same thing.
The point would be to be outside. Were traveling right now and I can’t find the link but if you search for wolphrams life hacks type of thing there’s an article he wrote about it which was a fascinating read.
Personally I have an elliptical at home with a laptop stand on it and I love it.
I don’t care how much you think your code is readable, plain text comments are readable by everyone no matter the proficiency in the programming language used. That alone can make a huge difference when you’re just trying to understand how someone handled a situation.
There’s nothing keeping the comments up to date with the code. Comments should be sparse and only on sections that aren’t obvious why they’re being done
There’s nothing limiting what a comment should be as far as I know.
As an example of what I mean, I’ve seen in a 10k+ lines python code a few lines of bit manipulation. There was a comment explaining what those lines did and why. They didn’t expect everyone to be proficient in bit manipulation but it made it so that anyone could understand anyway.
Then someone needs to change something about the code and doesn’t bother updating the comment. Now you still have uncommented code but with a comment that confuses instead of helping.
IMHO the issue in this situation is not the comment but that the person updating the code didn’t do his job properly which shouldn’t be an excuse not to do it from the start.
This is the kind of pointless comment I see in my codebase all the time. Best I can tell, a couple of my coworkers like to plan out their code using comments, then backfill in the actual executable code. That’s fine, but they leave the comments in when they add no value.
` public static LocalDate parseEndDateFromString(String dateString) {
<span style="color:#323232;"> try {
</span><span style="color:#323232;">
</span><span style="color:#323232;"> String[] split = dateString.split("-");
</span><span style="color:#323232;">
</span><span style="color:#323232;"> //In order to get the last day of the desired month, we go to the first day of the next month, account for rollover, then subtract one day
</span><span style="color:#323232;">
</span><span style="color:#323232;"> int month = Integer.parseInt(split[0]) == 12 ? 1 : Integer.parseInt(split[0]) + 1;
</span><span style="color:#323232;">
</span><span style="color:#323232;"> return LocalDate.of(Integer.parseInt(split[1]), month, 1).minusDays(1);
</span><span style="color:#323232;">
</span><span style="color:#323232;"> } catch (Exception e) {
</span><span style="color:#323232;">
</span><span style="color:#323232;"> throw new RuntimeException("Invalid date format - must be MM-YYYY");
</span><span style="color:#323232;">
</span><span style="color:#323232;"> }
</span><span style="color:#323232;">
</span><span style="color:#323232;">}`
</span>
Stuff like this, otoh, is where comments are useful. The required format is obvious from the error message, the param and return from the method signature, the only part that requires a comment is the fiddly logic of accounting for the edge case where month == 12 and the rationale behind how we determine the last day of the month. As a rule, comments are for why something is being done, if it’s not obvious, and for magic numbers. Code should tell you what code does.
edit: can anyone spot the bug that I introduced with that parseEndDateFromString() method?
Yeah, proper documentation is not done with comments in code, but it’s a project in and of itself. Proper documentation is also fucking hard and I have no idea how people (in open source projects) can do it. It’s so fucking boring and tedious, especially when there are a million interesting problems you could tackle instead. Mad respect for people writing documentation, seriously.
I also hate writing comments and prefer to just write out everything in code.
I write the shit in the explanation before programming it, its a way to construct a code in human language and logic, with my manual you could program the exact same program in another programming language. (i cant show it because what i program is company secret, including the manual) and yes its kinda boring but everyone is grateful for it and for the things i do i need to make shure its never failing, so its checked by several different people, and such a manual helps a lot for everyone.
yep. Good code is self-documenting and syntax highligting and having longer sections folded up may help more than having to process some greyed out text. But comments are still useful for generating proper autocompletion and avoiding having to skim through you '“self documenting code”. Also it helps greatly with TDD and maintaining good coding practices. For example if you need a numbered list to reliably sum up what some function does, it’s often a good sign that it should be broken into a couple smaller ones.
programmer_humor
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.