What is the meaning of OR?

PleegWat

@Parody Having a return halfway through a function makes it harder to scan what it is going to do. I generally make exceptions for error returns, but that's just because I primarily use a language without exceptions.

If you have a good reason to have a success return in the middle of the function (IE, there is significant work both before and after the potential return) then you should probably look at splitting the function.

Arantor

@PleegWat I tend to have successful early return if it turns out that there's no work to do after all, e.g. 'fetch a bunch of records from the database to operate on' but as long as 'nothing to do' isn't a failure state, successful early return shouldn't necessarily be grounds for splitting the function.

Will admit it's probably a good idea in a lot of cases though.

Gąska

@cvi said in What is the meaning of OR?:

: I then tend to put the operator on the new line.

Me too. It's much more readable to me when a line starts with "but wait there's more!" than when it ends with it. Unfortunately this style is impossible in many "modern" languages due to auto-semicolon.

Parody

@PleegWat said in What is the meaning of OR?:

If you have a good reason to have a success return in the middle of the function (IE, there is significant work both before and after the potential return) then you should probably look at splitting the function.

I've never had a problem with making more functions. :)

Gąska

@Parody according to one fairly popular coding coach, no function should have more than 3-4 lines. If you can split it, split it; and if it has 5 lines, you almost certainly can split it somehow. 6 is right out.

MrL

@Gąska said in What is the meaning of OR?:

@Parody according to one fairly popular coding coach, no function should have more than 3-4 lines. If you can split it, split it; and if it has 5 lines, you almost certainly can split it somehow. 6 is right out.

I worked at a company where his ideas were treated like gospel. It was a nightmare.
Luckily I'm not there anymore.

Benjamin Hall

@MrL said in What is the meaning of OR?:

ideas were treated like gospel

This is always a problem, no matter whose ideas are the lucky ones chosen for this status.

I've got an architect who likes to drink the koolaid.

Gąska

@MrL I worked at a company where we basically adopted "Uncle Bob: the Good Parts". Near-100% unit test coverage, a solid whole-program test suite on top of it, constant 10% man-hours allocated to refactorings, and using the standard design patterns wherever they make sense. Worked very well for us, and while there were plenty of WTFs in that project, they were almost entirely restricted to external services and other parts of code we weren't allowed to refactor.

The only downside of the constant refactorings was that we've had 5-6 concurrent versions to maintain (biannual releases with years of support each) and when a bugfix had to be made, we couldn't simply apply the code patch to all branches; we've had to implement it at least twice - in the new, nice way and in the old, ugly way. On the plus side, the bugs were pretty rare (especially compared to other projects in our department), and thanks to our test suites at least we knew for sure they're going to be the same bugs.

MrL

@Gąska said in What is the meaning of OR?:

@MrL I worked at a company where we basically adopted "Uncle Bob: the Good Parts". Near-100% unit test coverage, a solid whole-program test suite on top of it, constant 10% man-hours allocated to refactorings, and using the standard design patterns wherever they make sense.

Yes, pretty horrible stuff.

Gribnit

@Gąska said in What is the meaning of OR?:

@Parody according to one fairly popular coding coach, no function should have more than 3-4 lines. If you can split it, split it; and if it has 5 lines, you almost certainly can split it somehow. 6 is right out.

This isn't wrong, but it's not right enough - this assumes no assumable or useful couplings.

Gribnit

@Parody said in What is the meaning of OR?:

@PleegWat said in What is the meaning of OR?:

If you have a good reason to have a success return in the middle of the function (IE, there is significant work both before and after the potential return) then you should probably look at splitting the function.

I've never had a problem with making more functions. :)

It can be a problem if more than one thing you wanted dynamic ends up implemented statically.

Gąska

@MrL do you beat your wife for cooking a nice dinner too?

MrL

@Gąska said in What is the meaning of OR?:

@MrL do you beat your wife for cooking a nice dinner too?

If the way she cooked it disgusts me, sure.

Gąska

@MrL but why does a perfectly fine ~~dinner~~work methodology disgust you? Do you like being miserable, or what?

LaoC

