mleku on Nostr: i think they have some section on this in the main everyone-must-read #golang text, i ...

i think they have some section on this in the main everyone-must-read #golang text, i forget what it is called just now, but you'll find it somewhere

the length of variable names should relate to how big is the scope

if you have a loop with like <10 lines of code it is insane to put more than a few letters when the heading of the iterator shows you what they are

if it lives inside a long function, its name should remind you what it is for

if it is a package scope variable, make use of the package's name to add extra nuance when importing the package - eg tags.NewWithCap(c int) to generate and allocate a tags list with a prescribed capacity (unused but ready to use array elements pre-allocated) - same rule applies to functions also, in Go they are first class and you can declare functions and constants within any scope including inside a for or if/else block

and in my opinion, if your loop is more than 10 lines long you probably need to unfold some of it into functions so it is under 10 lines long

there is some contention also about named parameters in Go, a lot of guys are like "i hate naked returns" - this is where you give the return tuple variables name, so you can assign to them and not name them when you terminate execution using 'return' - my view is that, again, if the function doesn't even take up half a screenful why should you duplicate the information when you only want to assign a value to either the answer or the error value, then you just put a nice clean "return" line and done

and again, if your functions are taking up that much space you have to keep all these things repeatedly in context or longer specific mnemonics you probably have written a complex bitch of a function that will be a nightmare to change and debug anyway, so it's a moot point in my view

short functions, short loops, useful, meaningful abstractions that reflect the purpose

but i'm a bit weird like that