361–370 of 424 posts
We had considered ways to expand on this feature for educational purposes by adding audio to create a tutorial but never could allot resources for this.
Earlier quoted context omitted.
Hello from the bizarro universe of people who do this all the time and can't imagine the opposite. Do you never rewrite some code only to realize it didn't precisely capture all the edge cases of the thing you rewrote? In those cases I use the git gutter in VSCode to view what the old code looked like and compare and contrast to the new version to see what I missed. It seems to me that that's the same as what these e…
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.
For anyone that uses emacs, there is an excellent plugin "undo-tree" that solves this problem in a slightly different way. Everytime you undo a series of actions and then perform a new action, it creates a branch in the "tree". You can then visualize the tree and move through it quickly your entire buffer history.
Even without undo-tree, Emacs undo history is "persistent". By that I mean that changes aren't overwritten, so the statement in the article that undoing stuff and then making edits loses the undone changes is not true for Emacs. You just have to undo back through the new edits, then you will start to redo the old undone edits, and so on. It can be tedious, but just the knowledge that it's all there is quite liberatin…
Jetbrains IDEs have a local history feature that provides snapshots with diffs and allows partial rollbacks. I only use it when experimenting with different approaches. Mostly I only use the "Local Changes" tab in the Git panel that shows the diff compared to the last commit, or "Compare with branch" to see the overall changes relative to the base branch.
VSCode also has a local history plugin. One of my default installs https://marketplace.visualstudio.com/items?itemName=xyz.loca...
Earlier quoted context omitted.
> the wrong way is not constructive. Well, open minded people can try other ways. Mine is sitting back and thinking instead of racing the keyboard to try out stuff until it works. Both ways (as I compare to my exclusively younger colleagues) reap results in about the same timespan, but I hardly type more than the actual code I need to type while my colleagues write and delete books ('iterate fast') in that time. It b…
My guess is that the code that was thought through first will be better (easier to understand by the next developer) than the code generated by many iterations.
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.
I typically have it open beside my IDE so I can keep an eye on the progress in the file tree view. I can drag-select a set of lines, right-click and stage them, when I'm basically locking those in, then keep going.
It also auto-fetches every minute or so, so I have great visibility on what coworkers are doing in the commit graph. Lets me react to what they do pretty quickly, and I can implicitly review what they do and I can poke them if I notice something weird.
This is honestly the feature keeping me on PyCharm over VSCode the most. The "local history" feature of JetBrains IDEs is amazing. It saves on every blur, and has a diff viewer when comparing with history.
NetBeans has the same feature. I cranked it up to keep it for 30 days. Very handy. It's essentially an "automatic git" on every save.
Earlier quoted context omitted.
> 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". I would argue that these are not good commit messages as they do not add information not already provided by the diff itself. Commit messages should communicate the intended effect of a change that has been made, rather than being a…
In which case I want a lossy summary of the diff... And it would be great if a tool could generate those for me...
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…
This is the one thing above all else which has kept me off Go. Tentatively comment out a line or two and the whole compilation process may come crashing down because now you have a declared but unused variable, and mere warnings apparently aren't Gestapo enough in this particular universe. You then find and comment out the offending declaration, only for the compilation to die in flames again because now you referenc…