Tuesday, May 27, 2014

Golang: Formatting Your Code with Gofmt

Contrary to what some may think, I do try to keep several balls in the air; work obligations, the podcast (Geeking After Dark), and (when I have a good block of time along with a solid idea of what small step I want to accomplish) my organically mutating GoLang experiment, all being kept in the air as I try to fit in a functional amount of sleep. Recently I have been losing more sleep than usual to the stress of finding a new apartment, and now am in the middle of a rats nest involving the arrangements that come with trying to actually move locations.

Good times!

But through all this I still managed to get an occasional commit on my personal Go project.

Learning to program with a personal project in a language you haven't used before can be an almost zen-like experience. I'm hitting all sorts of moments when I sort of feel like I'm starting to understand why certain memes and practices are in place, and using a language that itself is the product of insights gleaned from perceived design issues with other languages allows me to take advantage of certain aspects encouraged in the programming language. Rarely will you find a language where the users keep asking each other for help in the form of, "What is the idiomatic way to do this?"

The last time I found a language that had such a strong "This is the proper way to do this in this language even though you can get it to work doing it a different way but we'll judge you for doing it wrong" vibe it came from books introducing new programmers to Ruby on Rails. Not that this was a bad thing; I feel that in a proper context with a proper design, it's possible that the "proper" way of doing something in that language ends up just feeling better and being more readable.

Readability...often subjective, and something that can (and does) spawn huge threads of argument. It's probably where much of the push for newer programming communities to have a canonical proper way to do things originated.

I was looking up information for implementing a feature fermenting in my head when I discovered that Go, despite being a relative newborn in the field of programming languages, has a utility in the standard suite of tools meant to help you format your source code in the proper way.

I used it, and I really like it.

all you have to do is:

gofmt -w yoursourcecode.go

...and it'll replace your .go file with a reformatted file. While I didn't have (from what I could tell) huge changes, it did spruce my stuff up a bit. And it looks, so far, like it didn't break anything. If you just run gofmt without the -w, it'll write the output to standard output, which you could direct to a new file through redirection if you were so inclined.

Gofmt actually has a few options you can use to try streamlining things by eliminating extra parens and such. I haven't experimented with it; being relatively new,  I sometimes prefer being overly explicit in what I place into my sources so I have less trouble figuring out what I'm trying to accomplish later on; besides, the compiler removes and optimizes much of my inefficiencies for me. For now I'm at a level where running gofmt before a commit will be a workflow insertion to help keep my source a little more clean, and it also helps in learning the proper way to format source code.

If you're new to programming and trying to learn Go, try using gofmt in your workflow. Use the resulting files to absorb what is considered good practices in writing clean-looking and maintainable source. I won't say that it's perfect, but it should at least point you in the right direction of creating source code files that are easier for others to read and maintain down the road, including for your future self.

Especially your future self. Trust me on that.

No comments:

Post a Comment