@Arantor said in What is the meaning of OR?:

@cvi Don't get me started on && and || vs and and or (yes, PHP has both sets of operators, yes you can intermix them, but no you fucking shouldn't because operator precedence will absolutely bite your ass)

If it's anything like Perl's (and IIRC they got that part right), the two sets exist precisely because people have been bitten by operator precedence. You use and/or if you want the partial-evaluation behavior and &&/|| for boolean logic, so something like
$a = $b || $c and return works just like
$a = $b || $c or return.

MrL

@Gąska said in What is the meaning of OR?:

@MrL but why does a perfectly fine ~~dinner~~work methodology disgust you?

Because I tried it, it was horrible and therefore I don't consider it fine.
Yeah, I should elaborate, but I'm exhausted - maybe later.

Do you like being miserable, or what?

I'm still in IT, so that's quite obvious.

Gąska

@MrL said in What is the meaning of OR?:

@Gąska said in What is the meaning of OR?:

@MrL but why does a perfectly fine ~~dinner~~work methodology disgust you?

Because I tried it, it was horrible and therefore I don't consider it fine.

The Uncle Bob way, or only the Good Parts while specifically excluding all the Bad Parts such as "write 4-line functions" and "dependency injection everywhere"?

Like really. You must be the first programmer I've ever met who doesn't like being able to refactor everything on a constant basis.

MrL

@Gąska said in What is the meaning of OR?:

@MrL said in What is the meaning of OR?:

@Gąska said in What is the meaning of OR?:

@MrL but why does a perfectly fine ~~dinner~~work methodology disgust you?

Because I tried it, it was horrible and therefore I don't consider it fine.

The Uncle Bob way, or only the Good Parts while specifically excluding all the Bad Parts such as "write 4-line functions" and "dependency injection everywhere"?

What you described. I have no idea what lands in what Bob parts.

Like really. You must be the first programmer I've ever met who doesn't like being able to refactor everything on a constant basis.

10% for refactoring is the only good part there. In principle at least.

Gąska

@MrL said in What is the meaning of OR?:

@Gąska said in What is the meaning of OR?:

@MrL said in What is the meaning of OR?:

@Gąska said in What is the meaning of OR?:

@MrL but why does a perfectly fine ~~dinner~~work methodology disgust you?

Because I tried it, it was horrible and therefore I don't consider it fine.

The Uncle Bob way, or only the Good Parts while specifically excluding all the Bad Parts such as "write 4-line functions" and "dependency injection everywhere"?

What you described. I have no idea what lands in what Bob parts.

The specific things I mentioned were good, everything else was mostly bad. And before you scoff at design patterns - I didn't mean using pattern for the sake of using patterns; I meant using standard implementations instead of reinventing the same wheel in a different way, so that other developers have easier time learning your codebase. As for test coverage, I've talked way too much about it already in the past and IIRC you remained unconvinced. Your loss.

Like really. You must be the first programmer I've ever met who doesn't like being able to refactor everything on a constant basis.

10% for refactoring is the only good part there. In principle at least.

In practice too. We didn't always refactor, but having that as a fixed part of every sprint avoided the whole problem of convincing the management every time we really need to refactor something.

LaoC

@Arantor said in What is the meaning of OR?:

@Gąska sure, for complex cases like that I'd tend to agree.

The example I gave was more representative of what code I'd actually seen. My former coworker would likely have written your sample more thusly:
var barBaz = Config.User.GetBar("baz");
var barBazShazams = barBaz.shazams;
var firstShazam = barBaz.shazams[0];
var shazamModifier = input.shazamModifier;
var fooFactor = firstShazam + shazamModifier;
var bestFoo = getBestFoo(input.foos);
var fooValue = bestFoo * fooFactor;

Real Programmers can write assembly code in any language.

MrL

@Gąska said in What is the meaning of OR?:

The specific things I mentioned were good, everything else was mostly bad. And before you scoff at design patterns - I didn't mean using pattern for the sake of using patterns; I meant using standard implementations instead of reinventing the same wheel in a different way, so that other developers have easier time learning your codebase.

