Six years ago, I was taught my first lesson of C++. Soon after learning about loops, came a subsidiary lesson about the goto statement. The teacher made it clear that using goto was a horrible practice because of unconditional-jumps mess it creates and should always be avoided. A bit of googling followed and I ended up with a well known essay of E. Djikstra’s ‘Goto is considered harmful’ and I committed myself to never use the statement even if it meant creating a frivolous flag variable.
When I didn’t had much exprience with web development, the only worthwhile thing I was able to sell as a freelancer was web scraping. After all, it was just a lousy combination of cURL and preg_* functions. Twiddling around Stackoverflow I got to know about the most upvoted answer on the site – a hyperbolic poetry on how you should never parse HTML with regular expressions and half a dozen more answers parroting the same message with their own flavour of the joke.
This moved me to abandon my way of using regexes and try a using a DOM Parser instead. Note that, at that time, the DOM libraries in PHP were really bad and DOMDocument API was far too weak to do anything moderately complex but anyway, I bore with them for any web scraping that I did.
Not-always best practices
Notice anything common between the two? I took both ‘opinions’ as something written in stone, needing always to be adhered to and gladly, sacrificed my pace of development in favor of something I saw as ‘best practice’. Goto statement is not evil if you use it a good way and sometimes it is the perfect solution to break out of loops.
I think goto’s are fine, and they are often more readable than large amounts of indentation. That’s especially true if the code flow isn’t actually naturally indented (in this case it is, so I don’t think using goto is in any way clearer than not, but in general goto’s can be quite good for readability).
-— Linus Torvalds
In the second case, I obliged to dictated don’t-parse-html rule and switched to something ‘saner’ and spent 4-fold time to do it that way, when there was no perfect tool to do it than regular expressions. In fact, the professed fact in that thread that one cannot parse HTML with regular expressions, because HTML isn’t regular is hardly true.
I believe, most of us assume that we always have the rationality to make a judgement but often, we are affected by the prevailing opinion / practice. The authority is still acting, its effects are not obvious but given a new found situation, we might discard the rational choice and chose something without a good judgement. After learning many lessons like the two I mentioned, I was sure that I won’t be making the same mistake of blindly following the popular judgement but I was wrong.
Any person who has used Git for an appreciable amount of time might have seen a branching model – git flow which suggest to create a branch for everything – from small bug fixes to small features. While the benefits of the process seems attractive, it is not obvious that it hinders the pace of development, like any other check.
I was certain that the model needs to always be followed by any team but I was surprised, that chromium’s development team works without using branches so that their pace isn’t hampered by branching, and merging. This made me realize that repetitive branching may often be unnecessary if your team is good enough to follow coding guidelines and the stability is complemented by a great automated testing and building environment. While it is possible that, this might sometimes result in introducing broken features, the gains in the pace are also significant.
Conclusion
There are some opinions in programming world that acquire a status of unquestionable wisdom and we tend to follow it blindly, without questioning how well it fits the use-case. While, we shouldn’t snub the popular practices but it is wise to always question their efficacy in your own scenario.