8 ms·

That's not about being smart or not.. But about brevity and a bit of experience. I'd certainly recommend the first one, there's simply less stuff to parse, it'

by dusted 4y ago

That's not about being smart or not.. But about brevity and a bit of experience. I'd certainly recommend the first one, there's simply less stuff to parse, it's easier and quicker to read. x is a pair with key of type string and value of pair with key of type string and value of type string. The other one is overly verbose to read, it takes more effort to read and understand.. But it could have merit, for instance if you need to extract status into a variable of declared type later..

collyw 4y ago
Used to do a lot of Perl, which is a wonderful language for writing obfuscated code. If something is an advanced feature of the language and I felt the need to use it, I would ad a comment explaining what the code was doing.
- dusted 4y ago
  It's a good idea to write _what_ something does, especially when the algorithm seems very "generic". I'll a thousand times rather have // Create users from id's userList = theblackmagiconeliner; Than a 20 line version of it where I'm left having to read through it to determine "oh, it made users from a list of id's" or even just.. having to read through it to find out if there's other stuff plugged in because "it could go there" or even just finding where it ends and actual work starts. userList = userListFromUserIdList(userIds); is also perfectly acceptable, but if it's only used once in that file, I'd prefer the blackmagiconeliner.. If it's only used once in the project, I'd also prefer that to having another file just for that function. Just do the work and get on with it.
  - stirfish 4y ago
    Put the 20 line version in a properly named function, even if it's only used once. There are two reasons for this: 1. You're probably doing something else where you don't want to stop and decipher a magic one-liner. That comment is a great name for that function. 2. Now that you have a function, write a test. Now that you have a test, your coworkers won't be tempted to tuck extra stuff in that function, because everyone hates editing tests.
    - dusted 4y ago
      I'd prefer the single line magic one. Exactly because now.. what used to be a menial computation required to get from A to B, has become a Thing, its existence has been justified not just by the declaration of a named function, but it has been blessed by the allocation of holy inodes and filesystem entries and versioning control entries, and oh god no, now it's been promoted to "actually important piece of infrastructure" by the greasy hand of a unit test. It has become a goal in and of itself.. What used to be a worthless piece of "I have Id's I need user objects"-getting-it-to-work has ascended and become immortal. Hours of work will now replace minutes, it adds drag to the entire system, not just in code size and bulk, but in developer mindshare, it exists and must therefore be considered and payed some amount of respect. It is painless to delete a single line of "doing stuff" when refactoring something.. But alas, in the end, the function call is deleted, but it lives on, either unreferenced or shows its ugly face in other parts of the code, now mutilated and mutated to support "that thing that sounds like what it did but not quite".. No, flamethrowers alight! Kill it with fire! Let it never be born. And I'm actually very much in favor of DRY. But that mainly is about repetition, not about spawning as much "structure for the sake of structure" as possible.
      - stirfish 4y ago
        That single line of magic is still a Thing, just a thing without a name or any way to check that you didn't make a mistake in writing it. If this magic single line is a map over a list, that's fine - but I've seen some deeply unholy one-liners. Like, 600 characters for no reason. Don't do that!
    - collyw 4y ago
      Single one liners tend to be quite functional in style and can avoid a lot of side effects that you might get with a 20 liner in a function.
      - stirfish 4y ago
        That's fine, you can do that. I was thinking more about, for example, nested list comprehensions squeezed onto one line.
- chasil 4y ago
  Most of my coworkers are Java and .NET developers. When we have to get down to the C, lately I've thrown away everything they try to migrate, and write something more sensible. There really isn't any reason to add comments to this code. No one will ever read such commentary while I am employed. It does me no benefit, so I stopped.
pivo 4y ago
The first implementation is bad. It’s less stuff to type, but if you’re parsing it, you’re trying to understand it, and the second implementation makes the meaning clear while the first implementation is mostly meaningless. Code is written once but read many times. Be kind to your readers, which includes yourself in the future.
- dusted 4y ago
  I strongly disagree. My comment was from my immediate experience parsing what he wrote right there and then. The first one is easy to read and quick to understand, the second on is already like "oh god, now comes a bunch of stuff" and then "okay, he declares that, it's this.. fine" "Okay, he declared this thing and then the other thing is part of that, yeah" and finally "oh, okay he wanted a variable named X with a pair<string, pair<string,string>> geesh fuck just get to the point already!" Like, seriously, it's like the analogy with the little kid explaining every little thing in excruciating detail, actually managing to make it sound like something is happening while nothing's happening.. Don't talk up this giant thing and tell me what you want to tell me.
  - phailhaus 4y ago
    > The first one is easy to read and quick to understand No it's not. Let's look at it again: val x: Pair<String, Pair<String, String>> What does x represent? You don't know. Actually, there's no way for you to know what the person writing this code meant when they defined this variable. Sure, you know its structure, but how is it meant to be used in the context of the application? This is one difference between junior and more experienced engineers. Junior engineers know what they meant when they wrote the code, but often forget to consider their teammates or future selves.
    - ethanwillis 4y ago
      The difference is that self-documenting code is bad. Code isn't documentation for humans. Documentation is documentation for humans. One comment right above this that gives a direct example of what x "is", is easier to understand. And then the structure of this line is also easier to understand more quickly than the second example. Is this bad? // A tuple defining an item with a status. (item-name (status-key status-value)) val x: Pair<String, Pair<String, String>> But even knowing what x "is" either with documentation or with verbose "self-documenting code" it still doesn't answer your question of "how this code should be used in the context of the application" Do we save x somewhere? Do we fetch something from somewhere else based on status-key? None of this is known. You get that from description, you get that from surrounding context. Except if we write all of our code like the second example then when we start reading the surrounding context it's going to be more painful. We're hiding the structure with extra verbosity in the pursuit of not having to write documentation or use the best tool we have for communicating with other humans... natural language.