That assumes that other developers know those design patterns and can easily recognize them.
Wouldn't work for me, for example.

As for test coverage, I've talked way too much about it already in the past and IIRC you remained unconvinced. Your loss.

Actually I'm quite convinced - that Tests are a religion. Or rather a cult. Huge waste of time, a lot of pointless motions and the only result is feeling good about oneself.
Source: working on projects with tens of thousands of tests.

Like really. You must be the first programmer I've ever met who doesn't like being able to refactor everything on a constant basis.

10% for refactoring is the only good part there. In principle at least.

In practice too. We didn't always refactor, but having that as a fixed part of every sprint avoided the whole problem of convincing the management every time we really need to refactor something.

Yeah, that's a big plus of such situation.
In one and only place where we managed to negotiate something like this, when there wasn't anything obvious to refactor, we used this time to gradually transform whole project to new design. It took a year (3 times actually), but we got to design that better suited changing requirements - it would never be possible to convince decision makers to do it in one go.

da Doctah

This may better belong in the Random Thought of the Day thread, but the dependence on the meaning of "OR" tells me it has business here as well.

One thing that lay people don't understand about the simplest sort of tech is that there are two kinds of "or" in the English language, exclusive and inclusive. And you can't get agreement on which is the default because people use both interchangeably:

"You may have one cookie or one candy bar before dinner."
"If you show up to work naked or drunk, you're fired."

(There are also two kinds of "why" in English where other natural languages make a clear distinction which I call the "what for" and "how come" senses. Examples of each in respective order are answers to the question "why is the remote control in the freezer?"

"how come" -> "I was holding it in my hand when I went to make myself a snack."
"what for" -> "The batteries last longer if you keep them good and cold.")

Zecc

@Gąska said in What is the meaning of OR?:

Yours looks equally wrong. Every line of code that ends with a binary operator looks wrong.

But you added one more line ending with a binary operator.
INB4 JS ASI, if not already

Also, this then:

    var foo
            = getBestFoo(input.foos).value
           *  (Config.User.GetBar("baz").shazams[0] + input.shazamModifier);

Zecc

@Gąska said in What is the meaning of OR?:

Me too. It's much more readable to me when a line starts with "but wait there's more!" than when it ends with it. Unfortunately this style is impossible in many "modern" languages due to auto-semicolon.

I knew it!

Zecc

@MrL said in What is the meaning of OR?:

That assumes that other developers know those design patterns and can easily recognize them.

If they don't, it's a learning opportunity. Win-win.

Gąska

@MrL said in What is the meaning of OR?:

@Gąska said in What is the meaning of OR?:

The specific things I mentioned were good, everything else was mostly bad. And before you scoff at design patterns - I didn't mean using pattern for the sake of using patterns; I meant using standard implementations instead of reinventing the same wheel in a different way, so that other developers have easier time learning your codebase.

That assumes that other developers know those design patterns and can easily recognize them.

The goal of the original Design Patterns book was exactly that. It should be standard part of every CS degree curriculum - all 23 of them, not just a select few. Instead of the differences between CGA and EGA or whatever they're teaching nowadays.

As for test coverage, I've talked way too much about it already in the past and IIRC you remained unconvinced. Your loss.

Actually I'm quite convinced - that Tests are a religion. Or rather a cult.

In that few people who claim to practice it actually understand it, and the straw version is super easy to pound at.

Source: working on projects with tens of thousands of tests.

And how much coverage do those tests provide? 90%? 95%? As I mentioned before, anything short of complete full coverage is useless. But when you do have full coverage, oh man, it's so good. You can actually make change in the code and be absolutely positive nothing else has broken! (Not to be confused with being broken to start with - contrary to popular belief, tests don't prevent bugs.) It's especially great for refactorings - since refactoring is supposed to change nothing at all, behavior-wise. And there are only two ways of verifying nothing has changed: automated tests, or manual tests.

MrL

@Zecc said in What is the meaning of OR?:

@MrL said in What is the meaning of OR?:

That assumes that other developers know those design patterns and can easily recognize them.

If they don't, it's a learning opportunity. Win-win.

