11 ms·
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.
by jonnycomputer 6y ago
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.
- 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.