Sort By:
Aug 14, 2014
@chris4182 -

> Food for thought: Dilbert's replacement will keep the code as-is because he's an idiot as per Dilbert, or in real, Dilbert's code is good? ;)

The answer to the trick question is none of the above; Dilbert's replacement is a Wally. He leaves the code as-is so he does no work.
Aug 13, 2014

I apologize for not being a purist when it comes to coding and being more of a perfectionist in my language. You apparently take it seriously enough that there is no room for humor (in a comic strip comment section, no less). Be that as it may, I do stand by my comments that there is good code... subject to the reviewers opinion... bad code... again, subject to the reviewers opinion... and code that should never be written. Don't confuse opinion with industry standards or best practices.
Aug 12, 2014
Food for thought: Dilbert's replacement will keep the code as-is because he's an idiot as per Dilbert, or in real, Dilbert's code is good? ;)
Aug 12, 2014
I wish this site had edit buttons sometimes... tho I can understand why not. Most people in these comments tend not to be the kind of people that troll edit their posts however. Now I'll probably get negative votes... but it's not like I really care about that anyway.


What I said previously is "some things aren't opinion...", this doesn't mean that what contributes as "good" or "bad" code isn't opinion, it's simply stating there are exceptions, which in this case I have inferred are bad, irrelevant of opinion.

I am guessing if you know PHP that there is clearly some bad logic in the below code that I put earlier.

$myvar = $_SESSION['somevar'];
$dbresults = mysql_query('SELECT * FROM mytbl WHERE password=$myvar');

This bad logic leads to both PHP and MySQL injection attack vulnerabilities (at minimum). However, there are other bad things about this code, it is using a deprecated method (mysql_query), the variable names $myvar and somevar are meaningless and should be "password". Also the MySQL query has a 9 out of 10 chance of being horrifically bad but that'd require knowing the design of the DB. Lastly in this scenario, there is simply no sanitization on somevar... I could write a page and half of A4 on all the issues with that, but notably the above mentioned PHP/MySQL injection attacks are caused by this lack of sanitization.

Overall there is basically nothing acceptable about this piece of code... it's the code of somebody new to PHP who doesn't know what they are doing and with out oversight of a Senior Developer. This is code that should not EVER see the night of day in production and yet I have seen in use in such... as depressing as that is.
Aug 12, 2014
@Morduin00 I don't see any real humor or logic in that previous post.

Code can always be made better or more efficient, that doesn't mean the code that came before was bad. It may even be a case of the goal posts have changed and the old code was fit to another model which again doesn't mean the previous code was bad as it was fit for purpose for it was designed. Bad code is simply bad code, don't try to differentiate with a term you literally just made up. Don't try to hide behind redefining inefficient code (which may not necessarily be bad) as bad code and then bad code as "bad-idea" code.

The code I posted is literally down to nothing more than a lack of experience, unfortunately companies have a bad habit of hiring cheaply and getting in junior PHP devs to do their entire website for them and then wonder why their sites get compromised. Or worse they off shore the code to people in other countries that can churn out piles and piles of bad code but not a single line of good code.
Get the new Dilbert app!