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

401–410 of 424 posts

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

#401

Post by bennysonething »

jonnycomputer wrote: post #151
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.

As an aside, I think I wouldn't mind if a programming language would include two commenting syntaxes, one for ordinary comments, and another for commenting out. These are two very different use-cases, and distinguishing them syntactically might facilitate certain kinds of work-flows.

Hrm, but it's obvious if somethingis commented out code vs an actual comment. I'm probably missing something here.

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

#402

Post by b3n »

jolmg wrote: post #380
im3w1l wrote: post #304

Earlier quoted context omitted.

It's been over a decade since my bad experience so take my words with a grain of salt. Iirc, the issues I had was that I made a huge history of undos-followed-by-redos-followed by-undos-etc etc and the more I navigated my history the more tangled and out of control it became. I think I also had a problem with often accidentally switching from undo to redo mode. Emacs documentation recommends using C-f (forward-charac…

I agree. It's cool that it's lossless, but doing a lot of undos and redos makes the history quickly unwieldy to navigate. I much prefer vim's tree implementation. I wouldn't say that it's worse than the standard, though. Unwieldy as it may be, I like that I can just keep on pressing C-/ and eventually get to the state I want without risk that I may have lost it because I accidentally made a change after a series of u…

> doing a lot of undos and redos makes the history quickly unwieldy to navigate

Are you aware of the `undo-only` (and `undo-redo`) functions? They make it a breeze to navigate even the most complex undo history.

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

#403

Post by [deleted] »

est31 wrote: post #392
toyg wrote: post #317

Earlier quoted context omitted.

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

[deleted]

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

#404

Post by justinnhli »

dorian-graph wrote: post #310
justinnhli wrote: post #25

Earlier quoted context omitted.

> > (3) There is no visual indicator of where you are are in your undo/redo history. > There might be plugins that somehow present this info in the interface. The undotree vim plugin [1] does this, and gives both the file at the time as well as a diff of what changed. [1]: https://github.com/mbbill/undotree

> undotree I was going to mention this plugin. I haven't fully mastered quickly jumping around in it, but it's one of those things that when it's useful, it's VERY useful.

Ditto. Unless I have to go back a lot of edits, I don't actually use the plugin that often. I've mapped my undo/redo keys to traverse the undo tree instead of the undo stack:

nnoremap u g-

nnoremap g+

It takes a little bit of getting use to, but it takes care of most instance where I need a previous edit from a minute ago.

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

#405

Post by jolmg »

b3n wrote: post #402
jolmg wrote: post #380

Earlier quoted context omitted.

I agree. It's cool that it's lossless, but doing a lot of undos and redos makes the history quickly unwieldy to navigate. I much prefer vim's tree implementation. I wouldn't say that it's worse than the standard, though. Unwieldy as it may be, I like that I can just keep on pressing C-/ and eventually get to the state I want without risk that I may have lost it because I accidentally made a change after a series of u…

> doing a lot of undos and redos makes the history quickly unwieldy to navigate Are you aware of the `undo-only` (and `undo-redo`) functions? They make it a breeze to navigate even the most complex undo history.

Actually, I wasn't. Thanks for that.

(undo-redo) doesn't seem to be defined in stock Emacs, but undo-tree defines (undo-tree-redo), which does the needful.

My comment was more about lamenting the defaults in comparison with vim's, but it's true that it doesn't take much configuration to make it much better.

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

#406

Post by quacked »

happimess wrote: post #382
jonnycomputer wrote: post #351

Earlier quoted context omitted.

Thanks. I'll think about it.

For the record, I think the second version is a clear improvement.

Out of curiosity, do you do much creative writing? I agree that the second version is clearer and more grammatically sensible, but the first version bends the normal usage of syntax to evoke emotion, although a word here or there could be adjusted.

Here's an example of a similar update; would you say you like the second version more?

"Halting, stuttering, his words slurred, his eyes watery, his knees trembling, he thrust forth the knife, and with a cry the blow was struck-"

vs.

"His knees trembled, his eyes were watery, and spoke in a steady stream of unintelligible nonsense. With a cry, he thrust forth the knife, and the blow was struck."

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

#407

Post by logbiscuitswave »

gnabgib wrote: post #377
logbiscuitswave wrote: post #162

Earlier quoted context omitted.

A common code style rule for C# is // for comments and //// for commented out code (/// is reserved for documentation generation). StyleCop analyzers can enforce this during code analysis passes. While this isn’t a language construct (a comment is a comment after all), Visual Studio can key off these stylistic differences to show code comments vs commented code differently. I find it to be a neat trick to improve cod…

I've never seen this in C# code! How common is this? Do you have any references? Sounds like a useful convention (it's nigh impossible to google). VS only distinguishes between `///` (docblock) and all other (double, quadruple,quintuple, /*/). But maybe there's an extension.

Here’s more about commenting style:

https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/ma...

StyleCop is used for analyzing code style in C# code.

Specifically:

> If the comment is being used to comment out a line of code, begin the comment with four forward slashes rather than two.

StyleCop relies on this to tell the difference between commented code and code comments. If you use ReSharper, it can do some nifty transformation to strike these out in the IDE which is kinda cool too.

I’m a big fan of StyleCop to enforce consistent code styles. (Even if it’s not always what I may aesthetically prefer.)

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

#408

Post by logbiscuitswave »

CobsterLock wrote: post #330
logbiscuitswave wrote: post #162

Earlier quoted context omitted.

A common code style rule for C# is // for comments and //// for commented out code (/// is reserved for documentation generation). StyleCop analyzers can enforce this during code analysis passes. While this isn’t a language construct (a comment is a comment after all), Visual Studio can key off these stylistic differences to show code comments vs commented code differently. I find it to be a neat trick to improve cod…

I thought //// was psuedo reserved for documentation. and then // was for general comments. I usually use block comments for commenting out code or I just use VS hotkeys which I think are //

It’s actually /// (3 slashes) that reserved for pseudo-documentation use.

There’s a StyleCop rule to enforce this as well:

https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/ma...

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

#409

Post by beermonster »

eithed wrote: post #389

My primary editor is VSCode, but I've got Sublime open as well. When making changes part way, I just cmd+x -> cmd+v to Sublime. This way if something doesn't work out I don't need to undo to whatever it was that was working. If operating on multiple files I can have the snippets in the same tab, or different tabs in Sublime.

Check this out then. It’s like git-timemachine for Emacs but for VS Code

https://marketplace.visualstudio.com/items?itemName=bee.git-...

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

#410

Post by jononor »

londons_explore wrote: post #328
sdevonoes wrote: post #320

Earlier quoted context omitted.

I do the same. Many people comment about commiting frequently but that doesn't work for me: delete code + commit => I don't see the code anymore and my brain magically forgets about it. I need the quick feedback loop: commented code + uncommented code (all in one screen) => new code is going to look like a mix of both. If I have to use git to see commented code then the feedback loop is broken.

Commiting frequently also has a substantial cost of needing to think of a commit message. If you don't think of a commit message, you'll never be able to find this version again. If you think up a message every 2 minutes, you'll quickly find you spend more time thinking of commit messages than writing code. I wish there was some kind of auto generated commit message. Things like: "Added function xyz()" or "Adjusted c…

Putting low-effort comments into temporary commits is OK. The one can use interactive rebase (git rebase -i) to squash and edit it into a coherent and clean history, when things get closer to finished.
Post reply on HN