Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Practical Go: Real-world advice for writing maintainable Go programs

dave.cheney.net

Post reply on HN
Print view View original

221–230 of 237 posts

Re: Practical Go: Real-world advice for writing maintainable Go programs

#221

Post by freyir »

entity345 wrote: post #178
freyir wrote: post #177

Earlier quoted context omitted.

If you’ve seen any amount of Go and Java code (starting with, say, the standard libraries), you’d know these communities take very different approaches to variable names.

The point is that you do not choose the way to name variables based on a sheepish "it's the way the community does it". You're responsible for your own code, and your organisation's code. It has nothing to do with the language.

I know the point you're making, but I don't think it's very convincing.

First off, OP is talking about a trend in the community to favor shorter and shorter names. He didn't say you need to code that way, but there is an increasing chance that the programmers you work with, or the libraries you depend on, will have adopted this convention.

Second, unless you are coding in a vacuum or starting a brand new project, you're usually expected to follow the conventions of an existing codebase. These were likely influenced by conventions in the community, which often are set by conventions in the standard library, which have much to do with the language.

Re: Practical Go: Real-world advice for writing maintainable Go programs

#222

Post by yiyus »

atombender wrote: post #215
yiyus wrote: post #196

Earlier quoted context omitted.

Could you work around this somehow using a combination of internal packages and type aliases in public packages?

Not sure. But sounds messy -- type aliases aren't really intended for that.

It was more a sincere question than a suggestion. I haven't written any serious Go since aliases were added and have never had any need for them so far.

Re: Practical Go: Real-world advice for writing maintainable Go programs

#223

Post by Groxx »

coder543 wrote: post #175
Groxx wrote: post #168

https://dave.cheney.net/practical-go/presentations/qcon-chin... > 8.3. Never start a goroutine without [knowing] when it will stop. 100% agreed with the concept, but even the final example is flawed. That'll unblock and continue immediately after `close(stop)`, without being able to do two important things: it can't tell you when it's done shutting down, and it can't tell you if it encountered an error. Fixing this m…

> 100% agreed with the concept, but even the final example is flawed. That'll unblock and continue immediately after `close(stop)`, without being able to do two important things: it can't tell you when it's done shutting down, and it can't tell you if it encountered an error. Fixing this makes it even more complex. The final example actually does both of these things already, but maybe you're confusing the purposes o…

Shutdown blocks until draining is complete, but ListenAndServe returns immediately when Shutdown is called: https://golang.org/pkg/net/http/#Server.Shutdown

>When Shutdown is called, Serve, ListenAndServe, and ListenAndServeTLS immediately return ErrServerClosed. Make sure the program doesn't exit and waits instead for Shutdown to return.

So no, this writes to the "done" channel essentially immediately once `close(stop)` is called, and ends the process prematurely.

Re: Practical Go: Real-world advice for writing maintainable Go programs

#224

Post by Roboprog »

kazagistar wrote: post #214
SaltyBackendGuy wrote: post #109

Earlier quoted context omitted.

Now write a unit test for function fDing() { ... } Honestly with modern JS I am not sure this feature is that great. Looks more like a code smell these days imo. Edit: Formatting

Make private functions that are only visible to the current module. Then write your unit tests directly in that same module, next to the functions, so they can access them even when the rest of the world cannot. Of course, this requires sensible language support.

Hierarchy vs list. I don’t want a list (of subroutines). I want a tree of self contained routines. Only your containing routine uses you. Which “private“ routines use which? (I know the IDE will tell me about this routine, and that routine, but I don’t want to have to ask)

Your employer doesn’t want you testing getters, anyway, but rather features. Unit test fanatics need to stop.

