Best Practices Are Not Always the Best • Hacker News Board

Re: Best Practices Are Not Always the Best

#31

Post by jerf » Thu, May 10, 2018, 1:53 PM UTC

phil21 wrote: post #26

coldtea wrote: post #11

Earlier quoted context omitted.

> Best practices are a very wide category, don't parse HTML with regular expressions is the kind of thing you really should just say don't do that. I call BS. "Don't have a continuously running service parse arbitrary HTML with regular expressions" would be a bad thing. Parsing specific, given, HTML files, with known structure to the dev, with regular expressions (e.g. as part of a one-off scrapping script) is totall…

As someone who has created more hacks like you describe than I care to admit, you actually make the case of precisely why you don't parse HTML with regex. Because that code works fine for 5 years until it blows up after something upstream changes. From a RoI calculation this might be perfectly fine if you're still around and remember how to fix it - it's a 5 minute fix after all! But if you've left, or if that system…

"Because that code works fine for 5 years until it blows up after something upstream changes."

I believe the point here is exactly that nothing will change, because the regex in question isn't for a service, it is just for that specific file, right now, today. I've regexed specific HTML files myself too, because even though I am very comfortable with XPath and Beautiful Soup and tree representations in general, regexes are even easier on a static file like that.

Re: Best Practices Are Not Always the Best

#32

Post by phil21 » Thu, May 10, 2018, 1:56 PM UTC

dave84 wrote: post #29

phil21 wrote: post #26

Earlier quoted context omitted.

As someone who has created more hacks like you describe than I care to admit, you actually make the case of precisely why you don't parse HTML with regex. Because that code works fine for 5 years until it blows up after something upstream changes. From a RoI calculation this might be perfectly fine if you're still around and remember how to fix it - it's a 5 minute fix after all! But if you've left, or if that system…

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.

Re: Best Practices Are Not Always the Best

#33

Post by phil21 » Thu, May 10, 2018, 1:58 PM UTC

jerf wrote: post #31

phil21 wrote: post #26

Earlier quoted context omitted.

As someone who has created more hacks like you describe than I care to admit, you actually make the case of precisely why you don't parse HTML with regex. Because that code works fine for 5 years until it blows up after something upstream changes. From a RoI calculation this might be perfectly fine if you're still around and remember how to fix it - it's a 5 minute fix after all! But if you've left, or if that system…

"Because that code works fine for 5 years until it blows up after something upstream changes." I believe the point here is exactly that nothing will change, because the regex in question isn't for a service, it is just for that specific file , right now, today. I've regexed specific HTML files myself too, because even though I am very comfortable with XPath and Beautiful Soup and tree representations in general, rege…

We're not talking about one-liners used on a single file here (as far as I could tell) - if that's the case, use whatever quickest hack you can think of to get the job done. Use-once coding is entirely different - everyone loves some code golf once in a while, but it doesn't mean you commit that to git :)

For re-usable tooling though, after some time you tend to avoid design patterns that you've personal witnessed break down repeatedly and cause issues.

Re: Best Practices Are Not Always the Best

#34

Post by watwut » Thu, May 10, 2018, 2:03 PM UTC

phil21 wrote: post #26

coldtea wrote: post #11

Earlier quoted context omitted.

> Best practices are a very wide category, don't parse HTML with regular expressions is the kind of thing you really should just say don't do that. I call BS. "Don't have a continuously running service parse arbitrary HTML with regular expressions" would be a bad thing. Parsing specific, given, HTML files, with known structure to the dev, with regular expressions (e.g. as part of a one-off scrapping script) is totall…

As someone who has created more hacks like you describe than I care to admit, you actually make the case of precisely why you don't parse HTML with regex. Because that code works fine for 5 years until it blows up after something upstream changes. From a RoI calculation this might be perfectly fine if you're still around and remember how to fix it - it's a 5 minute fix after all! But if you've left, or if that system…

There are plenty of disposable code situations where the code wont break after 5 years, because it does not exist after two months. Also, failing regexp on likely generated html like that likely wont take 3 days to find. That is ridiculously high estimate even for messy codebase.

You are trying to make estimates and decisions for project you know literally nothing about. That is about worst practice of them all.

In case the question was asked by someone lacking the experience - well then it is absolutely ok to learn regexp by trying to parse info few downloaded files of toy scrapped site. Having newbie fight like this just to learn makes no sense.

Re: Best Practices Are Not Always the Best

#35

Post by pasbesoin » Thu, May 10, 2018, 2:10 PM UTC

When they moved us, programmers and related staff, to "cubettes" -- not even full cubes, but rather a corner in a shared three-sided "pen" with low walls. Your neighbor's shoulder three to five feet away from you. Cube meetings crowding into their half of the pen. Conversations shouted willy-nilly across the open floor plan.

They called that the "best practice".

"Best" is in the eyes of whoever's calling it a "best practice".

Re: Best Practices Are Not Always the Best

#36

Post by Pamar » Thu, May 10, 2018, 2:16 PM UTC

mlevental wrote: post #30

Pamar wrote: post #21

Earlier quoted context omitted.

While I agree with you in general (i.e. educate people or just stay silent instead of pontificating/be condescending if not rude), what would you say about the canonical answer on StackOverflow, then? https://stackoverflow.com/questions/1732348/regex-match-open...

