Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add advice on formatting strings using %q #186

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions src/SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -60,6 +60,7 @@
- [Initializing Maps](map-init.md)
- [Format Strings outside Printf](printf-const.md)
- [Naming Printf-style Functions](printf-name.md)
- [Format Strings Using `%q`](formatting-strings.md)
- Patterns
- [Test Tables](test-table.md)
- [Functional Options](functional-option.md)
Expand Down
38 changes: 38 additions & 0 deletions src/formatting-strings.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
# Format Strings Using `%q`

Whenever formatting messages that contain a string component via `fmt`, use `%q` instead of `%s`. This will wrap the specified string in quotes, helping it stand out from the rest of the error message. More importantly, if the string is empty, it will provide a more helpful error message.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whenever formatting messages that contain a string component via fmt, use %q instead of %s.

I think we might want to clarify slightly: it's not necessarily just when a string component in general is used, but more when dynamic strings (incl. user-provided values) could potentially cause interpolation to result in something weird.

Maybe something like:

Whenever dynamic strings - such as user-provided data - are used for formatting,
prefer the placeholder %q over %s.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[...] helping it stand out from the rest of the error message.

More importantly, if the string is empty, it will provide a more helpful error message.

I'd either generalize these slightly or remove the word "error" (this guidance can apply to more than just errors). Maybe something like:

More importantly, if the string is empty or has its own formatting, the result
will be clearer and more consistent.


<table>
<thead><tr><th>Bad</th><th>Good</th></tr></thead>
<tbody>
<tr><td>

```go
fmt.Errrof("file %s not found", filename)
// Prints the following:
// file myfile.go not found
//
// Or if the string is empty:
// file not found
```

</td><td>

```go
fmt.Errrof("file %q not found", filename)
// Prints the following:
// file "myfile.go" not found
//
// Or if the string is empty:
// file "" not found
```

</td></tr>
</tbody></table>

This advice applies more generally to other contexts when reporting user-specified data, such as logging invalid usernames:

```go
log.Printf("User %q does not exist", username)
// User "no_name" does not exist
```
Comment on lines +33 to +38
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would generalize this slightly to something like:

This advice can also apply more generally to other formatting situations
when a dynamic string could confuse or change the formatting or meaning of
surrounding text when interpolated.

Mostly to avoid bucketing "logging" as "formatting" (i.e., structured logging - which is at least as relevant as log.Printf scenarios - doesn't require the same treatment for fields, because they are already discrete values).

I think the log.Printf example is fine to keep, I would just put a good/bad example under the fmt.Errorf examples.

40 changes: 40 additions & 0 deletions style.md
Original file line number Diff line number Diff line change
Expand Up @@ -67,6 +67,7 @@
- [Initializing Maps](#initializing-maps)
- [Format Strings outside Printf](#format-strings-outside-printf)
- [Naming Printf-style Functions](#naming-printf-style-functions)
- [Format Strings Using `%q`](#format-strings-using-q)
- [Patterns](#patterns)
- [Test Tables](#test-tables)
- [Functional Options](#functional-options)
Expand Down Expand Up @@ -3584,6 +3585,45 @@ go vet -printfuncs=wrapf,statusf

See also [go vet: Printf family check](https://kuzminva.wordpress.com/2017/11/07/go-vet-printf-family-check/).

### Format Strings Using `%q`

Whenever formatting messages that contain a string component via `fmt`, use `%q` instead of `%s`. This will wrap the specified string in quotes, helping it stand out from the rest of the error message. More importantly, if the string is empty, it will provide a more helpful error message.

<table>
<thead><tr><th>Bad</th><th>Good</th></tr></thead>
<tbody>
<tr><td>

```go
fmt.Errrof("file %s not found", filename)
// Prints the following:
// file myfile.go not found
//
// Or if the string is empty:
// file not found
```

</td><td>

```go
fmt.Errrof("file %q not found", filename)
// Prints the following:
// file "myfile.go" not found
//
// Or if the string is empty:
// file "" not found
```

</td></tr>
</tbody></table>

This advice applies more generally to other contexts when reporting user-specified data, such as logging invalid usernames:

```go
log.Printf("User %q does not exist", username)
// User "no_name" does not exist
```

## Patterns

### Test Tables
Expand Down