Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Best Practices Are Not Always the Best

blog.bloomca.me

Post reply on HN
Print view View original

21–30 of 61 posts

Re: Best Practices Are Not Always the Best

#21

Post by Pamar »

mlevental wrote: post #8
Retric wrote: post #5

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

>don't parse HTML with a regular expressions Even if I agree with you (I don't know because I've never been in the situation where that was a thing I was considering and weighing against other options) what I'm arguing here is that if someone asks how to do that then you should either tell them along with the admonishment or not say anything at all. But don't go around being a dick by yelling "haha that's the dumbest…

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...

Re: Best Practices Are Not Always the Best

#22

Post by shubhamjain »

"Don't use Goto," "Don't use Regex against HTML." Worse than not following best practices is accepting it without demur. The insight dawned upon when I learned how Chromium's team doesn't use continuous branching. The codebase moves so fast that committing to a single branch is a much better option [1]. I highly doubt Google's engineers made that choice out of sloppiness.

Although, I think it's not simple to foresee long-term implications of our decisions. And, best practices do fill that hole. At the same time, programmers should keep an open mind to use a solution if it's a radically simpler choice.

[1]: https://medium.com/@aboodman/in-march-2011-i-drafted-an-arti...

Re: Best Practices Are Not Always the Best

#23

Post by quantumhobbit »

Evertime I hear someone defend something as a best practice without any other justification, I mentally switch “best practice” with “cargo culting” and lose no information.

Sometimes the best practice in question does have value and can be articulated. But in those cases the articulated reason makes a better argument and you don’t hear the phrase “best practice” quite as often. When it is just cargo culting, the only defense is to repeat “best practice” over and over again.

Re: Best Practices Are Not Always the Best

#24

Post by tboyd47 »

> There are also tons of evangelists, which promote their technology/process/approach of choice, giving endless introductory talks and blogposts, but without answering complicated questions.

I find some programmers are very adamant that there's always a right way and a wrong way to do something and you just have to examine the pros and the cons. Well, what about when it's between a legacy codebase that no one on the team has even spent half a day looking at and an idea that someone read on a blog post that they never bothered to try? You can't honestly begin to identify pros and cons in a situation like that. But this is how our industry is now. So you kind of have to take claims of "best practices" with a grain of salt.

I don't even really engage in discussions on "best practices" anymore. Not because I'm cynical, but because they just lead nowhere. Write some code that runs, show it to me and we'll talk.

Re: Best Practices Are Not Always the Best

#25

Post by coldtea »

Retric wrote: post #19
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…

That is a trap and why people give that advice so freely. Sure, today you just want to parse these files just the once an never again, ever, really I mean it. Can you determine if it's Yes Vs No well sure and even more complex operations also 'work'. However, if you control what's going on then don't use regular expressions it's wasteful overhead. If you don't control it then you can't tell if it will stay like that,…

>If you control what's going on then don't use regular expressions it's wasteful overhead.

Not really, if you control what's going on it's a very fast option -- use awk, sed, or your scripting language's regex lib, and get the values you need. End of story.

Nobody cares if you can micro-optimize it with lower level string parsing that doesn't use a regex engine -- and the regex engine might end up being faster that that anyway.

>If you don't control it then you can't tell if it will stay like that, which is the trap.

No, but I already covered that in my original comment. One can do it to extract values for a specific, known html file, I said.

Besides,

(a) a lot of changes can still be caught by regex -- e.g. the order of attributes don't matter if the regex checks for that specific attribute alone (e.g. a href in an a tag).

(b) other changes will also fuck any non-regex, parser-based lib. E.g. if the nesting changes or an element is moved to another section. It's not like you don't have to update scripts written with e.g. BeautifulSoup or some HTML parser when the document changes.

>It's also why these are called best practices not physical laws.

That's up to those who advocate them to understand: and don't hand them out as if they were physical laws "NEVER PARSE HTML WITH REGEX".

Re: Best Practices Are Not Always the Best

#26

Post by phil21 »

coldtea wrote: post #11
Retric wrote: post #5

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

> 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 became old and crufty and fragile you may have just burned 3 days tracking it down.

If someone is asking this question, it is entirely appropriate to tell them "don't ever do that" - they obviously lack the experience and big picture thinking to know when it is appropriate to deviate due to business reasons. If you leave it at that I agree you're being a dick - whenever shooting someone's idea down you had damn well better have some appropriate alternative options.

Re: Best Practices Are Not Always the Best

#27

Post by vorpalhex »

quantumhobbit wrote: post #23

Evertime I hear someone defend something as a best practice without any other justification, I mentally switch “best practice” with “cargo culting” and lose no information. Sometimes the best practice in question does have value and can be articulated. But in those cases the articulated reason makes a better argument and you don’t hear the phrase “best practice” quite as often. When it is just cargo culting, the only…

I prefer to think of the term as "sensible default". A "best practice" is usually not the worst default to have, and if you don't have the time or bandwidth to dive into a problem and just want to pick a solution from a hat, you could do a lot worse.

The danger comes in that when you want to supplant the best practice with a new practice, you have to genuinely understand the problem in your context, and be able to articulate a full explanation about why the new practice has an advantage.

But there is definitely cargo culting around best practices - see using Redux. Core features of your app shouldn't be left to just acceptable defaults, but instead you should grapple with those problems and choose the best possible answer you can at the time.

Re: Best Practices Are Not Always the Best

#28

Post by Retric »

coldtea wrote: post #25
Retric wrote: post #19

Earlier quoted context omitted.

That is a trap and why people give that advice so freely. Sure, today you just want to parse these files just the once an never again, ever, really I mean it. Can you determine if it's Yes Vs No well sure and even more complex operations also 'work'. However, if you control what's going on then don't use regular expressions it's wasteful overhead. If you don't control it then you can't tell if it will stay like that,…

> If you control what's going on then don't use regular expressions it's wasteful overhead. Not really, if you control what's going on it's a very fast option -- use awk, sed, or your scripting language's regex lib, and get the values you need. End of story. Nobody cares if you can micro-optimize it with lower level string parsing that doesn't use a regex engine -- and the regex engine might end up being faster that…

I don't mean CPU overhead.

I mean you are creating a brittle process that's hard to verify it actually worked, unless you have access to the data some other way in which case it's mostly pointless. Regular expressions are not going to tell you if one of the files just happens to have bad data or any number of things that's going to cause problems.

Re: Best Practices Are Not Always the Best

#29

Post by dave84 »

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…

Serious question... why would any other approach be exempt from the problems you stated?

Re: Best Practices Are Not Always the Best

#30

Post by mlevental »

Pamar wrote: post #21
mlevental wrote: post #8

Earlier quoted context omitted.

>don't parse HTML with a regular expressions Even if I agree with you (I don't know because I've never been in the situation where that was a thing I was considering and weighing against other options) what I'm arguing here is that if someone asks how to do that then you should either tell them along with the admonishment or not say anything at all. But don't go around being a dick by yelling "haha that's the dumbest…

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 anyone's questions?): a flat out no is completely unsatisfactory and lazy. a no with a measured explanation is good.
Post reply on HN