3 ms·

> We need more languages that come with rigid rules for things like style, so we can stop wasting time and get on with solving problems. This is where I'm at n

> We need more languages that come with rigid rules for things like style, so we can stop wasting time and get on with solving problems. This is where I'm at now. Decades ago, I was an "only spaces, no tabs" guy. Still am to an extent. But what made me more open was realizing it wasn't spaces or tabs specifically that mattered, only that code is readable, and consistently formatted code is more readable. Seeing things like `gofmt`, which mix tabs and spaces, and comes with the language? Your debate about spaces versus tabs is over, now we can get back to tackling real problems, and your code will be rejected at CI if it isn't run through the standard formatter. Same thing with `black` for Python. Above all else, be consistent. I can understand hate for "standard" language libraries that have functions with wildly different naming schemes or input and output arguments that aren't consistent - those should DIAF (looking at you, PHP "standard" library). But as to the names themselves? Doesn't particularly matter much. Unless you're the Bruce Tognazzini of API design, you probably don't have anything of substance to back up why it should be "make_" versus "create_".

sdfghswe 3y ago
> Above all else, be consistent. Aren't you still doing the same thing though? You have your arbitrary rules and they're absolutely truths... until you change your mind about them. Except before the rule was "only space no tabs" and now it's "be consistent"?
- npsimons 3y ago
  Given how many people here are disagreeing except on "be consistent", I feel I'm in good company in having that as my rule. I'm not being inconsistent, I'm learning, growing and adapting. "Strong opinions, weakly held." But yes, "A foolish consistency is the hobgoblin of little minds." The question is, what is "foolish"? I'm arguing against things like `strpos` and `str_rot13`. I'm arguing against having similar functions where argument order is inconsistent. These are the sorts of things that slow developers down and force them to check the documentation every time just to make sure they aren't introducing bugs by default.
  - sdfghswe 3y ago
    > I feel I'm in good company in having that as my rule I'm sure you also felt in good company about tabs or not tabs or whatever it was you liked.
    - npsimons 3y ago
      Kindly cite a problem with admitting mistakes and growing and learning from them. Then explain how consistency is a bad thing.
      - sdfghswe 3y ago
        > Kindly cite a problem with admitting mistakes and growing and learning from them. Nothing against this. > Then explain how consistency is a bad thing. This is a really boring conversation, because if I give a good example you'll just define consistency for that example not to apply. For example, picking the token case of naming functions in such and such way, it occurs to me that I don't really care if you break rules are long it's done in a way that doesn't affect the interface. If something can be considered an implementation detail, I don't care that it doesn't follow the same rules, as long as the interface doesn't allow you to see it. But then you'll just say something like "oh but 'consistency' doesn't mean a rule applies under any and all circumstances, there's always caveats" bla bla bla. It's a boring conversation, my point is that you had a dogma, and now you have a different dogma. You think you're evolving, I think you're changing but not evolving in a bigger way.
Mawr 3y ago
Consistency is table stakes. It doesn't override the need for good decisions, it's just the baseline. A consistently applied bad decision is still a bad decision. Tabs vs spaces is a great example, since tabs are just better ( :) ). The attempts to control how others view the code are frankly bizarre. Why not go all the way and control the typeface, font size, and syntax highlighting by sharing code via screenshots? Let everyone choose their preferred indentation size, it's not only polite, but also an accessibility concern.

sdfghswe 3y ago

> Above all else, be consistent. Aren't you still doing the same thing though? You have your arbitrary rules and they're absolutely truths... until you change your mind about them. Except before the rule was "only space no tabs" and now it's "be consistent"?

npsimons 3y ago
Given how many people here are disagreeing except on "be consistent", I feel I'm in good company in having that as my rule. I'm not being inconsistent, I'm learning, growing and adapting. "Strong opinions, weakly held." But yes, "A foolish consistency is the hobgoblin of little minds." The question is, what is "foolish"? I'm arguing against things like `strpos` and `str_rot13`. I'm arguing against having similar functions where argument order is inconsistent. These are the sorts of things that slow developers down and force them to check the documentation every time just to make sure they aren't introducing bugs by default.
- sdfghswe 3y ago
  > I feel I'm in good company in having that as my rule I'm sure you also felt in good company about tabs or not tabs or whatever it was you liked.
  - npsimons 3y ago
    Kindly cite a problem with admitting mistakes and growing and learning from them. Then explain how consistency is a bad thing.
    - sdfghswe 3y ago
      > Kindly cite a problem with admitting mistakes and growing and learning from them. Nothing against this. > Then explain how consistency is a bad thing. This is a really boring conversation, because if I give a good example you'll just define consistency for that example not to apply. For example, picking the token case of naming functions in such and such way, it occurs to me that I don't really care if you break rules are long it's done in a way that doesn't affect the interface. If something can be considered an implementation detail, I don't care that it doesn't follow the same rules, as long as the interface doesn't allow you to see it. But then you'll just say something like "oh but 'consistency' doesn't mean a rule applies under any and all circumstances, there's always caveats" bla bla bla. It's a boring conversation, my point is that you had a dogma, and now you have a different dogma. You think you're evolving, I think you're changing but not evolving in a bigger way.

Mawr 3y ago

Consistency is table stakes. It doesn't override the need for good decisions, it's just the baseline. A consistently applied bad decision is still a bad decision. Tabs vs spaces is a great example, since tabs are just better ( :) ). The attempts to control how others view the code are frankly bizarre. Why not go all the way and control the typeface, font size, and syntax highlighting by sharing code via screenshots? Let everyone choose their preferred indentation size, it's not only polite, but also an accessibility concern.