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

11–20 of 61 posts

Re: Best Practices Are Not Always the Best

#11

Post by coldtea »

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…

>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 totally, absolutely, fine.

If my HTML file is like:

  
  
  foo

  foo

  foo

  foo

  foo

  foo

  foo
I can parse it just fine with regex.

And even parsing is the wrong word: I can extract the information I want is a better term. I won't be parsing anything in the AST sense.

Re: Best Practices Are Not Always the Best

#12

Post by dkersten »

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…

I agree.. if you ask any kind of question on code optimisation on stackoverflow you’ll be bombarded with “profile and see” responses, or “don’t bother, your compiler can do a better job” or “use an existing library”, but... profiling will only tell me what’s best on my current hardware, not in the general case. It doesn’t help me understand typical performance characteristics of common operating systems or hardware. It also doesn’t help me with coming up with new better approaches that I don’t know about (which is why I’m asking the question in the first place, to learn what I don’t know). The compiler can do a decent job, but it’s not magic and it often pretty easy to beat the compiler or at least helping it (eg by following Mike Actons advice - compiler can’t make cache inefficient code cache efficient often). Finally, regarding using libraries, sure, in production code I probably will, but I want to learn! If nobody learns, who will write tomorrow’s libraries?

Re: Best Practices Are Not Always the Best

#13

Post by Rapzid »

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…

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 to clear the dirty bit on an ntfs file system, and probing into details only "library writers" should have to worry about.

Re: Best Practices Are Not Always the Best

#14

Post by jrs95 »

mlevental wrote: post #10
jrs95 wrote: post #7

Earlier quoted context omitted.

Sounds like the community might be a reason to use Vue over React ;) In all seriousness this is a problem I've run into before as well. I once reported a bug and the lead developer of the project responded saying he didn't think the bug existed. Setting the hostname in the config to the server's IP address was irreversible even if you change it later -- the site would redirect back to the raw IP and outgoing emails w…

>Sounds like the community might be a reason to use Vue over React ;) I've run into these "no I'm not telling you because of best practices" people in every single "community"

I'm sure -- the only times I haven't are when I haven't even had the opportunity to. I was just joking around.

Re: Best Practices Are Not Always the Best

#15

Post by [deleted] »

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…

[deleted]

Re: Best Practices Are Not Always the Best

#16

Post by coldcode »

epicide wrote: post #9
xojp123 wrote: post #4

Being a tad pedantic and agree with the spirit of the article, but this just seems like a result from the overuse of the phrase 'best practices'.

Exactly. "Best" practices don't always turn out to be the best, after all. "Better" practice might be a better (heh) fit. It's often more useful to look at anti-patterns and avoid those (still with a grain of salt) than it is to go looking for a pre-existing "best" solution to your specific problem.

Don't get me started on the other best, "Best of Breed". Nothing in software or programming is a binary system, best and dreadful.

Re: Best Practices Are Not Always the Best

#17

Post by Noumenon72 »

Two years into my programming career, there's still almost nothing I do that isn't just implementing the best way someone else thought to do it. And I still have a lot more to learn before I would start off on my own. My only problem with best practices is that sometimes there are too many and living up to them all would take all your time. And some of them are just evangelists for niche ideas and it's hard to tell.

Re: Best Practices Are Not Always the Best

#19

Post by Retric »

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…

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, which is the trap. Things that don't change the meaning like swapping the order Attributes which does not change the meaning will often force an update to your regular expression.

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

Post reply on HN