DEV Community

loading...

Discussion on: Attempting to Learn Go - Building Dev Log Part 03

Collapse
dirkolbrich profile image
Dirk Olbrich • Edited

Hey, nice post series. I always learn something new from it.

What would you think of renaming some functions to make them more unambiguous? I know, Go is known for making names as short as possible, but ... πŸ€”

For example

func getContents(f *string) ([]byte, error) {}

The code within explains itself, as it is short enough, but if you read only the function signature, it is not quit clear. Does it get the content of a string and returns it as a byte slice? What, if the function gets longer? I would have to skim a lot more code to understand it.

How about

func getFileContent(f string)

or

func getContent(file string)

And why do you use a reference to the Λ‹fileΛ‹ string instead of a simple value?

Another one would be

func parseFM()

Abbreviations are hard to follow, it not within the closed context of a function. Maybe

func parseFrontMatter()

would make it instantly clear?!

Looking forward to your next post.

Collapse
shindakun profile image
Steve Layton Author

Thanks for the comment! It would definitely make it clearer. I always go back and forth on names, I've been thinking about learning more toward descriptive functions like getFileContent(f string) especially for stuff I'm going to be posting. Now, is probably a good time to try and commit to that. I can't remember why I wrote it that way and didn't just send in a string. It's not like we're memory constrained it doesn't need to be that way and the passed in string would just be garbage collected eventually.