5 ms·

I agree, and the link I posted states as much. I think the problem comes when people take that advice without nuance and think it gives them carte blanche to m

by adamkl 9y ago

I agree, and the link I posted states as much. I think the problem comes when people take that advice without nuance and think it gives them carte blanche to make everything as obscure as possible. And really, it’s not about whether or not we can understand our own code, but can the future developers who have to maintain it after we leave. I kinda worry that the Go community is creating a lot of unmaintainable code right now.

geodel 9y ago
I see an intrinsic pattern to variable naming in Go and not some randomly assigned single letters. I work on Java code where variables name look like 'reconnectDelayToInitiallyEstablishJMSConnection" Even though very clear name it really exhaust me while reading code like this. Java explicitness things like spreading code over dozens of files and directories for a functionality that could ideally be in 1-2 reasonably sized files. And methods that actually do something instead of calling another methods. So I guess code I deal with is understandable at a method level which finally does something. But overall it is too sprawling to fit everything in mind while looking at a functionality.
- adamkl 9y ago
  I would just argue for a happy median. Enough to convey intent, without being verbose. Your java example is clearly exhausingly verbose (I’ve seen similar in C#), where it seems in Go it would probably be written: rd := 1000 How is anyone supposed to understand at a glance what this value is for? Why not just: reconnectionDelay := 1000 Intent is clear. And now, I have strayed way too far off topic (I’ve done some flamegraph style debugging in .Net, super useful!), and should probably apologize to the OP.
  - crispinb 9y ago
    (to continue straying for a moment..) perhaps though it best depends on the variable specifics: like how often it appears, how far apart multiple uses are, etc. Some natural limits might be: (1) single letters for extremely local terms whose structural meaning is more salient than denotation (canonical example: loop counter); (2) fully spelled-out terms for globally-significant terms (not necessarily in global scope) whose denotation is crucial (canonical example: an app configuration value). Even two short camel-cased words often seem unnecessarily verbose for a loop counter to me. Whereas an important global config variable might justify the full THIS_IS_WHAT_I_AM_FOR treatment.
erik_seaberg 9y ago
Java went through a phase of not having inner classes, autoboxing, enums, generics, and looping over iterables. The code from that era was burned to the ground for being unreadable shit. This is survivable, if they're motivated to fix the glaring omissions in Go.

by adamkl 9y ago

geodel 9y ago

I see an intrinsic pattern to variable naming in Go and not some randomly assigned single letters. I work on Java code where variables name look like 'reconnectDelayToInitiallyEstablishJMSConnection" Even though very clear name it really exhaust me while reading code like this. Java explicitness things like spreading code over dozens of files and directories for a functionality that could ideally be in 1-2 reasonably sized files. And methods that actually do something instead of calling another methods. So I guess code I deal with is understandable at a method level which finally does something. But overall it is too sprawling to fit everything in mind while looking at a functionality.

adamkl 9y ago
I would just argue for a happy median. Enough to convey intent, without being verbose. Your java example is clearly exhausingly verbose (I’ve seen similar in C#), where it seems in Go it would probably be written: rd := 1000 How is anyone supposed to understand at a glance what this value is for? Why not just: reconnectionDelay := 1000 Intent is clear. And now, I have strayed way too far off topic (I’ve done some flamegraph style debugging in .Net, super useful!), and should probably apologize to the OP.
- crispinb 9y ago
  (to continue straying for a moment..) perhaps though it best depends on the variable specifics: like how often it appears, how far apart multiple uses are, etc. Some natural limits might be: (1) single letters for extremely local terms whose structural meaning is more salient than denotation (canonical example: loop counter); (2) fully spelled-out terms for globally-significant terms (not necessarily in global scope) whose denotation is crucial (canonical example: an app configuration value). Even two short camel-cased words often seem unnecessarily verbose for a loop counter to me. Whereas an important global config variable might justify the full THIS_IS_WHAT_I_AM_FOR treatment.

erik_seaberg 9y ago

Java went through a phase of not having inner classes, autoboxing, enums, generics, and looping over iterables. The code from that era was burned to the ground for being unreadable shit. This is survivable, if they're motivated to fix the glaring omissions in Go.