321–330 of 424 posts
Reading the comments, I'm stunned and disillusioned. Are most modern developers struggling to write code without this? If so, there is a fundamental problem that has nothing to do with levels of undo.
I think you simply don't understand the workflow... when and why people do this.
Generally, the idea of referring to an older version of code while working on a later version is good and useful, is it not?
This is just one way of doing this.
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…
My approach is similar to this, except for whole functions/classes I tend to just create a new one with a version number. e.g. DataContext => DataContext2. When I'm satisfied that DataContext2 does everything that DataContext does, I delete old one and rename DataContext2 => DataContext. The risk here, is that sometimes it's not possible to migrate everything to the new version and you end up with multiple old versio…
If you're using a language with strong typing and good refactoring support (right now that's C#/Visual Studio for me), the eventual rename from DataContext2 to DataContext is a non-event.
* works well entirely through keyboard shortcuts (especially useful when editing code)
* the shortcuts are standard so you already know them and have them committed to memory
* works across editors
* high granularity of control over exactly which version of the old code to refer to
Undo trees seem like the best alternative, since it can be done strictly as an extension to convention undo/redo... a little HUD can let you see your current location in the tree and the normal keys can be used to navigate it, with the addition of one more shortcut to change branch.
The "separate window with panning control" suggested in the article seems awful to me.
Sad to see so much judgement in this thread from developers who can't fathom why others would need this. "Sounds like trial an error." "Develop a better memory." Programming is not black and white, there is no right or wrong way to do it. OP discovered a problem they had and wrote a solution for it, believing that others might need to solve the same problem. Clearly they were correct based on plenty of others chiming…
"Sounds like trial and error" Isn't that what coding is?
Bug fixes have a bit more trial and error to them obviously, but it's usually not reading entire code blocks.
If some function becomes too gordian I start working on a refactoring branch to fix it.
I also use 2+ monitors so I experience very little of the code deletion issues referenced here.
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…
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.
Sad to see so much judgement in this thread from developers who can't fathom why others would need this. "Sounds like trial an error." "Develop a better memory." Programming is not black and white, there is no right or wrong way to do it. OP discovered a problem they had and wrote a solution for it, believing that others might need to solve the same problem. Clearly they were correct based on plenty of others chiming…
But I don't do this every 5 minutes, that's just mind boggling. And my reason for doing it isn't that I can't remember or couldn't recreate, it's that I use copy/paste a lot to avoid errors from typo's and the like.
It just seems weird to have to do this that often.
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…
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.
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 constant FOO to 27" or "Made lots of changes in file a.c,, b.c and c.c".
These could be auto generated, and then commits could happen in the background every time the code is compiled.
It would be nice for git to have some kind of "commit of commits" which allows a hierarchical representation of commits. Ie. the "Add new printscreen feature" could have as subcommits "Create print renderer" and "Hook up print UI".
This is awesome, I would use it. Maybe make it a visual studio code plugin?
Earlier quoted context omitted.
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.
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…