At the end of the last lesson, we managed to resolve the bug we had when it came to file offsets, and now our counter works when it comes to testing individual files, such as the words.txt, and when it comes to testing standard in, using say the following syntax. As you can see, both of these counts are coming back correctly.

However, if I go ahead and pass in multiple files, such as the words.txt and lines.txt as follows, whilst the individual file counts are working correctly, currently we're only producing a single total, which is the total of the number of words from each file. To solve this, we have a couple of different options. We could go about creating an individual integer in order to represent each of the three properties, so total words, total bytes, and total lines. However, this feels very reminiscent of when we first made the changes to our CountFile function, when we started by returning three different integers.

In my personal opinion, a better approach is to make use of the actual encapsulation we already have, which is the Counts struct. Making use of this struct in order to track the number of totals, such as follows:

var totals Counts
totals.Bytes += counts.Bytes
totals.Words += counts.Words
totals.Lines += counts.Lines

There's actually a number of different reasons why I prefer this approach. For starters, whilst we're only tracking three properties, it's incredibly trivial to add yet another one. Let's say we want to keep track of the numbers of letter A's, let's say, or letter A. By using a struct which encapsulates all of the properties, we won't actually have to change much of our code in order to support new attributes.

Additionally, if we want to change the value from int to say, int64, which we will do later on, then this is also going to be easier to use this Counts type as well.

---

Next, we can then go about adding in some code in order to print out these actual values. This is going to be similar to lines 31 and 36:

fmt.Println(totals.Lines, totals.Words, totals.Bytes)

With that, if we now go ahead and test this code, it should run as expected, with our new total line printing out the totals from each of the files that we pass in.

However, if we go back to our code, you'll notice that each of the three fmt.Println lines on line 31, 36 and 40 are pretty similar. And not only this, but they also need to be in the same order. For example, if we accidentally had a bug where we were printing the words first and the lines second, this would be pretty bad to present to the user.

Therefore, this is a bit of a justification to have a single function that we can use to print out the actual properties of a Counts type.

---

Let’s open up count.go and define a function called PrintCounts, which takes a Counts type and a file name:

func PrintCounts(c Counts, fileName string) {
    fmt.Println(c.Lines, c.Words, c.Bytes, fileName)
}

In main.go, replace fmt.Println calls with:

PrintCounts(counts, fileName)
PrintCounts(counts, "") // for stdin
PrintCounts(totals, "total")

This works, but there's a better option: methods.

---

Let’s refactor PrintCounts to be a method on the Counts type:

func (c Counts) Print(fileName string) {
    fmt.Println(c.Lines, c.Words, c.Bytes, fileName)
}

Now update the calls in main.go:

counts.Print(fileName)
counts.Print("") // stdin
totals.Print("total")

This is cleaner and reduces duplication.

---

Even better: Instead of:

counts := GetCounts(file)
counts.Print(fileName)

You can now write:

GetCounts(file).Print(fileName)

It still works the same, but it's more concise.

---

Now, let’s add tests for this method. In count_test.go:

func TestPrintCounts(t *testing.T) {
    testCases := []struct {
        name   string
        input  Inputs
        want   string
    }{
        {
            name: "simple five words.txt",
            input: Inputs{
                Counts:   Counts{Lines: 1, Words: 5, Bytes: 24},
                FileName: "words.txt",
            },
            want: "1 5 24 words.txt\n",
        },
    }

    for _, tc := range testCases {
        t.Run(tc.name, func(t *testing.T) {
            var buf bytes.Buffer
            tc.input.Counts.PrintTo(&buf, tc.input.FileName)

            if buf.String() != tc.want {
                t.Logf("Expected: %q, Got: %q", tc.want, buf.String())
                t.Fail()
            }
        })
    }
}

To support that, change the method to:

func (c Counts) PrintTo(w io.Writer, fileName string) {
    fmt.Fprint(w, fmt.Sprintf("%d %d %d", c.Lines, c.Words, c.Bytes))
    if fileName != "" {
        fmt.Fprintf(w, " %s", fileName)
    }
    fmt.Fprint(w, "\n")
}

Now we can test output precisely using a bytes.Buffer.

---

Handle stdin case:

{
    name: "no file name",
    input: Inputs{
        Counts:   Counts{Lines: 20, Words: 4, Bytes: 1},
        FileName: "",
    },
    want: "20 4 1\n",
}

If you see test failures like extra spaces or missing newline, it's usually because of the default behavior of fmt.Println or spacing in Fprintln. Use Fprint with a format string for precise formatting.

---

With that:

• ✅ We now have a reliable print method
• ✅ It’s reusable across files and stdin
• ✅ It’s testable
• ✅ We’re ready for the next lesson

In the next lesson, we’ll improve the interface by removing the need to pass in an empty string for no file name—using variadic parameters.