by dusted 4y ago

collyw 4y ago

Used to do a lot of Perl, which is a wonderful language for writing obfuscated code. If something is an advanced feature of the language and I felt the need to use it, I would ad a comment explaining what the code was doing.

dusted 4y ago
It's a good idea to write _what_ something does, especially when the algorithm seems very "generic". I'll a thousand times rather have // Create users from id's userList = theblackmagiconeliner; Than a 20 line version of it where I'm left having to read through it to determine "oh, it made users from a list of id's" or even just.. having to read through it to find out if there's other stuff plugged in because "it could go there" or even just finding where it ends and actual work starts. userList = userListFromUserIdList(userIds); is also perfectly acceptable, but if it's only used once in that file, I'd prefer the blackmagiconeliner.. If it's only used once in the project, I'd also prefer that to having another file just for that function. Just do the work and get on with it.
- stirfish 4y ago
  Put the 20 line version in a properly named function, even if it's only used once. There are two reasons for this: 1. You're probably doing something else where you don't want to stop and decipher a magic one-liner. That comment is a great name for that function. 2. Now that you have a function, write a test. Now that you have a test, your coworkers won't be tempted to tuck extra stuff in that function, because everyone hates editing tests.
  - dusted 4y ago
    I'd prefer the single line magic one. Exactly because now.. what used to be a menial computation required to get from A to B, has become a Thing, its existence has been justified not just by the declaration of a named function, but it has been blessed by the allocation of holy inodes and filesystem entries and versioning control entries, and oh god no, now it's been promoted to "actually important piece of infrastructure" by the greasy hand of a unit test. It has become a goal in and of itself.. What used to be a worthless piece of "I have Id's I need user objects"-getting-it-to-work has ascended and become immortal. Hours of work will now replace minutes, it adds drag to the entire system, not just in code size and bulk, but in developer mindshare, it exists and must therefore be considered and payed some amount of respect. It is painless to delete a single line of "doing stuff" when refactoring something.. But alas, in the end, the function call is deleted, but it lives on, either unreferenced or shows its ugly face in other parts of the code, now mutilated and mutated to support "that thing that sounds like what it did but not quite".. No, flamethrowers alight! Kill it with fire! Let it never be born. And I'm actually very much in favor of DRY. But that mainly is about repetition, not about spawning as much "structure for the sake of structure" as possible.
    - stirfish 4y ago
      That single line of magic is still a Thing, just a thing without a name or any way to check that you didn't make a mistake in writing it. If this magic single line is a map over a list, that's fine - but I've seen some deeply unholy one-liners. Like, 600 characters for no reason. Don't do that!
  - collyw 4y ago
    Single one liners tend to be quite functional in style and can avoid a lot of side effects that you might get with a 20 liner in a function.
    - stirfish 4y ago
      That's fine, you can do that. I was thinking more about, for example, nested list comprehensions squeezed onto one line.
chasil 4y ago
Most of my coworkers are Java and .NET developers. When we have to get down to the C, lately I've thrown away everything they try to migrate, and write something more sensible. There really isn't any reason to add comments to this code. No one will ever read such commentary while I am employed. It does me no benefit, so I stopped.

pivo 4y ago

The first implementation is bad. It’s less stuff to type, but if you’re parsing it, you’re trying to understand it, and the second implementation makes the meaning clear while the first implementation is mostly meaningless. Code is written once but read many times. Be kind to your readers, which includes yourself in the future.

dusted 4y ago
I strongly disagree. My comment was from my immediate experience parsing what he wrote right there and then. The first one is easy to read and quick to understand, the second on is already like "oh god, now comes a bunch of stuff" and then "okay, he declares that, it's this.. fine" "Okay, he declared this thing and then the other thing is part of that, yeah" and finally "oh, okay he wanted a variable named X with a pair<string, pair<string,string>> geesh fuck just get to the point already!" Like, seriously, it's like the analogy with the little kid explaining every little thing in excruciating detail, actually managing to make it sound like something is happening while nothing's happening.. Don't talk up this giant thing and tell me what you want to tell me.
- phailhaus 4y ago
  > The first one is easy to read and quick to understand No it's not. Let's look at it again: val x: Pair<String, Pair<String, String>> What does x represent? You don't know. Actually, there's no way for you to know what the person writing this code meant when they defined this variable. Sure, you know its structure, but how is it meant to be used in the context of the application? This is one difference between junior and more experienced engineers. Junior engineers know what they meant when they wrote the code, but often forget to consider their teammates or future selves.
  - ethanwillis 4y ago
    The difference is that self-documenting code is bad. Code isn't documentation for humans. Documentation is documentation for humans. One comment right above this that gives a direct example of what x "is", is easier to understand. And then the structure of this line is also easier to understand more quickly than the second example. Is this bad? // A tuple defining an item with a status. (item-name (status-key status-value)) val x: Pair<String, Pair<String, String>> But even knowing what x "is" either with documentation or with verbose "self-documenting code" it still doesn't answer your question of "how this code should be used in the context of the application" Do we save x somewhere? Do we fetch something from somewhere else based on status-key? None of this is known. You get that from description, you get that from surrounding context. Except if we write all of our code like the second example then when we start reading the surrounding context it's going to be more painful. We're hiding the structure with extra verbosity in the pursuit of not having to write documentation or use the best tool we have for communicating with other humans... natural language.