9 ms·

Look, do suggest whatever you want, but if I'm maintaining an important codebase, I'll reject BS like: - features without tests - extraLongNamesJustBecauseYou

by danwee 3y ago

Look, do suggest whatever you want, but if I'm maintaining an important codebase, I'll reject BS like: - features without tests - extraLongNamesJustBecauseYouHaveWorkedTheLastTenYearsInAJavaShop - domain logic in my "Http controllers" - domain logic in my "DAOs" - copy-pasted regexes that you cannot explain - adding 4 unmaintained dependencies from em-pee-em instead of writing the "algorithm" directly (which is at most 50 LOC) - non-deterministic systems commiting to master I know, humans are non-deterministic, but at least they dare to say "You were right. I don't know what I was thinking" when you point out their mistakes (if they don't say that, that's on you: they were a bad hire)

vorpalhex 3y ago
It's a sign of significant inexperience to be locked into a singular way of doing things and to have such hard rules. The goal is to achieve the end, not enforce a particular style. If long descriptive variable names work for your project, use them. If they don't work, don't use them. If you have to live by such fixed rules, you won't be a very useful developer.
- sanderjd 3y ago
  Agree with your general point, but I think this specific set of rules (maybe besides the function name length thing) read like experience rather than inexperience. I think this is a list of stuff that all seems fine at first, but has eventually burned anyone who has been doing the job long enough.
  - SebastianKra 3y ago
    Assuming you only maintain a single API, why is domain logic in http controllers so bad? - you have twice as many signatures to maintain, which will become inconsistent with each other - introducing a new layer when you eventually need it, isn't more work than maintaining it now - Unlike other IO, REST frameworks are easy to test in memory
    - sanderjd 3y ago
      Yeah I think it's really a good example of what I'm talking about. This is exactly the kind of thing that burns everyone eventually after they've done the job long enough, but which requires spilling a bunch of ink to describe why, which won't even work, because you just haven't been burned by it yet. And that's fine, this is just what accumulating experience is about. (And to make it worse, everyone's accumulated experience is different.)
      - SebastianKra 3y ago
        If you find a way to share what I should watch out for, I'd appreciate it :)
        sanderjd 3y ago
        I mean, this particular thing is covered in various books and other kinds of "best practice" documentation. There isn't a particular reason why I, as a random commenter on HN, would be able to make a more convincing case for it. But it's also reasonable to question the stuff it says in books and best practices documentation - nobody wants to cargo cult everything, and a lot of what's been written is not right in my view - so to some extent I feel like people just have to get burned by things in order to internalize why certain advice is good. I don't find that answer satisfying, but I've been on both sides of it over and over again throughout my career, and this is as far as I've gotten toward a conclusion.
      - vorpalhex 3y ago
        This is the poor sort of experience that leads to arbitrary rules without understanding. It is always about the comprehension of the end, not the form. These don't always burn everyone. Sometimes these are the right thing. They may not be the right thing at your shop, but the world of software is not just your little software. Long method names can lead to better, more readable testing and code. They can also be easier to mistype or be harder for non-native English speakers. Combining routing and logic can be very fast and easy, but can lead to hard to debug issues with sprawling projects. But not all projects are sprawling. If you think you are experienced and also buy deeply into any fixed rules, then the first claim is false.
- danwee 3y ago
  I thought it was clear, but perhaps my English is not at that level yet. All the bullet points except the last one were more or less tongue in cheek. Sure, long names are required some times, just like super short names have their place as well.
- avgcorrection 3y ago
  This is true if you get pull requests from people since there is a certain limit to how many of those you can get. However if you get pull requests from robots then you might eventually want to set down some rigid rules. Who has time to argue with the 36ths LLM contributor of the day? As eloquent as they might be. ;)
awelxtr 3y ago
What's wrong with the long names. Or more importantl, at what point a name is too long?
- klibertp 3y ago
  When more than half of the words could be removed without losing much meaning, that's too long. And believe me, people actually write those. It's horrible. It's like those science guys who name every single variable x, but in reverse.
  - godelski 3y ago
    I always think variables should be the minimal meaningfully unique identifier. We don't want to obscurificate code but we also want it to be readable. It's why we have style guides in the first place.
- smt88 3y ago
  Nothing is wrong with long names. Long names are good and serve as self-documentation. Some people are mad about that typing extra characters because they don't use their IDE properly to avoid it.
  - vikingerik 3y ago
    The problem isn't about typing it, it's about readability, when the length starts to interfere with reading comprehension for maintainability. With more than three or four words, the brain can't easily tokenize it into a single unit or distinguish between similar phrases, and it starts to take a lot of extra mental processing time to scan and parse it all.
    - klibertp 3y ago
      You can cheat with underscores, though. Said another way, you can trick your brain into tokenizing the looooong input by using, as a convention, some kinds of separators. In Elisp, you'll see names-that::have-_a_field_name+in-it. (Because of lack of namespacing and loose syntax rules for identifiers). Even if you do, though, a bad long name is still bad (one with 50% words to be removed without losing the meaning). Because you loose time on sifting through irrelevant or redundant information. At some point, you'll remember and learn to recognize the whole symbol, or a distinct part of it. Until that happens, though, you need to actually read, not just look, to know what's going on. It's slow, like a cache miss, and can be slowed down further by both not enough information, and too much information.