Hmm, no? If they don't know that code they are looking at is a design pattern they won't associate it with a name. Which is the whole point of design patterns - throwing around fancy names and being smug

MrL

@Gąska said in What is the meaning of OR?:

The goal of the original Design Patterns book was exactly that. It should be standard part of every CS degree curriculum - all 23 of them, not just a select few. Instead of the differences between CGA and EGA or whatever they're teaching nowadays.

If you want to train mindless automatons instead of programmers, sure.

In that few people who claim to practice it actually understand it, and the straw version is super easy to pound at.

Yeah, 'X is fantastic and if it's not you're doing it wrong', I'm familiar.

Source: working on projects with tens of thousands of tests.

And how much coverage do those tests provide? 90%? 95%? As I mentioned before, anything short of complete full coverage is useless. But when you do have full coverage, oh man, it's so good. You can actually make change in the code and be absolutely positive nothing else has broken! (Not to be confused with being broken to start with - contrary to popular belief, tests don't prevent bugs.)

Yes, that's really fantastic. You can spend countless hours writing tests and then tinker with them endlessly every time you change anything.

Hey, I changed stuff and as if by magic my 200 hours worth of tests tell me that stuff changed! Now I can spend 20 hours fixing those tests, so they stop telling me this. I just love how automated it is.

It's especially great for refactorings - since refactoring is supposed to change nothing at all, behavior-wise.

We have different definitions of refactoring.

And there are only two ways of verifying nothing has changed: automated tests, or manual tests.

Automated for actually complicated and/or changing parts. Manual for everything else.
Done with real testers, not programmers pretending to be testers. Preferably also with real users.

Zecc

The problem with design patterns is people tend to look at "pattern" more than "design".

topspin

@LaoC said in What is the meaning of OR?:

@Arantor said in What is the meaning of OR?:

@cvi Don't get me started on && and || vs and and or (yes, PHP has both sets of operators, yes you can intermix them, but no you fucking shouldn't because operator precedence will absolutely bite your ass)

If it's anything like Perl's (and IIRC they got that part right), the two sets exist precisely because people have been bitten by operator precedence. You use and/or if you want the partial-evaluation behavior and &&/|| for boolean logic, so something like
$a = $b || $c and return works just like
$a = $b || $c or return.

So they took the same operator symbols as C, because those are well known, and then applied different semantics to them?! In C & is bitwise and && is short-circuiting. Sounds like in PHP/Perl && is bitwise and and is short-circuiting.

dkf

@topspin said in What is the meaning of OR?:

So they took the same operator symbols as C, because those are well known, and then applied different semantics to them?! In C & is bitwise and && is short-circuiting. Sounds like in PHP/Perl && is bitwise and and is short-circuiting.

No. They're the same semantics as each other, but differ in precedence. In particular, and is lower precedence than = but && is higher precedence.

There's &/| for bitwise operations.

PleegWat

@Arantor said in What is the meaning of OR?:

@PleegWat I tend to have successful early return if it turns out that there's no work to do after all, e.g. 'fetch a bunch of records from the database to operate on' but as long as 'nothing to do' isn't a failure state, successful early return shouldn't necessarily be grounds for splitting the function.

Will admit it's probably a good idea in a lot of cases though.

@PleegWat said in What is the meaning of OR?:

(IE, there is significant work both before and after the potential return)

I agree.

Gąska

@MrL said in What is the meaning of OR?:

@Gąska said in What is the meaning of OR?:

The goal of the original Design Patterns book was exactly that. It should be standard part of every CS degree curriculum - all 23 of them, not just a select few. Instead of the differences between CGA and EGA or whatever they're teaching nowadays.

If you want to train mindless automatons instead of programmers, sure.

TDEMSYR.

In that few people who claim to practice it actually understand it, and the straw version is super easy to pound at.

Yeah, 'X is fantastic and if it's not you're doing it wrong', I'm familiar.

Newsflash: most things that are fantastic can be done wrong and then they're horrible!

Source: working on projects with tens of thousands of tests.