I guess unit tests were useful for C++, when it was constantly crashing everything :-(

C++ and its legacy need to ride off into the sunset, already.

Re: Practical Go: Real-world advice for writing maintainable Go programs

#225

Post by chewxy »

platz wrote: post #138
ilovecaching wrote: post #136

So I don't know how to fly a commercial airliner, but I could probably figure my way around a small single prop airplane. That's basically the difference between Go and a language like Rust or C++ or any language that requires a lot of up front investment, but then let's you work at power level 9000. So yeah, Go will get you there. It will take you a lot longer to get there when you aren't going 600MPH, and you can c…

But Go will never be a data science language like python, because Go is too limited to express that domain. Python may leave you in the lurch when it comes to maintainability, but for some domains python is infinitely better than Go.

Hmm. Weird. Almost my entire data science pipeline is in Go.

Re: Practical Go: Real-world advice for writing maintainable Go programs

#226

Post by platz »

chewxy wrote: post #225
platz wrote: post #138

Earlier quoted context omitted.

But Go will never be a data science language like python, because Go is too limited to express that domain. Python may leave you in the lurch when it comes to maintainability, but for some domains python is infinitely better than Go.

Hmm. Weird. Almost my entire data science pipeline is in Go.

Data engineering is not data science

Re: Practical Go: Real-world advice for writing maintainable Go programs

#227

Post by jimsmart »

twentythree wrote: post #65

> 2.3. Don’t name your variables for their types What's the best way to handle a situation where you use two different types for the same data? e.g. var usersMap map[string]*User var usersList []*User

Personally I'd use usersByID and users - I nearly always name my maps thingsByKey, and my default is that a plural thing on its own is nearly always a list, so adding a suffix of List doesn't add anything much here for me (Cheney's "Don’t name your variables for their types").

Re: Practical Go: Real-world advice for writing maintainable Go programs

#228

Post by jimsmart »

dana321 wrote: post #94

My advice would be this: If you have a specific reusable component.. Make a package to contain it. Use init() to compile any regular expressions and store them as variables within that package, so that you don't Split out related code in a folder, remembering that the included code is done in alphabetical order - so shared functions within the same package you should alphabetically make it the first to be included. Y…

> Use init() to compile any regular expressions and store them as variables within that package

No need to resort to init() for regexps, simply use an unexported package level variable:

var validFoo = regexp.MustCompile(...)

Re: Practical Go: Real-world advice for writing maintainable Go programs

#229

Post by lugg »

hackinthebochs wrote: post #97
dilap wrote: post #62

Earlier quoted context omitted.

I feel like I have the opposite problem. If the name is more than a few characters long, it starts to become non-instantaneous to recognize it. Things get much easier to follow with visually-instantly-recognizable symbols. So in conditions where a variable is used over a short area in the code (or where it's used _constantly_ over a wide area), I prefer short variables.

Totally agree. If you have to scroll up to be reminded what some variable means, a longer name is good. But if its usage is a few lines away from its declaration then there's no reason to add visual noise to your code.

I tend to agree here but I limit that to block scope as a general rule, I also only bother with really common concepts.

id identifier

i loop counter

j inner loop counter

c general purpose non loop counter

a, b, comparator methods

k, v, key value setters, array iteration

e, event, error or exception. Contextual rule but rarely collides.

Other than those I pretty much always write entire full word names. If it's abbreviated or shorthand it likely sounds funny in my head, or it leads to ambiguation. If I need to even ask / recall for a split second it's not good enough.

Programmers incorrectly place far too much weight on time to type. I write like ten lines of code on a good day. It's just not important. I want readable code that is clear and concise as possible. Every branch, block or shorthand variable raises a question I have to think about before moving on.

Clever code is why I call ten lines of code a good day. It sure as shit isn't my typing speed.

Re: Practical Go: Real-world advice for writing maintainable Go programs

#230

Post by Gibbon1 »

noir_lord wrote: post #58
jerf wrote: post #8

Earlier quoted context omitted.

The authors have chosen to make it as limited as they have on purpose, as I understand it. I disagree with them, but here we are. I've been slightly tempted at times to make something with markdown but never gotten enthusiastic enough to put the time. Plus, markdown is technically a bit too powerful, so I'd want to cut it back down, and before you know it I'm inflicting the 3,124th custom markdown on the world. Reall…

I'd just like to be able to toggle javadoc, phpdoc, godoc visibility on and off entirely (not collapsed to a line, or a marker) just make them vanish until I summon them back. I find them distracting when I'm reading the code but I don't want them not to exist either. EDIT: Another thing I'd love to be able to do is 'tag' a variable with a synonym and have that appear next to it eveywhere. so $strCstAcctRec (I wish t…

I've used an IDE that was aware of doxygen comments. Seems like that's close to what you want. You could right click and it'd show you the comment. I loved that IDE and it's long gone.
Post reply on HN