5 ms·

I just did this grep for single-character function names on the Mako codebase: grep -r '\<[a-z](' . And there were no matches. There were some one-charact

I just did this grep for single-character function names on the Mako codebase: grep -r '\<[a-z](' . And there were no matches. There were some one-character macros but they were macros repeated dozens of times in a localized area. It seems like what's being proposed is descriptive function names with simple variable names. If the function bodies are short enough (e.g. fit on a single screen) then this seems like a good trade-off to me. IOW, the variable names are symbolic but the function names are descriptive. The short variable names should be clear enough if you understand the purpose of the function.

jrop 5y ago
"Clean code reads like prose" (Uncle Bob C. Martin) This is quickly becoming my goto standard for measuring how clean my code is, and in my case this means ultra-descriptive variable names. I usually code in two passes: first rough things out using single-character/short names, and then go back and use LSP features to rename the variables using the language-aware tools in any modern code editor.
smt88 5y ago
> The short variable names should be clear enough if you understand the purpose of the function. I shouldn't have to read the function implementation to understand its purpose. Code is buggy! If the function has no name or comment explaining what it's supposed to do, I only have the (often buggy) implementation to go by. There is no reason to use terse, non-descriptive names in 2021. It's an awful practice that guarantees easy-to-avoid bugs.
- matvore 5y ago
  I am saying you indeed should have descriptive function names. I also agree that if the function's name leaves something to be desired then it should be commented. You are conflating function names--global and relatively non-contextual--with variable names--which have limited scope and rely on the function name for their meaning. In the setColor example, I would use setColor for the function name and c for the parameter name (with the caveat that C language doesn't have method names, so my reasoning about context has limited applicability to non-C languages)

jrop 5y ago

"Clean code reads like prose" (Uncle Bob C. Martin) This is quickly becoming my goto standard for measuring how clean my code is, and in my case this means ultra-descriptive variable names. I usually code in two passes: first rough things out using single-character/short names, and then go back and use LSP features to rename the variables using the language-aware tools in any modern code editor.

smt88 5y ago

> The short variable names should be clear enough if you understand the purpose of the function. I shouldn't have to read the function implementation to understand its purpose. Code is buggy! If the function has no name or comment explaining what it's supposed to do, I only have the (often buggy) implementation to go by. There is no reason to use terse, non-descriptive names in 2021. It's an awful practice that guarantees easy-to-avoid bugs.

matvore 5y ago
I am saying you indeed should have descriptive function names. I also agree that if the function's name leaves something to be desired then it should be commented. You are conflating function names--global and relatively non-contextual--with variable names--which have limited scope and rely on the function name for their meaning. In the setColor example, I would use setColor for the function name and c for the parameter name (with the caveat that C language doesn't have method names, so my reasoning about context has limited applicability to non-C languages)