meh. the tone isn't so bad but, while at first i thought otherwise, it doesn't really comprehensively explain why it's a bad idea (on first skim i thought most of the content of the answer was an explanation of the difference between a state machine and cfg or something like that). i think a good model for how to answer questions like this is really the same as you'd answer kids' questions as a parent (or maybe anyon…

Again, agreed. But what when something is at the same time pretty much wrong but also something that everyone tries to do because superficially looks like a good idea?

The reaction on StackOverflow was because they were getting dozens (hundreds) more or less identical copies of the same question. It was the same with "parse email via regexp" but I understand that more recent versions of the RFC make this doable.

Re: Best Practices Are Not Always the Best

#37

Post by pwinnski » Thu, May 10, 2018, 2:18 PM UTC

jerf wrote: post #31

phil21 wrote: post #26

Earlier quoted context omitted.

As someone who has created more hacks like you describe than I care to admit, you actually make the case of precisely why you don't parse HTML with regex. Because that code works fine for 5 years until it blows up after something upstream changes. From a RoI calculation this might be perfectly fine if you're still around and remember how to fix it - it's a 5 minute fix after all! But if you've left, or if that system…

"Because that code works fine for 5 years until it blows up after something upstream changes." I believe the point here is exactly that nothing will change, because the regex in question isn't for a service, it is just for that specific file , right now, today. I've regexed specific HTML files myself too, because even though I am very comfortable with XPath and Beautiful Soup and tree representations in general, rege…

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 were using that program of mine to print labels monthly now, and one of the completely-safe assumptions I'd made years earlier had bitten them. Fortunately, he knew how to resolve it easily, but I learned a very important lesson that day.

Re: Best Practices Are Not Always the Best

#38

Post by Franciscouzo » Thu, May 10, 2018, 2:23 PM UTC

phil21 wrote: post #26

coldtea wrote: post #11

Earlier quoted context omitted.

> Best practices are a very wide category, don't parse HTML with regular expressions is the kind of thing you really should just say don't do that. I call BS. "Don't have a continuously running service parse arbitrary HTML with regular expressions" would be a bad thing. Parsing specific, given, HTML files, with known structure to the dev, with regular expressions (e.g. as part of a one-off scrapping script) is totall…

As someone who has created more hacks like you describe than I care to admit, you actually make the case of precisely why you don't parse HTML with regex. Because that code works fine for 5 years until it blows up after something upstream changes. From a RoI calculation this might be perfectly fine if you're still around and remember how to fix it - it's a 5 minute fix after all! But if you've left, or if that system…

And parsing the HTML to an AST won't work either in 5 years, the format of the tree will probably have changed and you will be getting index errors.

Re: Best Practices Are Not Always the Best

#39

Post by cgdub » Thu, May 10, 2018, 2:27 PM UTC

Retric wrote: post #5

mlevental wrote: post #2

you 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…

Best practices are a very wide category, don't parse HTML with regular expressions is the kind of thing you really should just say don't do that. Camelcase is the middle ground where it's a good idea but personal preference may show up yet people get just as dogmatic about it. IMO, what trips people up is when wisdom says "don't use Oracle products" it's completely accurate, but not that helpful when you inherit a hu…

> you really should just say don't do that

You should also say WHY not to do that.

This lets whoever asked decide whether the reasoning applies to their own unique situation. Perhaps they are doing a one-off scrape of a single file with consistent structure like in the other comment.

The asker can also apply the same reasoning to similar situations. They won't come back to ask if they should use regex to parse JSON tomorrow.

And if you can't explain why something is "best practice", maybe it shouldn't be "best practice".

Re: Best Practices Are Not Always the Best

#40

Post by jerf » Thu, May 10, 2018, 2:31 PM UTC

phil21 wrote: post #33

jerf wrote: post #31

Earlier quoted context omitted.

"Because that code works fine for 5 years until it blows up after something upstream changes." I believe the point here is exactly that nothing will change, because the regex in question isn't for a service, it is just for that specific file , right now, today. I've regexed specific HTML files myself too, because even though I am very comfortable with XPath and Beautiful Soup and tree representations in general, rege…

We're not talking about one-liners used on a single file here (as far as I could tell) - if that's the case, use whatever quickest hack you can think of to get the job done. Use-once coding is entirely different - everyone loves some code golf once in a while, but it doesn't mean you commit that to git :) For re-usable tooling though, after some time you tend to avoid design patterns that you've personal witnessed br…

"We're not talking about one-liners used on a single file here (as far as I could tell)"

Well, we are, because to quote coldtea, the person you directly replied to, "'Don't have a continuously running service parse arbitrary HTML with regular expressions' would be a bad thing. Parsing specific, given, HTML files, with known structure to the dev, with regular expressions (e.g. as part of a one-off scrapping script) is totally, absolutely, fine." In context the first sentence clearly means that running the service like that would be a bad thing (hooray English and it's deep ambiguities in double negatives).

I still wouldn't necessarily be too upset about telling a junior dev to be suspicious of REs or avoid them (for instance, parsing HTML with REs typically requires using non-greedy matches, and there are some subtleties around that), but if you know what you're doing on a quick job it's fine. If you're a senior dev and you still haven't figured out what's likely to entrench itself and what really is a one-off job, well, that's your real problem. I haven't been surprised about what gets entrenched in quite a while.