With our new functions added of both CountLines and CountBytes, the next thing we want to do is make use of them inside of our actual code. Currently, if I just run the go run command passing in the words.txt, we're still only getting the value of 5, which is the number of words inside of our text file. Instead, we want to be able to count all of the attributes and have them printed to the console whenever we run our code similar to the wc command.

In order to do that, however, we're going to need to make a change to our CountWordsInFile function, which currently only returns an integer as its single return type. Instead, we want this function to return multiple integers, one for the number of words, another for the number of bytes, and another for the number of lines.

We could do this by changing the return value to return multiple integers as follows:

return CountLines(file), CountWords(file), CountBytes(file)

Additionally, we'll want the CountLines to be first as that's the order defined by the wc command.

Then inside of our actual code, we can go ahead and do:

lines, words, bytes := CountWordsInFile(file)

And we'll need to also change the value inside of our if err block as well. And with that, we're now returning the three properties in our CountWordsInFile function of lines, words, and bytes.

---

Whilst this code works, personally, I think there's a couple of issues with it, at least when it comes to both maintainability and readability as well.

For starters, if we head on over to the main function, and let's go ahead and call the CountWordsInFile function again. Whilst we can see in our editor that this file returns three integers back, it's hard to know which integer relates to which attribute in our CountWordsInFile function.

In our case, because we know that the first value is the lines, the second value is the words, and the third value is the bytes, then it's fine if we want to use this code. But if anybody else tries to read this code later on, or if our future self just forgets which attribute is which, then this could lead us in a situation where we accidentally present the wrong information to the user.

Whilst we can solve this using, say, comments or good naming, personally, I prefer to just apply more context when it comes to the actual code. Of which, there are a couple of ways we can do so when it comes to Go.

---

In order to see what those approaches are, let's head back on over to our CountWordsInFile function, and we'll take a look at the first approach, which is to specify named return parameters, which we can do as follows:

func CountWordsInFile(f *os.File) (lines, words, bytes int, err error)

However, when I now go to build this code, you'll notice that we now get an error letting us know that we have mixed named and unnamed parameters. This is because whilst we have set names for our three integer return parameters, we haven't set one for the error, which causes an issue when we try to compile this code.

Fortunately, we can resolve this by just setting a name for our error return value, which in this case I'm setting to err.

Now we have a few warnings that have appeared, which is that we have no new variables on the left-hand side of each of our shorthand initializers. This is because in Go, when you define named return parameters, it actually goes and creates those values inside of your actual function, although does so implicitly rather than explicitly.

Which means rather than recreating our variables of lines, words, and bytes, instead we can just assign the values to them as follows:

lines = CountLines(f)
words = CountWords(f)
bytes = CountBytes(f)

---

Now, if we head back on over to the main function and call our CountWordsInFile function again, this time you can now see that we have some indication about what the return values actually are, thanks to the fact that we're using named parameters.

However, personally, I still don't like this approach. For example, whilst we are giving more context about what's happening, having four return values, to me, feels kind of excessive. Personally, I always stick to a two return value maximum rule, sometimes going for three, although this is a personal preference, and if you want to return three return values, you absolutely can.

---

The other issue that I have with this approach, however, is a little bit more nefarious.

For example, if we go ahead and actually remove our calls to the CountLines, CountWords, and CountBytes functions, now if I go ahead and build this code, you can see it still works, despite the fact that we've forgotten to actually represent either of these three values. This is because, as I mentioned before, each of these three variables are created when we assign a name to the return parameter.

Perhaps even more nefarious than this, however, is what happens if we just refuse to return anything. This, in my opinion, should fail. However, if I head on over to a new terminal window and build this code, you'll see it compiles without an issue.

This is because, in Go, if you happen to have named return parameters, any return statement without arguments returns the named return values. This is known as a naked return, and whilst it's valid in Go, personally I have a couple of issues with them.

---

Personally, I find this to be rather hard to read, and typically when I'm scanning code, especially if the actual function signature is outside of view, such as:

return

Then this doesn't give me any indication about what the return values actually are, and I'll just assume that this function is an empty return function.

Whilst this doesn't happen too much on shorter functions, where the entire function contents are available on the screen at a single time, in longer functions, such as even our main function, where you need to scroll down to see the entire thing, this can present some problems. So personally, I think this is a bad practice. Although, again, this is my own opinion, and if it's something you want to do, then feel free to do it.

Personally, however, I'm not going to do so, so I'm instead going to return it as I had it before, and not return three integers and an error, instead reverting to only two return values.

---

So, in that case, how do we go about returning multiple values, even though we're constrained to two return values?

Well, in that case, we can make use of a struct type in order to encapsulate the actual return values.

To do so, let's go ahead and create a new struct type, called Counts, which will encapsulate the three counts we want:

type Counts struct {
    Bytes int
    Words int
    Lines int
}

Then, rather than returning a single integer inside of our CountWordsInFile function, let's go ahead and change this to be our actual Counts struct, which we can do as follows:

func CountFile(f *os.File) (Counts, error)

---

Next, let's go ahead and resolve the errors being reported by our text editor.

The first on line 18 is letting us know that we cannot use the value of zero, which is an untyped int constant, as Counts value in the return statement. Instead, in the case of an error, if you'll remember from error handling, we'll want to return an empty Counts type in this case:

return Counts{}, err

This would default all of the values of the fields to be zero.

Next, we then cannot use the count variable of type int as Counts values in the return statement. So again, we can go ahead and return this as a Counts literal:

return Counts{
    Bytes: CountBytes(f),
    Words: CountWords(f),
    Lines: CountLines(f),
}, nil

---

However, there's one last thing that I think we should go ahead and change. If you'll notice, the name of our function is CountWordsInFile, which unfortunately is no longer accurate, as we're no longer counting only the words, but we're counting other properties as well, such as the number of bytes and the number of lines.

Therefore, let's go ahead and change this to just be CountFile, which is a little bit more accurate and returns the counts from the various different properties.

With that change made, let's head back on over to our main.go file, or our main function, and let's make the following changes to make use of this new CountFile function, passing in our file name.

counts, err := CountFile(file)

Next, we then need to change our totals from being just:

total += wordCount

to:

total += counts.Words

And we then need to print out the counts:

fmt.Println(counts.Words)
fmt.Println(counts.Lines)
fmt.Println(counts.Bytes)

---

Now, if I go ahead and run this code, as you can see, it should work as expected. However, there's a bit of an issue.

You'll notice here we're now getting the value back of 0 from our words.txt, which is kind of strange, as before we were getting back the value of 5.

However, let's see what happens if we go ahead and add in our other counts, of Counts.Bytes, of Lines, and Counts.Bytes.

Now, if I go ahead and run this code, you'll see this time we're only getting the value of bytes. However, when I run the wc command, you'll notice that all three values are able to be printed. So what's going on?

Well, if we take a look at our CountFile function, you'll notice that the CountBytes function is the one that we're calling first. If I go ahead and change this so that the CountLines function is now the first one being called, and go ahead and build and run the code yet again, you'll see this time the lines count is being printed, but the bytes count is no longer.

---

So what's going on?

This is a bug due to a certain property of the os.File or the io.Reader type, and one that we're going to need to solve in our next lesson in order to get our code to actually work.

Before we go ahead and solve this, go ahead and add the count.go and main.go changes into your git repository, adding in a new Counts struct in order to keep multiple counts from file.

And with that, I'll see you in the next lesson where we'll figure out what's actually happening with this code and how we can solve it.