|
Hey Bob,
I think it depends on the platform being used. If I am using a not so type safe platform where at coding time type cannot be inferred, then a prefix for denoting object type is perfectly valid. I am not so sure about type safe languages such as C#. Also the problem I described was prefixing of classes which again should be avoided in my opinion regardless of platform. Anyhow happy friday and happy coding !
Ashish
Ashish Kaila
|
|
|
|
|
WTF?
while (e) { Coyote(); }
|
|
|
|
|
"I hate TLAs." You may quote me.
|
|
|
|
|
In this software users have virtual money (so called 'coins'). You donate (real money) to get coins or you are very active on the platform, and for these coins you can buy extra features.
Recently the CEO asked me, why some users have millons of 'coins' on there account. So I looked at the code and I found this:
<p>This will cost you 9.99 of your coins.
Please acknowledge the transaction by clicking
on "Pay"</p>
<form method="post" action="">
(more stuff)
<input type="hidden" name="amount" value="9.99">
<input type="button" value="Pay">
</form>
And the PHP looked like this:
$query = "SELECT * FROM user WHERE id = $id";
$res = mysql_query($query);
while($row = mysql_fetch_array($res))
{
$amount = $row["amount"];
}
$amount = $amount - $_POST[amount];
$query = "UPDATE user SET amount = $amount WHERE id = $id";
I will not talk about all the other errors and flaws here, I'm just asking you: How is the math for:
4.55 -
-1,000,000 ?
|
|
|
|
|
I almost feel like asking where the web app is to mess around with it myself
|
|
|
|
|
i mean it!
The glorious "How-Not-To Programming", or "The 99 Don'ts of Web Development"
|
|
|
|
|
ok, so looks like you've got a job then - better get onto it and rewrite the app. If the CEO has written it without any programming skills, and he's attracted a bunch of keen users, and he's already got funding to employ you, then I'd say he's not doing too bad...
|
|
|
|
|
upon seeing all these code, I just want to poke my eyes out.
|
|
|
|
|
Is there any chance you could get him a job with Paypal? Please?
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
I'm sorry, but I found the next one: There is a file that shows some statistics. It is called via ajax from the index page once per second (so it produces already a lot of traffic anyway).
This is a part of the code inside this file:
$query = mysql_query("SELECT * FROM " . $table . "");
$data = mysql_num_rows($query);
$query2 = mysql_query("SELECT * FROM " . $table . " WHERE status = 'Online'");
$data2 = mysql_num_rows($query2);
$query3 = mysql_query("SELECT * FROM articels");
$data3 = mysql_num_rows($query3);
$query4 = mysql_query("SELECT * FROM user");
$data4 = mysql_num_rows($query4);
$query5 = mysql_query("SELECT * FROM posts");
$data5 = mysql_num_rows($query5);
$query6 = mysql_query("SELECT * FROM url where url !=''");
$data6 = mysql_num_rows($query6);
I totally lost my faith.
|
|
|
|
|
Obviously, this is a test to see how well your infrastructure holds up to DDoS attacks. No horror in that!
|
|
|
|
|
Yes, and a test of my patience when he asks me again: 'Why is the serverload over 90?'
|
|
|
|
|
1. You are 100% correct..
2. It has even a more basic flaw than that.. it is very very fragile.. using 'Select *' is a surefire guarantee to invoke all kinds of downstream issues when the DB design changes.
As a fail, it is admirably complete.
|
|
|
|
|
Yes, and the whole software even more. As I wrote in another part of this 'series' he managed to do really everything wrong which is possible - in fact he wrote the How-Not-To of programming. I don't know where to start, so much he did wrong. E.g. there is no checking and no escaping of parameters, GET and POST parameters are written directly in the query. Depending on the PHP configuration is is possible to delete whole tables via SQL-injection. And, pretty nice, every user has an account with virtual money. But this will be part 4..
|
|
|
|
|
To activate his account the user has to enter a key which is stored in the database in his account-record. How do we find this record? Well, we search the table:
$loginname = $_POST['loginname'];
$keyEntered = $_POST['key'];
$query = "SELECT * FROM user";
$result = mysql_query($query) or die(mysql_error());
while($row = mysql_fetch_array($result)){
if ($keyEntered == $row["activator"]){
$sql="UPDATE user SET activator = '', status='activated' WHERE username = '$loginname'";
mysql_query($sql);
$time=time()+ 365*24*60*60;
setcookie("check", "1",$time);
}
}
if ($keyEntered != $row["activator"])
{
$msg2="Invalid key";
}
So:
- No escaping of the entered POST-parameters.
- First query fetches ALL datasets!
- WHERE-clause in second query takes the loginname given by the user, not the id of the dataset found
Can this be worse?
|
|
|
|
|
Yes, it can.
Garnish the whole thing with some empty catch blocks. Obfuscate these horrors with a generous helping of spaghetti (code). Use only obscure abreviations as names for variables. Avoid comments at all cost. Throw in some lengthy and totally needless string manipulation to avoid having to use any other data type. Let those string manipulations fail (sometimes) because the string was null to begin with, which omits about 10000 code lines by going directly to the empty catch block.
Or how about this: Send some query to get a filled dataset with several tables and many rows. Then clear out all the rows (but prevent them from being deleted in the database). This way you conveniently get a dataset to fill with your own new rows. No hassle with setting up the dataset first.
And I have this and many more great ideas in one big ball of rubbish. And the spaghetti parts are so good that any attempt to replace the most horrible parts one by one is doomed to fail.
A while ago he asked me what he should have printed on my business cards. I said 'Wizard'.
I read books which nobody else understand. Then I do something which nobody understands. After that the computer does something which nobody understands. When asked, I say things about the results which nobody understand. But everybody expects miracles from me on a regular basis. Looks to me like the classical definition of a wizard.
|
|
|
|
|
If your code is clean, short, concise and has excellent method/function/variable/class names, then you can "Avoid comments at all cost."
|
|
|
|
|
Ha! You made some good suggestions! Unfortunately the genius about who I'm talking already managed most of your ideas. I will bring more examples, you will see!
|
|
|
|
|
Clippy: I see that you entered the wrong password. The correct password is "apple"; shall I enter it for you?
|
|
|
|
|
imagiro wrote: $time=time()+ 365*24*60*60;
Does nobody know that there are 86,400 seconds ina day? [I can't prove this but I have thios ingrained in my long-term memory.]
Panic, Chaos, Destruction.
My work here is done.
or "Drink. Get drunk. Fall over." - P O'H
|
|
|
|
|
Distant memories of childhood wonderment: Eight six four two zero(es). And yes, it has been useful these last 60-odd years.
Cheers,
Peter
ps No idea why you got downvoted. Have my 5 in at least partial compensation.
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
Nagy Vilmos wrote: Does nobody know that there are 86,400 seconds ina day? [I can't prove this but I have thios ingrained in my long-term memory.]
Just last week I wrote a formula that included "numdays * 86400" and then I replaced it with "numdays * 24 * 60 * 60" because that adds clarity for the people who don't know how many seconds are in a day. If other people are going to read your code, it's easier to do 24*60*60 than to add a comment explaining why you're multiplying by 86400.
|
|
|
|
|
Indeed.
Your compiler should do that multiplication as part of the optimization stage anyway, so feel free to leave arithmetic on constants like that in your code as long as it improves the situation.
Even if it didn't optimize that out, if you're waiting on the SQL server to retrieve your results like that, the last thing you'll notice is 2 extra integer multiplication operations.
|
|
|
|
|
Wow. So you replaced a "magic number" with a set of "magic numbers" for clarity?
Replace the thing with a constant and you'd be doing far, far better.
|
|
|
|
|
#define SECONDS_IN_A_DAY 86400
is clearer and slightly educational to the reader, so definitely a better solution
You trivialize my approach as using "magic numbers", but in the real world probably 90% of the population can tell what you're doing if you do 24 * 60 * 60 whilst maybe 15% of people know what 86400 is. So, I'd still say 24 * 60 * 60 is clearer than 86400 despite it being 3 "magic numbers" instead of 1. Astonishingly, if you add a fourth magic number, nearly every literate human on the Western calendar understands it with no explanation: "365 * 24 * 60 * 60".
|
|
|
|