Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Commenting out portions of code in Scala

Tags:

comments

scala

I am looking for a C(++) #if 0 -like way of being able to comment out whole pieces of Scala source code, for keeping around experimental or expired code for a while.

I tried out a couple of alternatives and would like to hear what you use, and if you have come up with something better?

// Simply block-marking N lines by '//' is one way... 
//  <tags> """ anything

My editor makes this easy, but it's not really The Thing. It gets easily mixed with actual one-line comments.

Then I figured there's native XML support, so:

<!-- 
  ... did not work
-->

Wrapping in XML works, unless you have <tags> within the block:

class none { val a= <ignore>
  ...
  cannot have //<tags> <here> (not even in end-of-line comments!)
</ignore> }

The same for multi-line strings seems kind of best, but there's an awful lot of boilerplate (not fashionable in Scala) to please the compiler (less if you're doing this within a class or an object):

object none { val ignore= """ This seems like
  ...
  <truly> <anything goes> but three "'s of course
""" }

The 'right' way to do this might be:

/***
  /*
  ... works but not properly syntax highlighed in SubEthaEdit (or StackOverflow)
  */
***/

..but that matches the /* and */ only, not i.e. /*** to ***/. This means the comments within the block need to be balanced. And - the current Scala syntax highlighting mode for SubEthaEdit fails miserably on this.

As a comparison, Lua has --[==[ matching ]==] and so forth. I think I'm spoilt?

So - is there some useful trick I'm overseeing?

like image 867
akauppi Avatar asked Nov 29 '12 17:11

akauppi


People also ask

How do you comment multiple lines in spark?

For single line comment we should use -- and for multiline /* comments */ .


3 Answers

Why not just make use of your source code control mechanism ? Keep the code separate, check it in as separate files and forget it. I wouldn't want my day-to-day code base cluttered up with this sort of stuff.

Note however that if you're not regularly using this code (e.g. in automated tests etc.) it'll suffer from code rot. As soon as you comment out or otherwise shelve this stuff, dependencies will move on and you'll find that before long it just won't link against the existing code base.

like image 136
Brian Agnew Avatar answered Oct 03 '22 23:10

Brian Agnew


I modified the Scala mode's SyntaxDefinition.xml to support /***...***/ style comments.

This is not the same as the Scala parser's support for nested /*...*/ comments, but I didn't find a way to express that for my editor.

In case someone wants to do the same, here goes:

<!-- AK 30-Nov-2012
-
- The Scala parser handles nested '/*...*/' style comments, but the SEE
- syntax highlighting seems not. 
-
- We introduce '/***...***/' style comments (starting with three asterisks
- since JavaDoc uses '/**..*/' style) and deeper levels, to be used for
- blocking out code blocks, even if they contain '/*..*/' comments within.
-
- Note: Original comment handling misses a 'type="comment"' field. Is that vital?
-
- Test: If this works right, the following will be highlighted as a single comment:
-     <<
-       /***
-       */
-       ***/    <- green, not black (note: Scala parses these differently; this is just to test the mode)
-     <<
-->
<state id="Multilevel Comment AK" color="#236E25" type="comment" font-style="italic">
  <begin><regex>/\*\*(?'commentCatch'\*+)</regex></begin>
  <end><regex>(?#see-insert-start-group:commentCatch)\*\*/</regex></end>
  <import mode="Base" state="EmailAndURLContainerState" keywords-only="yes"/>
</state>

You may also want to add type="comment" to the existing few comment highlight rules. I'm not sure if that is vital (other modes than Scala's do so).

Information on SubEthaEdit modes.

like image 34
akauppi Avatar answered Oct 04 '22 00:10

akauppi


There's one more option you've left out. Commenting of any sort has the downside of disabling syntax highlighting as well as not being included in IDE refactorings (Emacs+Ensime, IDEA, Eclipse, etc) or other code intelligence tools, I therefore prefer the following approach instead:

def ignore(block: => Any) = ()
def ignoreIf(cond: Boolean)(block: => Any): Unit = if (!cond) block

ignore {
  // experimental and/or disabled code
  syntaxHighlightingEnabled(true, 3, "foobar")
}

ignoreIf(SomeFeatureEnabled) {
  // experimental and conditionally enabled code
  syntaxHighlightingEnabled(true, 3, "foobar")
}
like image 38
Erik Kaplun Avatar answered Oct 03 '22 23:10

Erik Kaplun