And how much coverage do those tests provide? 90%? 95%? As I mentioned before, anything short of complete full coverage is useless. But when you do have full coverage, oh man, it's so good. You can actually make change in the code and be absolutely positive nothing else has broken! (Not to be confused with being broken to start with - contrary to popular belief, tests don't prevent bugs.)

Yes, that's really fantastic. You can spend countless hours writing tests and then tinker with them endlessly every time you change anything.

Hey, I changed stuff and as if by magic my 200 hours worth of tests tell me that stuff changed! Now I can spend 20 hours fixing those tests, so they stop telling me this. I just love how automated it is.

20 hours fixing tests, instead of 50 hours debugging when your change that shouldn't break anything inevitably breaks something. Of course with 95% coverage, you get the worst of both worlds - 20 hours fixing tests and still you have to debug for 50 hours because something inevitably broke.

It's especially great for refactorings - since refactoring is supposed to change nothing at all, behavior-wise.

We have different definitions of refactoring.

If we do, then your definition is wrong. If you change behavior, you're not refactoring, you're adding a feature.

And there are only two ways of verifying nothing has changed: automated tests, or manual tests.

Automated for actually complicated and/or changing parts.

Actually, the exact opposite. Automated tests for EVERYTHING BUT the changing parts. The parts you changed obviously need the tests updated, often rewritten entirely. But everything else should have stayed the same, therefore the tests for everything else should still pass. And if every small change in every small module require you to update all tests in the whole project, you have much bigger problems. Tell me, do you, by any chance, have a single "mock config of everything everywhere" object in some global variable that needs to be tinkered with whenever you change anything anywhere? I have it in my current project and yes, it sucks. It also shouldn't be like that at all.

Manual for everything else.

In the case of that awesome project I was talking about, manual testing involved uploading a config to test device, going to a lab on another floor, flipping the power switch to reset it, and waiting an hour for all subsystems to boot up. Rinse and repeat for every possible combination of config options. The full test procedure had several hundred test cases.

Done with real testers, not programmers pretending to be testers.

Yes, we had those. In Delhi. Because several hundred test cases - very uneconomical to do in Europe. And obviously we didn't have manual tests after every change.

MrL

@Gąska said in What is the meaning of OR?:

If you want to train mindless automatons instead of programmers, sure.

TDEMSYR.

That's the result of teaching people ready solutions instead of how to think and telling them that swaying from approved paths is wrong.
Every pattern enthusiast I worked with was like this - trying to fit everything he encountered into named boxes that filled his head, incapable of discussing problems and possible solutions with understanding and deathly afraid of doing anything differently than before.

Newsflash: most things that are fantastic can be done wrong and then they're horrible!

Shattering news: not everyone values things the same.

20 hours fixing tests, instead of 50 hours debugging when your change that shouldn't break anything inevitably breaks something. Of course with 95% coverage, you get the worst of both worlds - 20 hours fixing tests and still you have to debug for 50 hours because something inevitably broke.

It's actually only 30 seconds of debugging, not even remotely comparable to 20 hours for tests.

It's especially great for refactorings - since refactoring is supposed to change nothing at all, behavior-wise.

We have different definitions of refactoring.

If we do, then your definition is wrong. If you change behavior, you're not refactoring, you're adding a feature.

No.

And there are only two ways of verifying nothing has changed: automated tests, or manual tests.

Automated for actually complicated and/or changing parts.

Actually, the exact opposite. Automated tests for EVERYTHING BUT the changing parts. The parts you changed obviously need the tests updated, often rewritten entirely. But everything else should have stayed the same, therefore the tests for everything else should still pass.

Why write tests for things that never change and always pass? It's a waste of time.

Test complicated things to ensure they produce correct results. Test things that are subject to change to ensure that change didn't fuck things up.
All the rest is either boiler plate that does effectively nothing, trivial code doing obvious things, or code that will never change - you test those once and you're done with it.

Tell me, do you, by any chance, have a single "mock config of everything everywhere" object in some global variable that needs to be tinkered with whenever you change anything anywhere? I have it in my current project and yes, it sucks. It also shouldn't be like that at all.

But of course not! Why would I mock config of everything when I have no tests.

