<p>I wanted to give go a try so I made Sponge - a news and link aggregator. Any feedback or suggestions are appreciated!</p>
<p><a href="https://github.com/bobo333/sponge" rel="nofollow">https://github.com/bobo333/sponge</a></p>
<hr/>**评论：**<br/><br/>drannoc-dono: <pre><p>Hey man. That's a good job for a first go project. I do have some feedbacks for you :o)</p>
<p>I suggest you using a more-fit-for-Go structure for your files, as described by Ben Johnson (<a href="https://medium.com/@benbjohnson/structuring-applications-in-go-3b04be4ff091" rel="nofollow">https://medium.com/@benbjohnson/structuring-applications-in-go-3b04be4ff091</a>). It's a classic behavior that a lot of beginners have (made it myself) to build its piece of software in Golang "application oriented" by putting the main package at the root of the sources, sort of a web fashion. Go development is "library oriented", it's a different approach that I find more logical, makes you think of your code in a more open and reusable way.</p>
<p>Pretty much linked to the "application oriented" way of thinking, you don't need to go ape with subpackages. Can become a hell of public/private struct with public/privates method and render your code harder to read. Golang point of view tends to be "go the simplest way"</p>
<p>If I was trawler and your main function an iceberg, I would sink. I suggest you to cut it up in functions, some part of your main could be factorized, and use more early return conditions, for clarity.</p>
<p>You test error return, that's good! But most of the times it simply gets printed. The user most likely won't know anything went wrong, except if software output gets read or redirected to a file. I guess that was enough for you to put it that way for now and change that in future updates, but I had to point this out.</p>
<p>I hope that helped. Good day to you :o)</p></pre>bobo333: <pre><p>Thanks for taking the time to critique! Useful suggestions, and the article is helpful as well, cheers</p></pre>
