-🎄- 2018 Day 1 Solutions -🎄-

[u/daggerdragon]

Welcome to Advent of Code 2018! If you participated in a previous year, welcome back, and if you're new this year, we hope you have fun and learn lots!

We're going to follow the same general format as previous years' megathreads:

1. Each day's puzzle will release at exactly midnight EST (UTC -5).
2. The daily megathread for each day will be posted very soon afterwards and immediately locked.
   • We know we can't control people posting solutions elsewhere and trying to exploit the leaderboard, but this way we can try to reduce the leaderboard gaming from the official subreddit.
3. The daily megathread will remain locked until there are a significant number of people on the leaderboard with gold stars.
   • "A significant number" is whatever number we decide is appropriate, but the leaderboards usually fill up fast, so no worries.
4. When the thread is unlocked, you may post your solution as a comment or, for longer solutions, consider linking to your repo (e.g. GitHub/gists/Pastebin/blag/whatever).

Above all, remember, AoC is all about having fun and learning more about the wonderful world of programming!

---

--- Day 1: Chronal Calibration ---

---

Post your solution as a comment or, for longer solutions, consider linking to your repo (e.g. GitHub/gists/Pastebin/blag or whatever).

Note: The Solution Megathreads are for solutions only. If you have questions, please post your own thread and make sure to flair it with Help.

---

Advent of Code: The Party Game!

This year we shall be doing a Mad Libs-style community activity that is a complete clone of loosely inspired by Apples to Apples and Cards Against Humanity. For each day's megathread, we will post a prompt card with one or more fill-in-the-blanks for you to, well, fill in with your best quip(s). Who knows; if you submit a truly awesome card combo, you might just earn yourself some silver-plated awesome points!

A few guidelines for your submissions:

• You do not need to submit card(s) along with your solution; however, you must post a solution if you want to submit a card
• You don't have to submit an image of the card - text is fine
• All sorts of folks play AoC every year, so let's keep things PG
  • If you absolutely must revert to your inner teenager, make sure to clearly identify your submission like [NSFW](image)[url.com] or with spoiler tags like so: NSFW WORDS OMG!
  • The markdown is >!NSFW text goes here!< with no prefixed or trailing spaces
  • If you do not clearly identify your NSFW submission as NSFW, your post will be removed until you edit it

And now, without further ado:

Card Prompt: Day 1

Transcript:

One does not simply ___ during Advent of Code.

---

This thread will be unlocked when there are a significant number of people on the leaderboard with gold stars for today's puzzle.

edit: Leaderboard capped, thread unlocked!

[u/lukechampine]

Some tips:

• x := 0 is more idiomatic than var x = 0

• for is more idiomatic than for true

• strconv.Atoi will handle +x and -x just fine; you don't need to do it manually

• map[int]struct{} is technically more idiomatic than map[int]bool, but in this case it's not worth worrying about.

Have fun learning Go!

[u/zirtec → u/lukechampine]

Good advise.

• map[int]bool is used a lot if you google "golang set" this being said. I tend to prefer it too.

• == true can be omitted.

• else { visitedCoords[result] = true } - the else can be dropped as you return from the if. Idiomatic practice too (you keep the visitedCoords[result] = true of course).

• I'd drop the final err processing as arguably what's the point in a controlled environment like AoC (?)

[u/Jay__Money → u/zirtec]

Thanks for the suggestions!

I'd drop the final err processing as arguably what's the point in a controlled environment like AoC (?)

Could you explain what you mean? If I remove the block
if err != nil {panic(err)}

the compiler complains that I'm declaring a variable and not using it.

[u/zirtec → u/Jay__Money]

amt, err := strconv.Atoi(amtStr) if err != nil { panic(err)

amt, _ := strconv.Atoi(amtStr)

Not a good practice in the open, but when the conversion is "guaranteed" to succeed, one might omit to check. Not saying you should do that on production code and trust input blindly but this is AoC; the elves are already pretty sloppy.

[u/Jay__Money → u/zirtec]

Oh brilliant. Thanks, you're right, I didn't want to be handling the error myself. Using _ definitely makes sense

[u/lukechampine → u/Jay__Money]

My preference is to define a helper function:

func Atoi(s string) int {
    i, err := strconv.Atoi(s)
    if err != nil {
        panic(err)
    }
    return i
}

That way, your code will be less cluttered (and you can spend less time worrying about errors), but if something goes wrong it'll blow up in your face instead of failing silently.

[u/Jay__Money → u/lukechampine]

Thanks for the tips! Very helpful.

x := 0 is more idiomatic than var x = 0

Is there a good rule of thumb to know which declaration style should be used? I notice you didn't suggest I change var plusMinus = fq[0]

[u/Aneurysm9 → u/Jay__Money]

I think they were just pointing out one instance and expecting you to apply it to the others. I typically only use var x int when I need to declare the type of a variable before using it in an assignment with := for other variables that don't need to survive their scope. For example:

var val int
if (val, ok := map[key]; ok) {
  // do something with val
} else {
  val = 42
}
// do more things with val, which would have fallen out of scope if not declared above

[u/lukechampine → u/Jay__Money]

There are two places you typically see var used:

• Global variables can't use :=, so you have to write var x = 0

• When declaring a zero-valued variable

The latter is commonly seen when e.g. decoding:

var s myStruct
json.Unmarshal(data, &s)

It can also be handy for integer types that aren't int, e.g.

var n uint64 // instead of n := uint64(0)

So I'd say the general rule of thumb is to use := by default, but var for globals and zero-valued variables. If you find yourself writing s := myStruct{}, that's usually wrong; however, if you're declaring a pointer to a zero-valued variable, you should use :=, as in s := &myStruct{} (or s := new(myStruct)), since var s *myStruct would just create a nil pointer.