10 ms·
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 a
by jonnycomputer 6y ago
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 commented out:
>though his companions jogged just behind him, he would have barely seen them at all had he look. They ran, with their heads down, attentive only to their feet slapping the muddy earth, tracking the path they followed, their breath ragged.
and wrote this, using the commented-out text as a reference:
The fog was now so dense that he could see nothing ahead of him. He ran with his head down, breath ragged, attentive only to his feet slapping the muddy earth, tracking their path. His companions followed close behind.
- mssundaram 6y agoI 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.
- sslayer 6y agoCommenting is the answer. It stays until I'm certain I no longer need it.
- jonnycomputer 6y agoAs 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.
- powvans 6y agoYes! Just today I was wishing that I could have syntax highlighting on commented code that I was refactoring. Just dim it a bit instead of turning it all grey.
- pjungwir 6y agoPerl and Ruby have this. In Perl it's kind of an abuse of the perldoc system, like this: print "foo" =pod print "won't run" =cut Ruby basically copied it, although I don't think these have documentation uses: puts "foo" =begin puts "won't run" =end When I get to choose, I prefer sticking to // in C code so that I can use /* ... */ for hiding large blocks of code . . . although #if false ... #endif work too.
- logbiscuitswave 6y agoA 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 code readability.
- jonnycomputer 6y agoCool. I've never touched C#. But that seems like an approach applicable pretty generally. I like it!
- CobsterLock 6y agoI 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 //
- logbiscuitswave 6y agoIt’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/master/documentation/SA1626.md https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/ma...
- gnabgib 6y agoI'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.
- logbiscuitswave 6y agoHere’s more about commenting style: https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/master/documentation/SA1515.md 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.)
- WalterBright 6y agoI'll sometimes use: version (all) { ... new version ... } else { ... old version ... } and change `all` to `none` to try the other branch.
- throwaway744678 6y agoIn C, you can wrap the 'commented' code with #if 0 ... #endif
- hazeii 6y agoOr indeed if rewriting a block of code: #if 1 ....new code... #else ....old code... #endif Esp. for tricky stuff, it's then possible to just flip the 1/0 to easily test/compare/profile the new/old code. Some IDE's will even work out which block of code to colour and which to dim.
- jack_riminton 6y agoWhy have I never thought of that?
- _0ffh 6y agoI do the same, even in languages without a preprocessor. You can just use a life if-else, most compilers will optimize the test-on-a-constant away. Even when the code is kept in, I doubt it will have a major performance impact during testing in most cases.
- yitchelle 6y agoI would do a bit more by #if !defined(this_works_but_it_suck_memory_too_hard) .... #else .... #endif That should give me a clue why I "disabled" it when I come back to it 5 minutes later.
- MauranKilom 6y agoI usually just do this with a comment behind the #if false. Yes, nobody is probably ever going to define that particular identifier, but comments are also less restrictive (you can write normal text).
- unfunco 6y agoIn languages with multiline comments like /* and single-line comments like //, you can do: //* old_code(); /*/ new_code(); //*/ And remove the first slash from the first line to switch between blocks.
- thewakalix 6y agoScheme has #; which comments out a single expression. This covers most but not all use-cases. (It doesn’t help for commenting-out subsequences, like if you wanted to remove the top half of a begin block.)
- Gibbon1 6y agoSometimes I do stuff like // FIXME try new way mm/dd/yy if(1) { ... new way ... } else { ... old way ... }
- jfk13 6y agoIt's not a formal distinction, but in C++ code where all the ordinary comments use //, it can be handy to use /* ... */ to comment out a block. (Of course, if there's a stray /* ... */ comment already in the area to be commented out, this will fail. But an editor with appropriate syntax colouring can make that immediately apparent.)
- deleted 6y ago[deleted]
- shawnz 6y agoI like to put a space following the // if it's written text comments, but no space if it is commented-out code. I think the space looks nicer for text comments, but when I select a block of code and hit Ctrl+/ to comment it out, my IDE does not add a space. So it works out very conveniently for me.
- bennysonething 6y agoHrm, but it's obvious if somethingis commented out code vs an actual comment. I'm probably missing something here.
- throwawayboise 6y ago> 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.
- jamienicol 6y agoAnother good trick in emacs (if using git and magit) is `magit-find-file HEAD <file>`, then you can edit in one window and see the old version in the other
- jonnycomputer 6y agoIt 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.
- jonnycomputer 6y agoI 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.
- gnubison 6y agoVim does a similar thing to Emacs here: the `:sp` and `:vs` commands take an optional argument that, if given, loads a file in the new window. Otherwise the new window just contains the same buffer.
- josephg 6y agoI use this workflow a lot and while I’m still figuring out how I want to implement something. I’ll often just do the whole thing in one file, commenting, and rewriting and restructuring code as I go with multiple open windows to different parts of the file. I only break it up when I’m happy with the abstractions, and I know where the natural fault lines run between functions, classes and concepts. Doing this too early feels wrong; like I’m prematurely committing to a division of responsibility that’s going to subtly drive me to a bad design.
- Insanity 6y agoThis is exactly what I do. Vim split of the same file, one side for editing and the other for context. Works great!
- peach45 6y agoShouldn't it be "had he looked."? Also the second rendition makes doesn't include what the rest of the joggers are doing, yet the first one does. Not sure if intentional. At first I gasped at your practice, because I never do that, but I see the point now. Mastery of language.
- jonnycomputer 6y agoYes, I had a typo. I was editing in place, and then decided that I had made some poor choices and needed to start over. I didn't bother to fix the typo. Yes, there is a shift in point of view between the two versions. But the story is mostly written in third-person limited, and so my first version deviated from that. But I rewrite everything every time I read it, so who knows what will happen tomorrow.
- trashme 6y ago> Also the second rendition makes doesn't include what the rest of the joggers are doing ... Something is amiss here.
- peach45 6y agoKarma/backlash for my rude post. I will leave it unedited, but s/makes// in case it is not clear.
- jonnycomputer 6y agoI didn't take it as rude. Should I have?
- interfixus 6y agoThis 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 reference a never declared variable. It gets tiresome after a while.
- OskarS 6y agoAre unused variables really compiler errors in Go? That does seem very harsh, and very counter productive while developing. -Werror is all well and good, but while I’m in the middle of writing the code, it’s a bit much.
- interfixus 6y agoThey were, last time I looked. Which was admittedly a while ago.
- Gibbon1 6y agoEven worse if you include something that isn't used, that's also a fatal error.
- strken 6y agoThe theory is that given enough code, any antipattern that compiles will make its way into real use, and therefore the only way to make people stop using an antipattern is to refuse to compile it. Go trades inconvenience in the short term for removing an entire class of bugs and raising the readability floor of bad code.
- pharke 6y agoThat's an insane approach, eslint solves this just fine and is fully configurable for almost any style preference.
- dustymcp 6y agoI do the exact same i was thinking this article was silly..
- thomasahle 6y ago> I frequently just comment out the code and rewrite it anew That still doesn't give you easy access to the state of the code _halfway through the rewrite_, which is what the article mentions.
- dspillett 6y agoI do this, though it can get messy when I'm experimenting with multiple changes. As an experiment recently I've taken to keeping snapshots of active work areas using rsync every minute that there are changes present - an automated full-tree version of "keeping copies of the file" that works for everything (images, word processor docs, ...) not just my code editor, avoids an accidental change when doing undo-redo "breaking" the redo buffer, and it survives explicit file closes which undo/redo buffers usually do not. There are two significant caveats: it only works at all if I save regularly while tinkering (or the editor auto-saves regularly), and it doesn't work for files mmap-ed or otherwise open-locked by the editing process. Not terribly efficient IO wise, and still wouldn't be with the improvements I know I could make but haven't got around to, but it has proven helpful at times and takes very little space for several days of snapshots most of the time (identical versions of the same file in each snapshot are hard-linked not duplicated).
- faichai 6y agoMy 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 versions lying around, i.e. technical debt.
- zepearl 6y agoI do the same, but the opposite way, hehe - I rename e.g. "DataContext" to "DataContextOLD1", then I write the new "DataContext" (from scratch or by copying the original one and then modifying it), this way I'm sure that all calls to DataContext always use the new version.
- isaacdl 6y agoI do this too! A big benefit is gradual migration - for example, if I'm injecting DataContext into a bunch of different places, I can implement part of the functionality of DataContext. Once I have just enough functionality implemented to support one of the places it's injected, I update that place to take DataContext2. Then I can test, and move on to the next place. 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.
- throwaway4good 6y agoI used to work like that. Now I don't. (And I would advise against it.) Use version control, do lots of small of commits, use diff. Have a fast edit, build, test/run cycle. If you don't have it then spend the time setting it up.
- Rayhem 6y ago<sarcasm>My employer told me a 23-step code submission process, across five tools, that takes four days to run all the tests is fast enough. Is that fast enough?</sarcasm>
- throwaway4good 6y agoExactly. Lots of comments. People afraid of doing changes. Or removing old unused code. Not fully understanding what is going on. All signs of a broken development setup. Spend the time and do it right. You will be paid in multiples.
- washadjeffmad 6y agoWhen editing lab notebooks, it's customary to finely cross a line through data or notes you wish to discount without affecting their legibility. It's also expected that any edits or annotations be circled, dated, and initialed. The point is that data is never destroyed, and this is one of the many causes for the unflagging preference for tangible records over ELNs.
- quacked 6y agoHuh, I thought your first example was much more poetic. The vaguely run-on sentence does a much better job of evoking what's happening in the scene.
- jonnycomputer 6y agoThanks. I'll think about it.
- happimess 6y agoFor the record, I think the second version is a clear improvement.
- quacked 6y agoOut 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."
- happimess 6y agoIn both, the aloneness of "him" is the focus. In the first, his companions are the subject of both sentences. In the second, The fog and "he" are the focus, with his companions only mentioned as an afterthought.
- sdevonoes 6y agoI 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.
- CobsterLock 6y agoI get this for tracking down a bug or working on speeding a block up. But why does the unused code need to be committed? Yes it helps you with your one problem but it clutters the document with extra information for others. So I guess I phrased my question a little accusatory, commented out code is a pet-peeve of mine, but I'm still genuinely interested why the two different blocks need to be committed. Or i guess more importantly, if they need to be pushed to the mainline for others to recieve
- zrobotics 6y agoMaybe I misread the parent, but I don't think it was stated that the commented out code is committed. FWIW, I also sometimes work this way; however I delete the commented out block when I'm finished. This is also a pet peeve of mine, the only time commented out blocks of code are acceptable is if the obvious way to write something introduces a bug or ignores an edge case. In that case, I also leave a note explaining not to refactor this section and explain why. But especially while refactoring or fixing certain issues, I really find it helpful to have the prior version still present to compare against. If I have to commit while that commented code is still present, invariably my last commit message is along the lines of "removed commented code" or "cleaned comments for function XYZ". Especially since for these cases I also typically end up writing a comment once finished anyway. If there was something tricky enough happening that I was comparing against older code, likely there is something confusing enough happening that whoever is in the file next could also use some additional explanation that can only really be written once finished.
- londons_explore 6y ago
- flemhans 6y agoHow do you comment things out in the "English fiction/non-fiction" programming language?
- jonnycomputer 6y agoI'm writing in markdown. I use the quoting > character, instead of the more verbose [comment]: #(my comment) syntax. Emacs markdown mode changes the color of the text, and that is enough for me. I use the [comment]: $(my comment) syntax for actual commentary on the text.
- dmuth 6y ago> 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 # Nope # x = regex4 # Also nope x = regex5 # Currently testing this That gives me the way to see which approaches I've tried while solving the problem, and ensures I don't actually use the same exact regex twice. When I get a working solution, I comment out all but the line that works and commit that.
- jonnycomputer 6y agoIn 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.