5 ms·

Why does it matter what things are called if the name of the thing might be a lie anyway? I'm going to have to check what it does anyway! I've adopted what I c

by geocar 7y ago

Why does it matter what things are called if the name of the thing might be a lie anyway? I'm going to have to check what it does anyway! I've adopted what I call the square rule (I've never heard it called anything else): The length of the name is the inverse of the square of the extent, and the frequency of its use. Thusly, a short name like "i" might be acceptable if the number of source code bytes between all the users of the variable are small, such as: {int k=0,i=0;for(;i<500;++i)if(do_something(i))++k;return k;} or if the variable is used almost everywhere in the program: I might have: register int*G asm("r12"); and be okay with it if nearly every function in my program is using G in some way. If you've heard of a similar rule to "huffman-code" your variable names, you can imagine I've simply adopted a dictionary selection strategy. That works for me, but in a large program it breaks down, because a large program may have multiple names for the same operation, and with multiple programmers (even following this rule) it may be difficult to predict the names chosen by other people on the team. That leads to code bloat, because programmers will often invent similar utilities (but for different purposes) with different names. I'm working with a guy at the moment who is fastidious about naming. He's the naming czar in this project, and almost nearly every function in this application has had its name blessed by him, so they're unusually consistent, to the point whilst I can't quite predict what something might have been called when searching to see if someone has already written a function I might like to use, I can ask him what something should be called and if it exists it will certainly have that name. That's cool! That's also a bit of a new/interesting experience for me, and even though I see some value in it, it doesn't scale, and I don't know how to replicate it. I would see value in a book that can teach how to name things that need good names, that team members who can carefully follow the strategy can end up with consistent names so we can find each others hard work faster, so I hope this book (the author is describing) addresses this point, instead of the inverse: crappo-drivel about predicting a functions' (or definitions') implementation from its name, something I see a lot of bloggers wax on about, but has negative value to me.

croo 7y ago
I found the CleanCode book suggestions good enough for naming conventions: Variable name length should be proportional to its scope. Only used in the next three lines? "i" is good enough. Is it a public field? Then its name should be long enough to be descriptive. Functions are somewhat the inverse of variables - private functions called once or twice should have long descriptive names, public functions / api calls should be short descriptive names. This way I can always tell by glance what goes on under the hood if I ever have to peek. Contrary to parent comment I found it absolutely unacceptable to call a function "asm". A few more characters costs literally nothing and it helps communicate intent to other programmers or future self. Even if the name itself become a lie the intent will remain true and will tell stories about what the original tought process was.
- geocar 7y ago
  > Contrary to parent comment I found it absolutely unacceptable to call a function "asm". You can take your snark up with GCC, and leave me out of it: https://gcc.gnu.org/onlinedocs/gcc/Global-Register-Variables.html https://gcc.gnu.org/onlinedocs/gcc/Global-Register-Variables...
  - quelltext 7y ago
    I think they may have simple misunderstood what your example was about (G, not asm(...)). On the other hand their criticism contradicts their earlier point about widely used public/stdlib function names best having short names.
    - marcosdumay 7y ago
      Widely used libraries have one more constraint, in that they will always be used a lot, but they'll never be the most used things on any code base. As a consequence, they shouldn't use very short names. They should let the 1-3 letter names available for local code. (But there are exceptions, of course. There always are.)
- simiones 7y ago
  You misunderstood the parent code snippet, even if your statement will still stand. "asm" is a GCC intrinsic for inline assembly code. The name he was pointing to was "G" - that is, in the entire program, the variable G is used to mean a pointer to processor register r12 I believe.
  - croo 7y ago
    Yeah I misunderstood it. I never wrote a single inline assembly code in C in my life so that probably flew over my head but I hope my general message is clear: don't use less letter than whats needed to be understandable and descriptive. If every C programmer thinks the same when he sees 'asm' then its great. If you have to go into the function body to find out "what the fuck is 'asm'" then its definetly not and your function name is bad and you should feel bad. Thats the message. Like... 'eval' instead of 'evaluate' is probably fine as everyone understands it (though I would vote for the latter). 'evaluate_code' is just additional noise without entropy. 'umount' or 'passwd' or 'usr' gets a sad head shake from me every time. Or function names with numbering in it. These things are just terrible.
kstenerud 7y ago
> Why does it matter what things are called if the name of the thing might be a lie anyway? It matters because the names you choose signal your intent. As Knuth put it: "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." A line of code is going to be read hundreds or thousands of times more often than it is written. The more someone has to scan around to discover the purpose or intent of something, the harder/slower your code is to navigate. And this magnifies by the thousands of times it gets read by humans. Code has UX, just like all human interfaces have UX. We've already discovered that better UX is a good thing. Code is just another user interface to optimize for discovery.
- taneq 7y ago
  > As Knuth put it: "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." I've never heard that one before but it's brilliant. That second sentence should be the opening sentence of every introductory programming course.
  - geocar 7y ago
    Knuth's approach to code is quite remarkable and also rather unique. Here's one of his most famous programs in source code form: http://anorien.csc.warwick.ac.uk/mirrors/CTAN/systems/knuth/dist/tex/tex.web http://anorien.csc.warwick.ac.uk/mirrors/CTAN/systems/knuth/... Yes that's right, 1mb of source code text, all in one file. If you haven't had the pleasure of a well-considered literate program, it might be funny to hear that I'd actually prefer this to a lot of shit I have had to deal with in my life...
    - EliRivers 7y ago
      A well-written literate program is a joy to work with. To be able to genuinely understand a complex program's design by reading well-written prose which forms part of the source code. Literally reading code like a book, finding that it effectively has a plot and characters with understandable motivations, properly introduced and their places and relationships clearly understood. Done right, it can work so well. The only software I ever worked on in which the customer never reported a single bug was written entirely in literate code. The software I work on now is so much at the other end of the scale that sometimes when the customer reports something, there is a signficant period of investigation before deciding if it's a bug or if that's how it's meant to work.
jjeaff 7y ago
I haven't looked much if this exists, but a name generator script would be very handy. Ask for a couple of parameters, what does it do, what does it affect, etc. And then it spits out a name. Would be a great ide extension and could have a config file that checks into the source code to help keep things consistent.
- geocar 7y ago
  I would love to have a mechanical naming czar! I'm aware of https://hoogle.haskell.org/ https://hoogle.haskell.org/ which is kindof like that: You give it a type description and it tells you all the functions that have that type. Unfortunately, it's not actually that useful in my experience. I once saw a sublime text plugin that someone could insert a description of a function and it'd automatically pull in code snippets from stackoverflow. It was cute, but I have serious reservations for some of the code I've seen in stackoverflow. I imagine someone somewhere might have tried hooking up GPT-2 (or something) to a JIRA database of user stories and the diffs, and I'd be curious to know how that works.
- darkcha0s 7y ago
  You are seriously suggesting breaking my coding workflow, to open a popup just to give me a half-assed suggestion I will probably dismiss anyways? Visual studio wants your location
- throwaway15392 7y ago
  I think what would be more handy is a standardization of how APIs should be written across many different domains, to make modules more interoperable. The result of conceptualizing and abstracting different domains is in as much of a Wild West as it’s ever going to be today. This reminds me I wanted to research about the theory of marketplaces to understand better how can we improve the market of reusable software components. By that I mean improving the process that we actually use to find and use or create and distribute reusable software components.
temporama1 7y ago
People who couldn't care less: - your employer - your customers
- azangru 7y ago
  I bet our employers and especially our customers also don't care which programming languages we use, or which frameworks. But we, developers, care. That's enough.
andy_ppp 7y ago
If we can't agree what something means and keep these things up to date our software will become meaningless junk. There is agreement about short index names. I prefer to name things with intent and rename them when their usage changes.
jamesrcole 7y ago
> Why does it matter what things are called if the name of the thing might be a lie anyway? I'm going to have to check what it does anyway! Imagine a program where all the keywords and identifiers have been replaced with randomly generated strings.
- goblin89 7y ago
  Replacing all identifier names with random strings (perhaps excluding built-ins and third-party dependencies), and then having an outsider try and understand what the program does in under N minutes, could be such an interesting litmus test of how well a program is organized and structured beyond naming. (Which is not to say naming is unimportant, of course.)
Ensorceled 7y ago
> Why does it matter what things are called if the name of the thing might be a lie anyway? I'm going to have to check what it does anyway! If you think naming doesn't matter, why should I read the rest of your opinions on the subject of naming?
lloeki 7y ago
> I've adopted what I call the square rule (I've never heard it called anything else): The length of the name is the inverse of the square of the extent, and the frequency of its use. See Gerrand’s rule of thumb > The greater the distance between a name's declaration and its uses, the longer the name should be. https://talks.golang.org/2014/names.slide#4 https://talks.golang.org/2014/names.slide#4
viklove 7y ago
{int k=0,i=0;for(;i<500;++i)if(do_something(i))++k;return k;} This is an unreadable mess I would never let anyone on my team merge...

by geocar 7y ago

croo 7y ago

I found the CleanCode book suggestions good enough for naming conventions: Variable name length should be proportional to its scope. Only used in the next three lines? "i" is good enough. Is it a public field? Then its name should be long enough to be descriptive. Functions are somewhat the inverse of variables - private functions called once or twice should have long descriptive names, public functions / api calls should be short descriptive names. This way I can always tell by glance what goes on under the hood if I ever have to peek. Contrary to parent comment I found it absolutely unacceptable to call a function "asm". A few more characters costs literally nothing and it helps communicate intent to other programmers or future self. Even if the name itself become a lie the intent will remain true and will tell stories about what the original tought process was.

geocar 7y ago
> Contrary to parent comment I found it absolutely unacceptable to call a function "asm". You can take your snark up with GCC, and leave me out of it: https://gcc.gnu.org/onlinedocs/gcc/Global-Register-Variables.html https://gcc.gnu.org/onlinedocs/gcc/Global-Register-Variables...
- quelltext 7y ago
  I think they may have simple misunderstood what your example was about (G, not asm(...)). On the other hand their criticism contradicts their earlier point about widely used public/stdlib function names best having short names.
  - marcosdumay 7y ago
    Widely used libraries have one more constraint, in that they will always be used a lot, but they'll never be the most used things on any code base. As a consequence, they shouldn't use very short names. They should let the 1-3 letter names available for local code. (But there are exceptions, of course. There always are.)
simiones 7y ago
You misunderstood the parent code snippet, even if your statement will still stand. "asm" is a GCC intrinsic for inline assembly code. The name he was pointing to was "G" - that is, in the entire program, the variable G is used to mean a pointer to processor register r12 I believe.
- croo 7y ago
  Yeah I misunderstood it. I never wrote a single inline assembly code in C in my life so that probably flew over my head but I hope my general message is clear: don't use less letter than whats needed to be understandable and descriptive. If every C programmer thinks the same when he sees 'asm' then its great. If you have to go into the function body to find out "what the fuck is 'asm'" then its definetly not and your function name is bad and you should feel bad. Thats the message. Like... 'eval' instead of 'evaluate' is probably fine as everyone understands it (though I would vote for the latter). 'evaluate_code' is just additional noise without entropy. 'umount' or 'passwd' or 'usr' gets a sad head shake from me every time. Or function names with numbering in it. These things are just terrible.

kstenerud 7y ago

> Why does it matter what things are called if the name of the thing might be a lie anyway? It matters because the names you choose signal your intent. As Knuth put it: "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." A line of code is going to be read hundreds or thousands of times more often than it is written. The more someone has to scan around to discover the purpose or intent of something, the harder/slower your code is to navigate. And this magnifies by the thousands of times it gets read by humans. Code has UX, just like all human interfaces have UX. We've already discovered that better UX is a good thing. Code is just another user interface to optimize for discovery.

taneq 7y ago
> As Knuth put it: "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." I've never heard that one before but it's brilliant. That second sentence should be the opening sentence of every introductory programming course.
- geocar 7y ago
  Knuth's approach to code is quite remarkable and also rather unique. Here's one of his most famous programs in source code form: http://anorien.csc.warwick.ac.uk/mirrors/CTAN/systems/knuth/dist/tex/tex.web http://anorien.csc.warwick.ac.uk/mirrors/CTAN/systems/knuth/... Yes that's right, 1mb of source code text, all in one file. If you haven't had the pleasure of a well-considered literate program, it might be funny to hear that I'd actually prefer this to a lot of shit I have had to deal with in my life...
  - EliRivers 7y ago
    A well-written literate program is a joy to work with. To be able to genuinely understand a complex program's design by reading well-written prose which forms part of the source code. Literally reading code like a book, finding that it effectively has a plot and characters with understandable motivations, properly introduced and their places and relationships clearly understood. Done right, it can work so well. The only software I ever worked on in which the customer never reported a single bug was written entirely in literate code. The software I work on now is so much at the other end of the scale that sometimes when the customer reports something, there is a signficant period of investigation before deciding if it's a bug or if that's how it's meant to work.

jjeaff 7y ago

I haven't looked much if this exists, but a name generator script would be very handy. Ask for a couple of parameters, what does it do, what does it affect, etc. And then it spits out a name. Would be a great ide extension and could have a config file that checks into the source code to help keep things consistent.

geocar 7y ago
I would love to have a mechanical naming czar! I'm aware of https://hoogle.haskell.org/ https://hoogle.haskell.org/ which is kindof like that: You give it a type description and it tells you all the functions that have that type. Unfortunately, it's not actually that useful in my experience. I once saw a sublime text plugin that someone could insert a description of a function and it'd automatically pull in code snippets from stackoverflow. It was cute, but I have serious reservations for some of the code I've seen in stackoverflow. I imagine someone somewhere might have tried hooking up GPT-2 (or something) to a JIRA database of user stories and the diffs, and I'd be curious to know how that works.
darkcha0s 7y ago
You are seriously suggesting breaking my coding workflow, to open a popup just to give me a half-assed suggestion I will probably dismiss anyways? Visual studio wants your location
throwaway15392 7y ago
I think what would be more handy is a standardization of how APIs should be written across many different domains, to make modules more interoperable. The result of conceptualizing and abstracting different domains is in as much of a Wild West as it’s ever going to be today. This reminds me I wanted to research about the theory of marketplaces to understand better how can we improve the market of reusable software components. By that I mean improving the process that we actually use to find and use or create and distribute reusable software components.

temporama1 7y ago

People who couldn't care less: - your employer - your customers

azangru 7y ago
I bet our employers and especially our customers also don't care which programming languages we use, or which frameworks. But we, developers, care. That's enough.

andy_ppp 7y ago

If we can't agree what something means and keep these things up to date our software will become meaningless junk. There is agreement about short index names. I prefer to name things with intent and rename them when their usage changes.

jamesrcole 7y ago

> Why does it matter what things are called if the name of the thing might be a lie anyway? I'm going to have to check what it does anyway! Imagine a program where all the keywords and identifiers have been replaced with randomly generated strings.

goblin89 7y ago
Replacing all identifier names with random strings (perhaps excluding built-ins and third-party dependencies), and then having an outsider try and understand what the program does in under N minutes, could be such an interesting litmus test of how well a program is organized and structured beyond naming. (Which is not to say naming is unimportant, of course.)

Ensorceled 7y ago

> Why does it matter what things are called if the name of the thing might be a lie anyway? I'm going to have to check what it does anyway! If you think naming doesn't matter, why should I read the rest of your opinions on the subject of naming?

lloeki 7y ago

> I've adopted what I call the square rule (I've never heard it called anything else): The length of the name is the inverse of the square of the extent, and the frequency of its use. See Gerrand’s rule of thumb > The greater the distance between a name's declaration and its uses, the longer the name should be. https://talks.golang.org/2014/names.slide#4 https://talks.golang.org/2014/names.slide#4

viklove 7y ago

{int k=0,i=0;for(;i<500;++i)if(do_something(i))++k;return k;} This is an unreadable mess I would never let anyone on my team merge...