In the case of that awesome project I was talking about, manual testing involved uploading a config to test device, going to a lab on another floor, flipping the power switch to reset it, and waiting an hour for all subsystems to boot up. Rinse and repeat for every possible combination of config options. The full test procedure had several hundred test cases.

Seems like we work on very different kinds of projects. Which may (partly) explain our different views.

Kamil Podlesak

@MrL said in What is the meaning of OR?:

@Gąska said in What is the meaning of OR?:

It's especially great for refactorings - since refactoring is supposed to change nothing at all, behavior-wise.

We have different definitions of refactoring.

If we do, then your definition is wrong. If you change behavior, you're not refactoring, you're adding a feature.

No.

What is your definition of refactoring?

MrL

@Kamil-Podlesak said in What is the meaning of OR?:

@MrL said in What is the meaning of OR?:

@Gąska said in What is the meaning of OR?:

It's especially great for refactorings - since refactoring is supposed to change nothing at all, behavior-wise.

We have different definitions of refactoring.

If we do, then your definition is wrong. If you change behavior, you're not refactoring, you're adding a feature.

No.

What is your definition of refactoring?

Like I said: changing stuff so it looks/works better.

Gąska

@MrL said in What is the meaning of OR?:

20 hours fixing tests, instead of 50 hours debugging when your change that shouldn't break anything inevitably breaks something. Of course with 95% coverage, you get the worst of both worlds - 20 hours fixing tests and still you have to debug for 50 hours because something inevitably broke.

It's actually only 30 seconds of debugging, not even remotely comparable to 20 hours for tests.

Sure, and if you look at a full moon at midnight you'll see a unicorn.

It's especially great for refactorings - since refactoring is supposed to change nothing at all, behavior-wise.

We have different definitions of refactoring.

If we do, then your definition is wrong. If you change behavior, you're not refactoring, you're adding a feature.

No.

What can I say? Keep being wrong if you want.

And there are only two ways of verifying nothing has changed: automated tests, or manual tests.

Automated for actually complicated and/or changing parts.

Actually, the exact opposite. Automated tests for EVERYTHING BUT the changing parts. The parts you changed obviously need the tests updated, often rewritten entirely. But everything else should have stayed the same, therefore the tests for everything else should still pass.

Why write tests for things that never change and always pass? It's a waste of time.

Don't tell me you've never accidentally introduced a bug in one module when you were messing with another one. You've been programming for more than two years, and I haven't heard any news of second coming of Jesus yet.

Tell me, do you, by any chance, have a single "mock config of everything everywhere" object in some global variable that needs to be tinkered with whenever you change anything anywhere? I have it in my current project and yes, it sucks. It also shouldn't be like that at all.

But of course not! Why would I mock config of everything when I have no tests.

I meant at the time you've had to deal with "tens of thousands of tests". Because IME the main reason why people have to spend 20 hours updating tests whenever anything changes is because they have such global config referenced in all tests.

In the case of that awesome project I was talking about, manual testing involved uploading a config to test device, going to a lab on another floor, flipping the power switch to reset it, and waiting an hour for all subsystems to boot up. Rinse and repeat for every possible combination of config options. The full test procedure had several hundred test cases.

Seems like we work on very different kinds of projects. Which may (partly) explain our different views.

Also I'm not literal god blessed with omniscience who by definition never does any mistake like you are. Alternatively, I'm not full of shit like you are.

You remind me a lot of people who say static type systems are dumb because you can just check if everything works when you run it. They also complain about hours wasted doing pointless busywork, and they also pretend finding all bugs at runtime is quick and easy and that you always know at all times all the consequences your change is going to have for the whole program so you know exactly what you need to test and what you can safely ignore.

Gąska

@MrL said in What is the meaning of OR?:

@Kamil-Podlesak said in What is the meaning of OR?:

@MrL said in What is the meaning of OR?:

@Gąska said in What is the meaning of OR?:

It's especially great for refactorings - since refactoring is supposed to change nothing at all, behavior-wise.

We have different definitions of refactoring.

If we do, then your definition is wrong. If you change behavior, you're not refactoring, you're adding a feature.

No.

What is your definition of refactoring?

Like I said: changing stuff so it looks/works better.

Specifically: changing stuff so it does the same thing but looks/works better.

Kamil Podlesak

@Gąska said in What is the meaning of OR?:

@MrL said in What is the meaning of OR?:

@Kamil-Podlesak said in What is the meaning of OR?:

@MrL said in What is the meaning of OR?:

@Gąska said in What is the meaning of OR?:

It's especially great for refactorings - since refactoring is supposed to change nothing at all, behavior-wise.

We have different definitions of refactoring.

If we do, then your definition is wrong. If you change behavior, you're not refactoring, you're adding a feature.

No.

What is your definition of refactoring?

Like I said: changing stuff so it looks/works better.

That's approx. 50% of all software development.

Specifically: changing stuff so it does the same thing but looks/works better.

That's much better.

Arantor

There is a point to be made here though.

The application I am working on today has no tests at all (the underlying components/frameworks do but not our code)

And I am OK with this: we’re still rebuilding large swathes at any given time, and none of it is to pay off technical debt, but new functionality. And the interconnectedness I inherited guarantees tests would just be a drag factor at this point when the “how it should work” can change weekly.

If this ever settles down I might think about adding tests to prevent regressions but so far not seeing it having any value.

topspin

https://www.reddit.com/r/InclusiveOr/comments/rw1of3/taken_from_wireds_new_episode_of_tech_support/

homoBalkanus

@MrL said in What is the meaning of OR?:

That assumes that other developers know those design patterns and can easily recognize them.

It works when you substitute "other developers" with "me in three months"

Gribnit

@Arantor said in What is the meaning of OR?:

And I am OK with this: we’re still rebuilding large swathes at any given time, and none of it is to pay off technical debt, but new functionality. And the interconnectedness I inherited guarantees tests would just be a drag factor at this point when the “how it should work” can change weekly.

You should still have tests. Test code is greenfield, and you can externalize nearly all concerns from the cases themselves. The test code at that point can start to reveal how to unpick the mess, especially around how preconditions are established.

Your test code will end up better structured than the app got to be for a bit, which isn't a problem.

Steve_The_Cynic

@topspin said in What is the meaning of OR?:

@Steve_The_Cynic wow, that’s even worse. So a*b + c is equal to a * (b+c).

That's right, but it's a long way from the worst part of APL. It has a lot of very tersely-named operators, and an unreasonably large fraction of them are just single Greek letters...

It also has lots of operators that work across vectors and matrices, and can do a lot with very short expressions. One example, taken from https://en.wikipedia.org/wiki/APL_(programming_language) is:

life ← {⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵}

Which defines a function life that takes a single parameter which must be a boolean 2D matrix containing the states of the cells of a generation of Conway's Life, and returns the next generation.

Benjamin Hall

@Steve_The_Cynic And looks like line noise.

Steve_The_Cynic

@Benjamin-Hall No, it's APL, not Perl.

Arantor

@Gribnit

Right now I’m dealing with the fact that client and server both keep their state as the user flows through the key flow of the app… and this gets out of sync. Ain’t no tests going to help me cover the mess this caused.

Also a vast amount of my app is external API driven and mocking that out doesn’t help me deal with the weird edge cases that spits out.

I get that you feel tests would help. At this stage building tests is literally counterproductive because things change week to week such that what was the plan last week is now 180 this week, and tests just increase the drag factor on turning that tanker around.

Gribnit

@Arantor ah, fair, that's irrecoverable. Try day-drinking.

boomzilla

@Gribnit said in What is the meaning of OR?:

Try day-drinking.

Always a solid option.

Bulb

@cvi said in What is the meaning of OR?:

: I then tend to put the operator on the new line.

I used to put the operator mostly on the end of the line, exactly because that makes it obviously incomplete. But in one past project the main Java guy (we had C++, Java and JavaScript there) insisted that the standard convention is putting it on the next line. I feared it might not be compatible with JS automagic semicolons, but it actually inserts them based on what the next line starts with, so it is (but watch out of return statements). So I kinda got used to that since.