Earlier quoted context omitted.
Serious question... why would any other approach be exempt from the problems you stated?
Nothing is exempt, some things are far less fragile than others though.
Best Practices Are Not Always the Best
51–60 of 61 posts
Re: Best Practices Are Not Always the Best
#52you know what grinds my gears? when I go looking for help on a problem and the answers I get are "don't do that it's not best practices". like not okay here's how you do it but you shouldn't but just flat out I'm not going to tell you. that's the most arrogant/presumptuous and consistent thing I've ever dealt with and it's absolutely unique to software development. It completely discounts the individuals personal exp…
Whether you like it or not, I and many others instinctively use grammar, spelling and punctuation as a signal about the mind behind the post. Plus, it makes your post easier to read - posts that aren't just a continuous flow of text with no break are easier to read.
My point is - there is an easy way to give your post a greater chance of influencing the thinking more people.
Re: Best Practices Are Not Always the Best
#53If everyone is doing it. how can it possible make you the best?
Re: Best Practices Are Not Always the Best
#54Earlier quoted context omitted.
When I was young, I was asked to print some address labels, so I wrote a quick super-short BASIC program to parse a specific file, right now, today, and got those labels printed. Made all sorts of assumptions, but it didn't matter, because it was a static file, and nothing could ever change in it. Three or four years later, I was having lunch with the guy I'd done that for when he got a phone call. Turns out they wer…
What lesson was that? From my perspective, this other guy was using a program outside of its design spec. That can be fine, but such a thing is prone to the problem of safe assumptions suddenly not being safe. You wrote the program for the problem you needed it for, and for which, it worked fine. Unless part of the problem at the time was "we expect to use this program for a couple years", there is no reason to make…
Code designed to be used once has a habit of sticking around.
Re: Best Practices Are Not Always the Best
#55you know what grinds my gears? when I go looking for help on a problem and the answers I get are "don't do that it's not best practices". like not okay here's how you do it but you shouldn't but just flat out I'm not going to tell you. that's the most arrogant/presumptuous and consistent thing I've ever dealt with and it's absolutely unique to software development. It completely discounts the individuals personal exp…
Oh man this brings back memories. I learned golang for/during a performance coding competition. It was extremely frustrating asking questions about unsafe, pointer casting, and other nuts and bolts in golang-nuts and the irc channel. People were flat out refusing to answer very straight forward questions because "what are you trying to do", "that's not safe", "you shouldn't have to do that". Other fun times; trying t…
Re: Best Practices Are Not Always the Best
#56you know what grinds my gears? when I go looking for help on a problem and the answers I get are "don't do that it's not best practices". like not okay here's how you do it but you shouldn't but just flat out I'm not going to tell you. that's the most arrogant/presumptuous and consistent thing I've ever dealt with and it's absolutely unique to software development. It completely discounts the individuals personal exp…
Re: Best Practices Are Not Always the Best
#57Earlier quoted context omitted.
What lesson was that? From my perspective, this other guy was using a program outside of its design spec. That can be fine, but such a thing is prone to the problem of safe assumptions suddenly not being safe. You wrote the program for the problem you needed it for, and for which, it worked fine. Unless part of the problem at the time was "we expect to use this program for a couple years", there is no reason to make…
"right now, today" and "that specific file" Code designed to be used once has a habit of sticking around.
Re: Best Practices Are Not Always the Best
#58Earlier quoted context omitted.
"right now, today" and "that specific file" Code designed to be used once has a habit of sticking around.
https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
The only thing regex has going for it is you might already know it. But, this is one of those time when learning something is worth it.
PS: XP is doing a depth first search, which can be EXtreamly wasteful.
Re: Best Practices Are Not Always the Best
#59Re: Best Practices Are Not Always the Best
#60you know what grinds my gears? when I go looking for help on a problem and the answers I get are "don't do that it's not best practices". like not okay here's how you do it but you shouldn't but just flat out I'm not going to tell you. that's the most arrogant/presumptuous and consistent thing I've ever dealt with and it's absolutely unique to software development. It completely discounts the individuals personal exp…
I quite frequently run into the problem of the answer to something simply being "that's not best practice", "that's insecure" or even "that's user-hostile".
I don't /care/. This is getting installed on a Raspberry Pi and installed inside of a touchscreen coffee table and towed across the country. It doesn't matter that this non-internet-connected device may be vulnerable to other websites accessing its webcam. It doesn't matter that hiding scrollbars and cursors is normally user-hostile.
Go ahead and make the point that it's not best practice, insecure, or user-hostile... But don't make that your entire answer.