11 ms·

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 h

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 experience (and abilities to make the right decision for themselves) and their circumstances (the project itself) and it's always around something dogmatic/a reflection of fanboyism. most recently on #reactjs I wanted to know if there were a way to have locally scoped styles in react like in Vue - I got only condescension about how react is for "bigboys" and hence eschews the practice. Finally someone said hey maybe try styled-components, which was basically close enough and has 16,000 stars on GitHub (so I doubt it's "worst practices"). software devs are some of the most zealous people I've ever met - everything is an opportunity to bike shed and every question or difference of opinion is an opportunity to quarterback someone else's code base.

Retric 8y ago
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 huge mess.
- mlevental 8y ago
 >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 thing ever and I'm not going to tell you because of best practices"
 - Pamar 8y ago
 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-tags-except-xhtml-self-contained-tags/1732454#1732454 https://stackoverflow.com/questions/1732348/regex-match-open...
 - mlevental 8y ago
 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.
 - Pamar 8y ago
 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.
- coldtea 8y ago
 >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: <html> <body> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> </body> </html> 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.
 - deleted 8y ago
 [deleted]
 - Retric 8y ago
 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 <html><body>Yes</body></html> Vs <html><body>No</body></html> 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.
 - coldtea 8y ago
 >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".
- cgdub 8y ago
 > 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".
- nix0n 8y ago
 > you really should just say don't do that This is counterproductive unless you also say what to do instead.
_asummers 8y ago
A similar frustration I have is when you ask a specific question and get a "Why would you do it that way? Rearchitect your app this way!". That's not reasonable, outside the smallest of applications, regardless of if the underlying advice is sound.
jrs95 8y ago
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 would have the raw IP in them. Many other users were commenting about the issue with no response from the maintainer, and I ended up finding a workaround using one of the "developer options" which was really just a one line ruby config change. Then, the author wrote like a one paragraph response saying that you should never set up the software like that and not to use that workaround because it's a "developer option". This bug went unfixed for about 2 years after that. And this is a relatively common and high profile piece of open source software. The whole thing was just bizarre, especially how positive my experiences with other open source projects (some third party Spring packages and Go Dep in particular) have been.
- mlevental 8y ago
  >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"
  - jrs95 8y ago
    I'm sure -- the only times I haven't are when I haven't even had the opportunity to. I was just joking around.
- specialist 8y ago
  Grrr. I’ve always designed away the sharp edges. Because I don’t want the 4:00a wake up call from panicky customers. Which is why all my devs also did rotations in tech supp, QA/test, build monkey, etc.
dkersten 8y ago
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?
Rapzid 8y ago
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.
- Can_Not 8y ago
  There was a discussion earlier in life about how Django didn't support prepared statements. I didn't believe this, as no ORM I've ever used didn't use prepared statements by default. I asked around, trying to verify this claim. I got "what are you trying to do?" I'm trying to find out if Django's ORM uses prepared statements by default. Outside of that one ticket in Google search results (I'm not tuned into that ecosystem, so I can't discern if it's reliable proof or not), it seems like nobody really knows.
rkangel 8y ago
Please consider putting in the effort to capitalise the start of sentences properly, and possibly split up your post into multiple paragraphs. 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.
Can_Not 8y ago
I might end up writing react code at any random time in my future, I'm currently curious on how one would do the equivalent of "VueJS component computed properties" in React.
nucleardog 8y ago
I work on a lot of less-usual stuff. Kiosks, signage display drivers, interactive games running on touch screen walls, etc. 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.

Retric 8y ago

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

mlevental 8y ago
>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 thing ever and I'm not going to tell you because of best practices"
- Pamar 8y ago
  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-tags-except-xhtml-self-contained-tags/1732454#1732454 https://stackoverflow.com/questions/1732348/regex-match-open...
  - mlevental 8y ago
    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.
    - Pamar 8y ago
      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.
coldtea 8y ago
>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: <html> <body> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> <a href="xxxxx">foo</a> </body> </html> 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.
- deleted 8y ago
 [deleted]
- Retric 8y ago
 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 <html><body>Yes</body></html> Vs <html><body>No</body></html> 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.
 - coldtea 8y ago
 >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".
cgdub 8y ago
> 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".
nix0n 8y ago
> you really should just say don't do that This is counterproductive unless you also say what to do instead.

_asummers 8y ago

A similar frustration I have is when you ask a specific question and get a "Why would you do it that way? Rearchitect your app this way!". That's not reasonable, outside the smallest of applications, regardless of if the underlying advice is sound.

jrs95 8y ago

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 would have the raw IP in them. Many other users were commenting about the issue with no response from the maintainer, and I ended up finding a workaround using one of the "developer options" which was really just a one line ruby config change. Then, the author wrote like a one paragraph response saying that you should never set up the software like that and not to use that workaround because it's a "developer option". This bug went unfixed for about 2 years after that. And this is a relatively common and high profile piece of open source software. The whole thing was just bizarre, especially how positive my experiences with other open source projects (some third party Spring packages and Go Dep in particular) have been.

mlevental 8y ago
>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"
- jrs95 8y ago
  I'm sure -- the only times I haven't are when I haven't even had the opportunity to. I was just joking around.
specialist 8y ago
Grrr. I’ve always designed away the sharp edges. Because I don’t want the 4:00a wake up call from panicky customers. Which is why all my devs also did rotations in tech supp, QA/test, build monkey, etc.

dkersten 8y ago

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?

Rapzid 8y ago

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.

Can_Not 8y ago
There was a discussion earlier in life about how Django didn't support prepared statements. I didn't believe this, as no ORM I've ever used didn't use prepared statements by default. I asked around, trying to verify this claim. I got "what are you trying to do?" I'm trying to find out if Django's ORM uses prepared statements by default. Outside of that one ticket in Google search results (I'm not tuned into that ecosystem, so I can't discern if it's reliable proof or not), it seems like nobody really knows.

rkangel 8y ago

Please consider putting in the effort to capitalise the start of sentences properly, and possibly split up your post into multiple paragraphs. 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.

Can_Not 8y ago

I might end up writing react code at any random time in my future, I'm currently curious on how one would do the equivalent of "VueJS component computed properties" in React.

nucleardog 8y ago

I work on a lot of less-usual stuff. Kiosks, signage display drivers, interactive games running on touch screen walls, etc. 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.