style: using gofmt to format your code about sonic HOT 5 CLOSED

Every line in this project, as long as it is been written by me, are hand-tuned for aestheticness. Programming is a kind of art, not just tasks that someone forced you to finish.

Programs are indented to be read by human, not machine. Machines do NOT understand aestheticness, they can only do certain things pre-programmed by it's designer. It's also why there is very hard for computers to generate aesthetically pleasing arts.

If it's a trade-off, as long as they are functionally identical, I don't want to trade aestheticness for almost nothing.

IMO, go fmt is just an excuse to the laziness of programming. NEVER write messy code and hope go fmt magically fixes all the issues for you.

And also, go fmt is A code-style, not THE code-style. If Go really wants to force everybody to write identically looking code, they should fuse it into the syntax.

We have the rights of choosing our own style of programming, as our ByteStyle stats:

Champion Diversity and Inclusion

Take a look:

A hand-formatted program

func NameOf(id int) string {
    switch (id) {
        case APPLE  : return "Apple"
        case BANANA : return "Banana"
        case ORANGE : return "Orange"
        default     : return "Unknown"
    }
}

is considerably more readable and cleaner than the machine-generated counterpart:

func NameOf(id int) string {
	switch id {
	case APPLE:
		return "Apple"
	case BANANA:
		return "Banana"
	case ORANGE:
		return "Orange"
	default:
		return "Unknown"
	}
}

Also, the go fmt has some wierd formatting rules that cannot be turned off:

if a < (x + y) * z << 5 {
    // do something
}

will be formatted into

if a < (x+y)*z<<5 {
	// do something
}

which is A LOT messier.

Consider editing CONTRIBUTING.md.

from sonic.

Can you explain how a different code style might prevent others from participating in this project?

from sonic.

Can you explain how a different code style might prevent others from participating in this project?

check this: https://github.com/bytedance/sonic/blob/main/CONTRIBUTING.md#contribution-prerequisites, please.

You need fully checking with lint tools before submit your pull request. gofmt & golangci-lint

If you don't follow the contribution rules yourself, why should others follow?

and in google code review comments: https://github.com/golang/go/wiki/CodeReviewComments#gofmt:

Gofmt
Run gofmt on your code to automatically fix the majority of mechanical style issues. Almost all Go code in the wild uses gofmt. The rest of this document addresses non-mechanical style points.
An alternative is to use goimports, a superset of gofmt which additionally adds (and removes) import lines as necessary.

I think at least you guys represent bytedance, right? Isn't the company code specification mandatory to use gofmt?

If we mr, it will be a disaster to see that all files are modified, because of our using of gofmt

from sonic.

hello @wymli , I've opened a pr for this #37 and find out that the code after format is less prettier than the code before format.

I learned that the code is formatted manually with great care by @chenzhuoyu to make it pretty, because there's a lot of assembly code in the go files, and assembly code format is not the same as the go code. Unfortunately, gofmt cannot handle this at the moment.

Here's some diffs, you may compare them and determine which looks better:

You may also take a look at the pr #37 .

Thanks for your suggestion anyway.

from sonic.

That's a trade-off, maybe just ignore these mannually fine-tuned *.go files or code snippets.
The tools can't fit all scenarios.

from sonic.