I find myself using ctrl-r less and less as I make sure that anything of value that I work out goes into a Makefile or the app tooling, for me this is the basis of the dev-ops approach to work (make sure everything is scripted, not worked out on the fly).
Small programming tricks
81–90 of 192 posts
Re: Small programming tricks
#82Re: Small programming tricks
#83welllll that depends entirely on the DB Software you're using. A certain IBM product certainly has opinions on this.
Re: Small programming tricks
#84Re: Small programming tricks
#85> At a previous company, I shared a trick on slack every day with the engineering team, both technical and company-specific, and folks found them pretty useful. I would find that annoying, however to not be seen as a jerk I wouldn't say anything.
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…
"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 sharing knowledge, especially when seeing someone else do something that can be done better. But just leaving daily breadcrumbs to remind people you're the guy that teaches random trivia feels like attention seeking.
Re: Small programming tricks
#86The 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…
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".
Re: Small programming tricks
#87The most useful shell trick I've used to date is mapping the 'cd' command to 'zoxide', which is a more powerful version of cd that remembers folders you've been to.
Re: Small programming tricks
#88Only a few of these are actual programming tricks. The problem with sharing them is that they'll typically seem obvious to you, since you know them. It's difficult to know what is actually unknown to other people, and if you share stuff everybody knows you risk coming off as arrogant. Here's one that I think more people should know: avoid branches. If I can do the same thing without an if statement and even a logical…
I'm struggling to comprehend how branches can be avoided (or why one would want to, as they are the cornerstone of programming). I can only think how to obfuscate them, which is rarely useful.
A trivial example is actually written with a branch in C/C++, but relies on compiler optimizations to kick in. If you compile a ternary operator in C/C++ (and probably rust, C# and other languages) such as in:
int min_branchless(int a, int b) {
return a
With gcc/clang a -O2, one would expect the compiler to emit the following assembly: cmp edi, esi
cmovle eax, edi ; select a if a
There's numerical tricks for other operations/comparisons, and compilers know a lot of them. But, I just suggest compiling your code and configuring your compiler to emit the generated assembly with references to the code it was generated from (you should be able to get it to emit source line references in the assembly). You'll likely be surprised at the optimizations applied at -02, and utterly confused by what you find at -03.edit: Also, it doesn't mean to never branch, but to minimize branching, especially in tight loops. Branch outside loops, not inside, for instance.
e.g. don't do:
for (...) {
if (condition independent of loop variable) {
...
} else {
...
}
}
do: if (condition independent of loop variable) {
for (...) {
...
}
} else {
for (...) {
...
}
}Re: Small programming tricks
#89This reminded me to ask: To what extent are people still coding by hand these days? In my profession (academia), literally no one codes anymore. On one hand, it sucks because the joy and fun of programming has been replaced by constant agent orchestration tasks, but on the other hand, it's hard to go back to the way things were before because the productivity gain is so good. I remember learning a lot of these progra…
LLM's have not affected us in the slightest when it comes to coding. Maybe we write a snippet, post it for llm to scrutinize, and usually LLMs spout bullshit and wrong suggestions and after enough verbal abuse it points to some issues with the code.
But I don't get this delegation to LLM's for your entire coding. I hope everyone delegates to LLM :) (sarcasm)
Re: Small programming tricks
#90I find myself using ctrl-r less and less as I make sure that anything of value that I work out goes into a Makefile or the app tooling, for me this is the basis of the dev-ops approach to work (make sure everything is scripted, not worked out on the fly).
Ctrl+r is great, sometimes. History saving sucks which can make using it difficult, but i usually use it out of laziness than trying to recall a command, especially with ssh or repeated iterations requiring flipping between two settings/states. Its hard to rely on it for other things, but its still super useful.