4 ms·

Quality readable code does not depend on these sorts of styles. As a matter of fact, you can write totally opaque code, in perfect style. I have seen this. If

Quality readable code does not depend on these sorts of styles. As a matter of fact, you can write totally opaque code, in perfect style. I have seen this. If using getOrElse in one function and using an if in another is confusing, I am very sorry: things differ, things change, and its best to just learn to read code.

anon291 3y ago
> If using getOrElse in one function and using an if in another is confusing, I am very sorry: things differ, things change, and its best to just learn to read code. When engineers tell me these sorts of style changes confuse them, I think lesser of them. It's probably not socially acceptable to say, but there it is.
- dionian 3y ago
  I tend to agree, although certainly, it would possibly be poor style to mix them together frequently in the same area in an egregious way
- parpfish 3y ago
  i don't think style-enforcers are 'confused' and unable to read code, it's that consistent style makes reading code a LOT easier. if the same thing is being done in two different ways, you have to actually read and think about the both chunks of code to see that they're the same. with consistent style you can essentially speed-read a codebase because things are predictable. with inconsistent style, you're constantly reading slightly-different pieces of code and figuring out "is this different purely for style reasons, or was there a reason that one section if different?"
  - jiggawatts 3y ago
    You speak of using a consistent, established pattern to improve comprehension, but you eschew the use of capital letters when writing English. Interesting.
    - parpfish 3y ago
      I also make sure to include typos. Just to be consistent with the rest of the internet.
- patrick451 3y ago
  You're not alone, I tend to think the same thing. I really don't notice a difference between reading my team's own code vs reading our dependencies code or other random open source projects. Despite the fact that none of these repos enforce the same style. My most charitable interpretation is that software development is filled with people who have a touch of OCD and all these inconsistencies affect them in ways I simply can't comprehend.
- IshKebab 3y ago
  You're just misunderstanding. They're not saying they literally can't understand the code if it has inconsistent style and formatting; they're saying it's more work. It's like reading a book with no paragraphs. Of course you can do it. Nobody is "confused" by the lack of paragraphs. But you're an idiot if you think paragraphs don't matter, or don't make reading easier. I tend to think less of people that don't understand this, or don't care.
  - bonesss 3y ago
    There's also the context to consider: if I'm scanning someone elses' code in an unfamiliar subsystem, there's a high chance there is a bug or something time critical. Not the time for extra annoyance and work. Finding code that suddenly zigs where all the rest of the systems code zags takes extra mental overhead. It's annoying, and misleading. All too frequently bugs are coupled to such style violations, adding extra frustration around such misleading code.
    - IshKebab 3y ago
      > All too frequently bugs are coupled to such style violations That's a really good point actually. Style violations can make the code look like it does something that it doesn't, `if (a=b)`, missing curly brackets in C/C++, missing semicolons in Javascript, mismatched brackets, etc. An autoformatter can make it more obvious when you've done something wrong.

anon291 3y ago

> If using getOrElse in one function and using an if in another is confusing, I am very sorry: things differ, things change, and its best to just learn to read code. When engineers tell me these sorts of style changes confuse them, I think lesser of them. It's probably not socially acceptable to say, but there it is.

dionian 3y ago
I tend to agree, although certainly, it would possibly be poor style to mix them together frequently in the same area in an egregious way
parpfish 3y ago
i don't think style-enforcers are 'confused' and unable to read code, it's that consistent style makes reading code a LOT easier. if the same thing is being done in two different ways, you have to actually read and think about the both chunks of code to see that they're the same. with consistent style you can essentially speed-read a codebase because things are predictable. with inconsistent style, you're constantly reading slightly-different pieces of code and figuring out "is this different purely for style reasons, or was there a reason that one section if different?"
- jiggawatts 3y ago
  You speak of using a consistent, established pattern to improve comprehension, but you eschew the use of capital letters when writing English. Interesting.
  - parpfish 3y ago
    I also make sure to include typos. Just to be consistent with the rest of the internet.
patrick451 3y ago
You're not alone, I tend to think the same thing. I really don't notice a difference between reading my team's own code vs reading our dependencies code or other random open source projects. Despite the fact that none of these repos enforce the same style. My most charitable interpretation is that software development is filled with people who have a touch of OCD and all these inconsistencies affect them in ways I simply can't comprehend.
IshKebab 3y ago
You're just misunderstanding. They're not saying they literally can't understand the code if it has inconsistent style and formatting; they're saying it's more work. It's like reading a book with no paragraphs. Of course you can do it. Nobody is "confused" by the lack of paragraphs. But you're an idiot if you think paragraphs don't matter, or don't make reading easier. I tend to think less of people that don't understand this, or don't care.
- bonesss 3y ago
  There's also the context to consider: if I'm scanning someone elses' code in an unfamiliar subsystem, there's a high chance there is a bug or something time critical. Not the time for extra annoyance and work. Finding code that suddenly zigs where all the rest of the systems code zags takes extra mental overhead. It's annoying, and misleading. All too frequently bugs are coupled to such style violations, adding extra frustration around such misleading code.
  - IshKebab 3y ago
    > All too frequently bugs are coupled to such style violations That's a really good point actually. Style violations can make the code look like it does something that it doesn't, `if (a=b)`, missing curly brackets in C/C++, missing semicolons in Javascript, mismatched brackets, etc. An autoformatter can make it more obvious when you've done something wrong.