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

Why is it so hard to see code from 5 minutes ago?

web.eecs.utk.edu

Post reply on HN
Print view View original

391–400 of 424 posts

Re: Why is it so hard to see code from 5 minutes ago?

#391

Post by sixstringtheory »

xyzzy_plugh wrote: post #244
sixstringtheory wrote: post #241

Earlier quoted context omitted.

You can also use git commit --fixup, or, to fix up a commit with message “wip something”, you can make comments with messages like “fixup! wip something” or “squash! wip something” and git rebase --autosquash --interactive will reorder them all (squash! allowing you to stack commit messages by writing in the commit bodies)

Yes. I usually maintain a hefty stack of commits where the top ~5 are experimental WIP nonsense for me to either clean up to or discard, the next ~10 might be code out for review. But in between pushes to remotes, every session of changes turns into a slew of fixups and I'm often rebasing a stack of 30+ commits, massaged into 2-3 change sets.

I have the same, but now at work we use the GitHub squash function in PRs. I still make fixup commits but don’t have to rebase to manually squash them any more.

Re: Why is it so hard to see code from 5 minutes ago?

#392

Post by est31 »

toyg wrote: post #317
est31 wrote: post #294

Earlier quoted context omitted.

Personally I just use git for that. Even if I'm not 100% happy with some solution, I put it into a commit and then do subsequent improvements, or just remove it again entirely.

But then you end up having to clean up your git history before committing to the shared branches, with squashes and rebases, which is annoying.

Cleaning up your history isn't hard if you think about building a clean-up-able history from the start, where each commit is a unit. At least it is easy for me. If it's larger and complicated, I create branchname-v1, branchname-v2, etc. branches and squash. Those branches will still hang around in my fork of the repo should anyone need them.

As for my personal projects, I recently realized that using leveldb wasn't going to cut it for me right before I finished the database storage feature. I still finished it to create a commit that didn't break the build and then worked on switching to rocksdb. If in the future I decide to switch back to leveldb, it's always there.

Re: Why is it so hard to see code from 5 minutes ago?

#393

Post by est31 »

dd82 wrote: post #306
est31 wrote: post #294

Earlier quoted context omitted.

Personally I just use git for that. Even if I'm not 100% happy with some solution, I put it into a commit and then do subsequent improvements, or just remove it again entirely.

this is indeed useful, but what the parent comment is referring to is it also stores with local history outside of git. So you can check both git history for a selection, as well as local history that exists since your last commit.

I use my editor's history heavily, but never needed something beyond the Ctrl + Z / Ctrl + Shift + Z history to access things done immediately prior. If I'm unsure if I'll need some approach in the future, I make a commit. I've become increasingly good at this prediction.

Re: Why is it so hard to see code from 5 minutes ago?

#394

Post by jonnycomputer »

throwawayboise wrote: post #156
mssundaram wrote: post #141

Earlier quoted context omitted.

I do the same - both commenting out and viewing the file in parallel at different spots - vim vertical splits are great for that. In fact, one of my colleagues remarked that he never thought to view the same file alongside itself when he saw me do that when we were pairing.

> one of my colleagues remarked that he never thought to view the same file alongside itself I do this all the time in Emacs, usually to see two parts of the file that normally are too far apart to be visible at the same time. Collapsible sections can do similar, but to me it's quicker, more natural and more flexible to just split the window.

I think this workflow comes particularly naturally in Emacs, since anytime you split the window (e.g. C-x 3) the current buffer sn already duplicated in the new window. You have to change the buffer in the new window if that is what you want. You can do this in your IDEs too (like Pycharm) but the option to do so doesn't exactly leap off the screen at you.

Re: Why is it so hard to see code from 5 minutes ago?

#395

Post by jonnycomputer »

jamienicol wrote: post #300
throwawayboise wrote: post #156

Earlier quoted context omitted.

> one of my colleagues remarked that he never thought to view the same file alongside itself I do this all the time in Emacs, usually to see two parts of the file that normally are too far apart to be visible at the same time. Collapsible sections can do similar, but to me it's quicker, more natural and more flexible to just split the window.

Another good trick in emacs (if using git and magit) is `magit-find-file HEAD `, then you can edit in one window and see the old version in the other

It actually never occurred to me to do this. Perhaps because I tend to use command-line git, even when using an IDE. I haven't learned magit yet, and I know people swear by it. But this does look like a pretty good way to go about it, at least if your commits have a fine enough granularity.

Re: Why is it so hard to see code from 5 minutes ago?

#396

Post by jonnycomputer »

dmuth wrote: post #390
jonnycomputer wrote: post #133

When making changes to a block of code or block of text, I frequently just comment out the code and rewrite it anew. I might copy-paste existing code (just to avoid stupid transcription errors). If its too large to see both what I'm writing, and the old code, at the same time, I just use two windows on the same file. This is relevant to writing fiction or non-fiction as well. For example, I didn't like this, so I com…

> When making changes to a block of code or block of text, I frequently just comment out the code and rewrite it anew. This is the comment I came here for. (see what I did there?) I also sometimes keep multiple versions of the same line in comments, such as when I'm trying to a tricky regex work. For example, I might have code that looks like: # x = regex1 # Original line # x = regex2 # Doesn't work # x = regex3 # No…

In this case, keeping those in the commit might be worth it, if you come back and find that the regex wasn't right after all. That way you can make sure you (or others) don't repeat your mistakes. The comment could go in the commit message instead I guess, though I tend to keep those brief.

Re: Why is it so hard to see code from 5 minutes ago?

#397

Post by constantine42 »

Code smell, poorly factored. I almost never do this, but when I do, it's almost always because the code is already messy.

This can vary by problem domain and language. I see some examples of regex below and I can agree with that, because regex is difficult to read.

Re: Why is it so hard to see code from 5 minutes ago?

#398

Post by bfung »

covidthrow wrote: post #376
bfung wrote: post #144

Earlier quoted context omitted.

TDD (test driven development) really help in solidifying interfaces ahead of time and also to capture regressions. Yes, git diffs help, but once I’ve passed a parameterized suite of unit tests, never needed to undo/redo. Maybe not perfect the first go, but only need one/two tries to working code. Then refactor for readability.

TDD is definitely helpful, but I don't ever use it as a metric for code fitness. At best it proves a limited number of inputs produce a limited number of expected outputs. Consider, for example, a bug recently introduced during a refactor at my work: The programmer optimized a conditional based on a regex by transforming it into a simple string compare. All the tests passed, code/branch coverage was good. Except that…

There’s def. ways to write really good tests as well to avoid the limited input issue - write the test in a property-based test manner, like haskell’s quickcheck, and the test can catch entire classes of bugs.

The caps vs. no caps issue would be easily caught using randomString() as the test case.

Re: Why is it so hard to see code from 5 minutes ago?

#399

Post by ggpp »

strictnein wrote: post #383
ggpp wrote: post #358

Earlier quoted context omitted.

no it's webpack HMR (I know you're joking)

Hmm... I actually wasn't. By "live" I mean in the developer's own browser.

Ohhh, I thought it was a riff on "I don't always test my code, but when I do, I do it in production."
Post reply on HN