3 ms·

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 'reconnec

by 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.

by geodel 9y ago

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.