godelski 3y ago
> I know, humans are non-deterministic, but at least they dare to say "You were right. I don't know what I was thinking" when you point out their mistakes (if they don't say that, that's on you: they were a bad hire) Underappreciated sentiment right here. I can work with anyone that I can correct or can correct me without yelling or will at least point me in the right direction to understand their viewpoint (as opposed to "just because"). I've always seen it as a red flag when someone says they don't need people skills because their work should stand on its own (never met someone like that that also has an impressive resume). We have to work together. That's been a major reason for the success of humans. Cliche or not, it is underappreciated and I feel like it is becoming more so. (Despite this, I still don't like open office settings. That's an over correction)

by danwee 3y ago

vorpalhex 3y ago

It's a sign of significant inexperience to be locked into a singular way of doing things and to have such hard rules. The goal is to achieve the end, not enforce a particular style. If long descriptive variable names work for your project, use them. If they don't work, don't use them. If you have to live by such fixed rules, you won't be a very useful developer.

sanderjd 3y ago
Agree with your general point, but I think this specific set of rules (maybe besides the function name length thing) read like experience rather than inexperience. I think this is a list of stuff that all seems fine at first, but has eventually burned anyone who has been doing the job long enough.
- SebastianKra 3y ago
  Assuming you only maintain a single API, why is domain logic in http controllers so bad? - you have twice as many signatures to maintain, which will become inconsistent with each other - introducing a new layer when you eventually need it, isn't more work than maintaining it now - Unlike other IO, REST frameworks are easy to test in memory
  - sanderjd 3y ago
    Yeah I think it's really a good example of what I'm talking about. This is exactly the kind of thing that burns everyone eventually after they've done the job long enough, but which requires spilling a bunch of ink to describe why, which won't even work, because you just haven't been burned by it yet. And that's fine, this is just what accumulating experience is about. (And to make it worse, everyone's accumulated experience is different.)
    - SebastianKra 3y ago
      If you find a way to share what I should watch out for, I'd appreciate it :)
      - sanderjd 3y ago
        I mean, this particular thing is covered in various books and other kinds of "best practice" documentation. There isn't a particular reason why I, as a random commenter on HN, would be able to make a more convincing case for it. But it's also reasonable to question the stuff it says in books and best practices documentation - nobody wants to cargo cult everything, and a lot of what's been written is not right in my view - so to some extent I feel like people just have to get burned by things in order to internalize why certain advice is good. I don't find that answer satisfying, but I've been on both sides of it over and over again throughout my career, and this is as far as I've gotten toward a conclusion.
    - vorpalhex 3y ago
      This is the poor sort of experience that leads to arbitrary rules without understanding. It is always about the comprehension of the end, not the form. These don't always burn everyone. Sometimes these are the right thing. They may not be the right thing at your shop, but the world of software is not just your little software. Long method names can lead to better, more readable testing and code. They can also be easier to mistype or be harder for non-native English speakers. Combining routing and logic can be very fast and easy, but can lead to hard to debug issues with sprawling projects. But not all projects are sprawling. If you think you are experienced and also buy deeply into any fixed rules, then the first claim is false.
danwee 3y ago
I thought it was clear, but perhaps my English is not at that level yet. All the bullet points except the last one were more or less tongue in cheek. Sure, long names are required some times, just like super short names have their place as well.
avgcorrection 3y ago
This is true if you get pull requests from people since there is a certain limit to how many of those you can get. However if you get pull requests from robots then you might eventually want to set down some rigid rules. Who has time to argue with the 36ths LLM contributor of the day? As eloquent as they might be. ;)

awelxtr 3y ago

What's wrong with the long names. Or more importantl, at what point a name is too long?

klibertp 3y ago
When more than half of the words could be removed without losing much meaning, that's too long. And believe me, people actually write those. It's horrible. It's like those science guys who name every single variable x, but in reverse.
- godelski 3y ago
  I always think variables should be the minimal meaningfully unique identifier. We don't want to obscurificate code but we also want it to be readable. It's why we have style guides in the first place.
smt88 3y ago
Nothing is wrong with long names. Long names are good and serve as self-documentation. Some people are mad about that typing extra characters because they don't use their IDE properly to avoid it.
- vikingerik 3y ago
  The problem isn't about typing it, it's about readability, when the length starts to interfere with reading comprehension for maintainability. With more than three or four words, the brain can't easily tokenize it into a single unit or distinguish between similar phrases, and it starts to take a lot of extra mental processing time to scan and parse it all.
  - klibertp 3y ago
    You can cheat with underscores, though. Said another way, you can trick your brain into tokenizing the looooong input by using, as a convention, some kinds of separators. In Elisp, you'll see names-that::have-_a_field_name+in-it. (Because of lack of namespacing and loose syntax rules for identifiers). Even if you do, though, a bad long name is still bad (one with 50% words to be removed without losing the meaning). Because you loose time on sifting through irrelevant or redundant information. At some point, you'll remember and learn to recognize the whole symbol, or a distinct part of it. Until that happens, though, you need to actually read, not just look, to know what's going on. It's slow, like a cache miss, and can be slowed down further by both not enough information, and too much information.

godelski 3y ago

> I know, humans are non-deterministic, but at least they dare to say "You were right. I don't know what I was thinking" when you point out their mistakes (if they don't say that, that's on you: they were a bad hire) Underappreciated sentiment right here. I can work with anyone that I can correct or can correct me without yelling or will at least point me in the right direction to understand their viewpoint (as opposed to "just because"). I've always seen it as a red flag when someone says they don't need people skills because their work should stand on its own (never met someone like that that also has an impressive resume). We have to work together. That's been a major reason for the success of humans. Cliche or not, it is underappreciated and I feel like it is becoming more so. (Despite this, I still don't like open office settings. That's an over correction)