7 ms·
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
by mssundaram 6y ago
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.
- 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!