Live data from Hacker News

Small programming tricks

will-keleher.com

91–100 of 187 posts

Re: Small programming tricks

#91
> git log -S pattern (”git pickaxe”)

Another option is to do a ‘git log -p’ followed by a string search ‘/‘. It can give more context and let you browse more easily, especially if the project has small commits. It won’t work well for every project or search though.

Re: Small programming tricks

#92

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).

I do that too. I am trying to use Mise. (Getting interested in Maak. Haven't done anything with it yet. My Scheme is pretty rusty)

Still, Zsh history with fzf fuzzy searching is fantastic. I have years of history I can recall commands with a few keystrokes.

Truly a second-brain.

Re: Small programming tricks

#93
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…

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.

Re: Small programming tricks

#94
post #2

This 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…

> To what extent are people still coding by hand these days?

That's basically I all do. I might ask a few questions to LLMs here and there like Google/StackOverflow in the days of yore.

Still, every line in all my codebases are still hand-typed. I get everything I need out of the chatbots, and I cannot use any kind of agentic coding tools at work, oddly enough. Trust me, I'd love to have access to something like Codex at work. That way I could save my mental bandwidth for personal projects that I find interesting and enjoying.

Re: Small programming tricks

#96

Earlier quoted context omitted.

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.

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

Re: Small programming tricks

#97

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

I have the same feeling, there are new approaches and tricks to get things done, mainly from how to work with AI more efficiently. But the human brain still needs to be trained and learn new things to not get rotted

Re: Small programming tricks

#98
post #65

Earlier quoted context omitted.

I rather think the opposite. People who share tips and hacks are genuinely trying to help others, while people who hoard information are competing on an individual basis without regard for team.

Please take this in good faith, as I hope your own post is, but I interpret the thread you're replying to as focusing on the "everyday' part. Share knowledge? I don't think anyone here is arguing against that in any way (or conversely arguing for hoarding knowledge). The concern, one I share, is where the sharing has to happen publicly "every day" - so no matter how trivial, useless, niche, overly-specific the tip is…

Yep, crop dusting knowledge in a public space without at least tying it to something relevant is a faux pas in my book.

Offering to teach someone something proactively? Sure, go ahead.

Sharing stuff freely when asked and arming someone with the tools to investigate further? Amazing!

Treating a public channel like ye olde facebok wall? Mildly annoying.

Re: Small programming tricks

#99
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 last word (ctrl+w) but they don't seem to be as portable.

Re: Small programming tricks

#100

Earlier quoted context omitted.

OK, but the code with the branch is easier to understand.

Yeah, I don't buy the premise that branchless code is intrinsically easier to understand. Maybe OP's point is that adding unnecessary branches makes code harder to read? But that's generally the case for any unnecessary code.

I see stuff along the lines of:

  if (x == 0) {
      return y;
  }
  
  y += 25*x;
  return y;
and skipping the if just makes the function shorter and simpler, while also not involving the CPU branch prediction. Another one that doesn't necessarily skip all branching but at least drops one - and more importantly makes the code simpler and easy to verify, is removing the if statement in code like

  if (count == 0) {
      return;
  }

  for (int i = 0; i != count; i++) {
    puts("hello");
  }
Post reply on HN