Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Small programming tricks

will-keleher.com

Post reply on HN
Print view View original

111–120 of 187 posts

Re: Small programming tricks

#111

Post by rustyminnow »

kccqzy wrote: post #29
jawns wrote: post #10

I would love for someone to package up some kind of script or AI skill that evaluates your current terminal config/set-up and applies all of these tips and tricks. For instance, it might detect that you currently use ag, install ripgrep, and offer a short tutorial on how users accustomed to ag should use it. Or it might look at the history of git commands you've run and offer tips on efficiency improvements.

Going from ag to ripgrep is not unequivocally better. Sure ripgrep is faster, but its file filtering using -g is so much more cumbersome than -G in ag. The latter uses a regex and the former uses glob. I type many more characters to do the same search, and the same search is maybe 0.1s faster for a medium codebase. So no for me. Maybe it’s worth it for a larger codebase that isn’t large enough to require indexing.

ag is also a little more ergonomic with its default flex casing: your query is case-sensitive if it has any uppercase letters, otherwise case-INsensitive. rg defaults to case-sensitive (but does have flags for insensitive and flex casing)

Re: Small programming tricks

#113

Post by t-writescode »

rootlocus wrote: post #85
CableNinja wrote: post #30

Earlier quoted context omitted.

I think that "everyday" would be a stretch, but i dont understand why youd think thats annoying, someone took the time to consider helping the rest of the engineering team grow, by posting something useful. I frequently do the same, but not everyday; only when i think its something actually useful/helpful beyond the everyday crap. Most recently, we have had a huge push to use ai (just like everywhere else), ive been…

Why just one each day then? Why not a shared knowledge base? Do you start with a "bag of tricks" and then hand them out one by one each day to remind people you're the guy with the bag of tricks? "Oh, yeah, I know a cool trick, but y'all have to wait until tomorrow to find out what it is." "Look! It's a way to evaluate SQL expressions with a select with a from! Oh, you already knew about it?" I have nothing against s…

You’re right, a centralized repository would be good too.

Both a centralized repository AND a daily message, especially for new employees, would be ideal, imo!

Normalize chatting and sharing stuff in slack!

Re: Small programming tricks

#114

Post by corps_and_code »

taink wrote: post #96
corps_and_code wrote: post #46

Earlier quoted context omitted.

Maybe they mean rather than: if (thingThatIsTrue): // a bunch of logic here... else: // different logic here... they mean: if (thingThatIsTrue): return doThisWhenTrue() return dothisWhenFalse() Just a simple example. I'm not sure if this is what you consider "obfuscating" the branches. Logically the same, but a bit more linear to understand? Edit: I am bad at formatting comments here.

Putting two spaces before the line formats is as code. Example: No space before start of line. One space before start of line. Two spaces before start of line. Thus, you can put multiple lines of code with indentation as well as long as you put two spaces at the start of the line: int main() { return 0; } int main() { return 0; } See https://news.ycombinator.com/formatdoc

Oh perfect, thanks!

Re: Small programming tricks

#115

Post by simlevesque »

NegativeLatency wrote: post #72
simlevesque wrote: post #67

Earlier quoted context omitted.

You can mute the channel. Why would you want your teammates to communicate less ?

I think that it would be unwise to mute #engineering or whatever the main eng channel is >I shared a trick on slack every day with the engineering team

An engineering team may have multiple channels.

Re: Small programming tricks

#116

Post by gosub100 »

throwaway219450 wrote: post #99
kccqzy wrote: post #38

A lot more tricks can be learned from just watching AI work. Instead of allowing AI to work autonomously, go back to the old days where you manually approve every command the AI runs. Just recently while doing performance optimization work, I found Opus using the `perf` command in ways I didn’t know possible. Just give AI a real task and carefully read what commands are used by the AI to solve the problem; most likel…

There are several keyboard shortcuts that you would never find out from watching an agent, but are mindblowing to new Linux users. I suck at remembering vim keybindings, but I have ingrained ctrl+a ctrl+e for jumping to the start/end of a string (which also works all over OS X). I had been a developer for an embarassing amount of time before I discovered those. There are other terminal specific shortcuts for removing…

Another one, not quite as handy but still awesome: ctrl s / ctrl-q. This freezes/unfreezes the terminal output so you can read it, without interrupting your program. Useful for very fast walls of text.

Re: Small programming tricks

#117

Post by ellieh »

ChickeNES wrote: post #109
quirino wrote: post #93

Earlier quoted context omitted.

atuin kind of fixes this habit, when you click up you get a list of the latest commands, and you can just start typing to search. It's extremely natural.

I found atuin way too hard/slow to use, I think I went two days before I nuked it and went back to pure omzsh. Has it gotten any better in the past 2ish years?

(hi! I work on atuin!)

yes, it's improved a lot in the last couple of years! what in particular bothered you?

Re: Small programming tricks

#118

Post by weaksauce »

diath wrote: post #86
phforms wrote: post #77

The thing with a lot of these tricks is that you have to get into the habit of using them. I knew `Ctrl+r` for history since I learned about the command line. I even have a nice shell integration with fzf. But I still used the up/down arrow keys for years or scrolled up when I was looking for a previous command, because I never remembered the shortcut and just took the path of least resistance to find something. Usua…

> But I still used the up/down arrow keys for years or scrolled up when I was looking for a previous command It's not even that bad of a habit with zsh either where it will only scroll through history matching a substring in your history, for instance if I type "rg -i" and then start pressing up arrow, it will only cycle through history entries starting with "rg -i".

if you enable history substring search in zsh you can get that feature anywhere in the command and not just the start. it's very useful if you remember some snippet of the command like it had the word debug in it etc. in fish that is built in and on by default.

though one function that i recently added will narrow your history down based on a space separated set of filters which i found useful

    function hgrep
        set -l cmd history
        for pattern in $argv
            set cmd "$cmd | grep -- "(string escape "$pattern")
        end
        eval $cmd | cat
    end
use `hgrep ruby debug foo` would filter for a line that contained all the words ruby, debug and foo.

Re: Small programming tricks

#119

Post by thatcherc »

monideas wrote: post #31

Almost all of these are irrelevant in the age of AI, except for the logarithm thing

Can you explain that one (the logarithm trick)? I have no idea what it's trying do to. Is it saying that it's convenient or useful to know the order of magnitude of a number rather than its value?

Re: Small programming tricks

#120

Post by harikb »

diath wrote: post #86
phforms wrote: post #77

The thing with a lot of these tricks is that you have to get into the habit of using them. I knew `Ctrl+r` for history since I learned about the command line. I even have a nice shell integration with fzf. But I still used the up/down arrow keys for years or scrolled up when I was looking for a previous command, because I never remembered the shortcut and just took the path of least resistance to find something. Usua…

> But I still used the up/down arrow keys for years or scrolled up when I was looking for a previous command It's not even that bad of a habit with zsh either where it will only scroll through history matching a substring in your history, for instance if I type "rg -i" and then start pressing up arrow, it will only cycle through history entries starting with "rg -i".

Clearly I am missing some setting. On zsh on macOS and I tried what you just said and it doesn't work like this
Post reply on HN