Kotlin Coroutine Confidence: Add formatter off/on comments (pg 162)

Pragmatic Bookshelf PragProg Customers
,
1

As a minor suggestion, in timers/v19/src/main/kotlin/com/example/timers/TimerApplication.kt, you might want to consider adding // @formatter:off and (optionally) // @formatter:on comments:

val timer = java.util.Timer()

// @formatter:off
fun main() {                               /* Secret hidden brackets */
  println("3…")
  timer.schedule(1000)                         {
  println("2…")
  timer.schedule(1000)                         {
  println("1…")
  timer.schedule(1000)                         {
  println("Liftoff!")
  timer.cancel()                               } } }
}
// @formatter:on

While this appears fine in the book, and should appear as desired in the code in someone’s IDE, there is the possibility that someone might reformat the source code at some point, such as when first starting out. (I have been known to do that sometimes.) In such a case, the non-standard formatting being used in this example would be lost. You could even just put the // @formatter:off comment before the import statement so it is out of the way, and wouldn’t show in the book’s snippet.

Of course this assumes the user has the “Turn formatter on/off with markers in code comments” option enabled. (IntelliJ IDEA documentation). And to be honest, I can’t remember what the default is. You could potentially add a .editorconfig file to the root of the downloaded source with this enabled:

ij_formatter_off_tag = @formatter:off
ij_formatter_on_tag = @formatter:on
ij_formatter_tags_enabled = true

The EditorConfig plugin is a bundled plugin, and so this file will take effect.

If you do add the .editorconfig file, you may also want to include the indenting settings since the 2-space indent being used may conflict with a user’s more typical 4-space default:

[*]
indent_size = 2
indent_style = space
tab_width = 2
ij_formatter_off_tag = @formatter:off
ij_formatter_on_tag = @formatter:on
ij_formatter_tags_enabled = true
2

Good point, I understand why you bring it up! I’m the same, I’m constantly running the autoformatter on autopilot using keyboard-shortcut muscle memory.

Even though running this code example in the IDE isn’t too important—since the visual appearance of the source code is more important than what it actually does—I can see why testing it out would still be instructive. Including the // @formatter:off comment will make that easier for many people, and won’t do any harm for the rest, so I’ll certainly consider it—along with a note in the text. I’ll stop short of the editorconfig step, though. Anyone who has changed the settings away from their defaults is probably already aware, as you are, of how to fix the problem for themselves.

Thank you for the detailed suggestion!

3

For me it’s not just about testing the code. I tend to just look at code samples in my IDE even if I’m not running it. After 23+ years of near daily use of using IntelliJ IDEA, I just grok code quicker in my IDE with its consistent font and syntax highlighting compared to elsewhere. It’s not even a conscious thought to translate a style (bold purple) to a code meaning (constant). It just happens. I can also open Javadoc/KDoc on things as I explore the sample. Add to that the fact that the formatting of the provided code sometimes is not my preferred style, making it harder for me to grok. So a quick Ctrl+Alt+L reformats it for me. (Hence the importance of @formatter:off in this case.) So when I read a tech book and it shows a code sample, I turn to look at it in my IDE on my 2nd monitor rather than looking at it in the ebook. I’m likely more of an exception more than the rule in this regards :slight_smile: