[lugg]

Why are you giving your functions uncertain data?

The first point your code sees uncertain data is the point that it needs to clarify what it has.

The only way you get the errors you're talking about is if you ignore the above practice.

Garbage in. Garbage out.

For code i write, there is usually only one option for what is in a variable, the type of the data i out in there. This is true for dynamic languages as much as static.

In some situations I will also allow a null value. All that means is that there was no data, and no default is wanted. Usually, I want a default.

Closing off all entry points for uncertain data you need to make assumptions about is the first port of call when dealing with other people's or legacy code. It's the way to reason about code without a debugger.

If you can't reason about code without a big question mark above every piece of data you need a debugger.

[okcando]

This amounts to saying that you don't need a debugger if you don't make mistakes.

If your mental model of how the code that you're interfacing with works is wrong, then it won't help you. Your data validation will error out and you might find that it was too much too early. Not only do you have logic based on flawed assumptions but check code as well.

Understanding the code base you're programming against, that's a skill that can be improved but hoping to guard against all misunderstandings is probably unrealistic. Given that, following a trace may help you identify disagreements with your model more quickly.

[rbanffy]

> This amounts to saying that you don't need a debugger if you don't make mistakes.

Not making mistakes certainly saves time.

I often use a debugger to inspect variables and check my assumptions about the application state at that point.

[lugg]

Far from it.

I am saying you don't need a debugger in the scenario above because the only time you need it in that case is if your inputs can't be trusted.

If you control the domain, the only way you can't trust your input is if you fucked up.

The answer to that isn't "oh now I need a debugger" the answer is to go clean your code.

While I'm here, I'd also like to point out this isn't a "I'm good and your shit" thing I'm describing, this is my day job. I make lazy crap code to get things done, then I go in to modify it and find I can't reason about it, so I go and clean up the mess.

Maybe I made it, maybe I didn't, it's besides the point, you have a mess, clean that first, then reach for a debugger.

Hell reach for a debugger to help clean up if you need to, just don't sit there and tell me you need a debugger because code inherintly needs to make assumptions about what is in a variable. It doesn't. If it does, it's a code smell.

> So many errors boil down to assumptions about what is in a value.

Only avoidable errors. They should not be dictating your tools or your language.

[compiler-guy]

https://rachelbythebay.com/w/2018/04/28/meta/

[asveikau]

I generally like her writing when I come across it, but I disagree with that one.

Good programmers are humans and make mistakes, of course. However, that doesn't mean good programmers don't exist or that people can't vary a lot in skill or average quality of output.

She is correct that starting with some notion of "good people" is no silver bullet. But the conclusion that "we all suck", I hope that is hyperbole, because it isn't true. (Or maybe: everybody sucks a little bit differently.)

[Tempest1981]

I interpreted her point as, "don't be overconfident or arrogant", such that you think that everyone else sucks. That you're too good to "lower" yourself to everyone else's level.

[lugg]

Yea, I find this take on my post odd.

I am the first person to understand developers are far from perfect, my self included. But it's just code, you can refactor and learn from mistakes.

The thing I don't buy is that this stuff is difficult or that you can't expect good behavior from professionals.

Avoiding side effects, or pushing them out to the edge where reasoning about them is clear is something you should have been taught when you got your expensive piece of paper.

Likewise, avoiding, mutation, over abstraction, early optimisation, and variable reuse are all really basic shit you need to understand, if you're not hiring for these basic qualities, what the fuck are you hiring for? Good looks?

[lugg]

I'm sorry did you mean to imply something with that link?

[pjc50]

Ironically kernel space is one of the places where you're more likely to get "wrong" values being teleported in to your program by bits of hardware, kernels running on other cores, and nightmare out-of-spec ACPI BIOSes.

An example inconvenient debugging story: https://mjg59.dreamwidth.org/11235.html

(I don't think DMA triggers hardware watchpoints, but if you set a hardware watchpoint and an an address changes value without hitting a watchpoint you know that something funny is going on)