- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
hypoxia? I bet on intern
Admin
Intern, schmintern. This was done by either a genius senior dev or a HPC. Or both working together.
Admin
Even though the site is obviously French, the variables are English. That means that not only $golableMSG is misspelled, but $globaleMSG2 as well - it should be $globalMSG2.
Even in French, globale is only used for the feminine form, so I'm guessing this message variable is female.
Admin
Not only message is not supposed to have an extra "s", but "envoyer" is supposed to be "envoyé". The original may be translated to "Your Messsage is not send correctly" (with "send" instead of "sent")
Admin
Not only is there an extra letter s in "Votre Messsage n'est pas bien envoyer". Also, there's no need for a capital M. And it should be "envoyé" instead of "envoyer". That's like saying in English: Your message is not well to send".
Admin
I think this is the standard email sample script that's included on every PHP installation?
Admin
Yes. Hungarian notation is always bad. Except of course: pxPosX = pxLeft + ptWidth; and you immediately see the error in the dimensions. That is what Hungarian notation was all about, until Petzhold ruined it and asserted that it should denote type, and not dimension.
Admin
Maybe I'm misreading (it's still early in the morning, right?), but how does the code prohibit hyphens in the person's name? There's a hyphen in the regular expression.
Admin
Actually very common in France, which makes this surprising. Might be from another French-speaking country?
Admin
Including units in a variable name is fine- though I prefer postfix (
posXpx), but that said- it's still wrong. That problem should be delegated to your type system-posX = left + widthshould fail to compile if the units don't match.Admin
Doh, that's an error on my part.
Admin
In Hungarian notation, all PHP variables have the
$type, because those shitty enterprise applications are an expensive hell to maintain ;-)Admin
'6_6
Admin
No matter where I go in this project, there's a 99% chance that any line of code I copy is going to be terrible. To top it off, every main PHP file has at least 800 lines of code—no organization, no structure, just a spaghetti pile of horrors. I'm neck-deep in this messy soup, and honestly, I don’t know what to do anymore. Should I just quit and save my sanity, or stay and have some twisted fun trying to tame this beast?
Admin
The original paper proposing them suggested using them for identifying the difference between raw unvalidated/sanitised user input, stuff that's checked or doesn't need to be checked, stuff that's escaped for usage in the storage layer, and stuff that's escaped for usage on the front end.
The idea being that you'd always ensure the only time you ever pass from one to the other was when sanitising or escaping something, and then it's only ever done once(to avoid double escaping or similar).
The recommendation was to even honour this in the data storage, so untrusted data stored directly into the DB would retain a prefix to indicate it's raw userdata and not to be trusted, as well as would need to be escaped before displaying it back on the front end.
It's actually a very nice idea from a security standpoint, even today.
Admin
Who are you quoting? That text isn't anywhere else in this comment thread nor the main post.
Admin
I thought the original idea was to have measurement units (cm, mm, inches, liters, degrees etc.), as there was no mechanism at the time for strict variable types.
The first time I encountered safe/unsafe strings (I do not do web development) was in Joel's blog entry 'Making Wrong Code Look Wrong'. Makes sense the way he explains it.
Admin
While we're refining grammar: "checked to see if the $_POST variable were set" should just use "was" (and, really, "whether"). Subjunctive "were" is wrong here, since it's not wishful or contrary to fact. It's set or it's not, and this is finding out which. Indicative.
On the plus side, at least this site HAS a contact-us page, which is not something I can say about most websites I visit today.
Admin
It was, but Remy removed it when the error was pointed out.
Admin
Take the personal contact details of the nice people (if there are any) at the company, and save your sanity.
All the time you spend taming that beast is time that you don't spend doing more fulfilling and/or healthy things (like spending time with your loved ones, taking care of your body, spending time outdoor in nature, writing postcards to distant friends, or literally whatever else).
If you choose to stay anyway, then at least demand tons of cash from the company, and good working conditions (as much remote work as you need, etc).
Admin
Yes, it allows hyphens, and also parentheses, colons, pluses, and so on, but not apostrophes.
Admin
Oh, I see. Thanks for clearing that up. Might it be better to use a strikethrough, like ~~this~~ that way it's clear that something changed and only ninja-edit for more serious cases?
Addendum 2024-11-22 09:01: Hmm, apparently strikethrough markdown isn't supported in comments.
Admin
Let me guess the asterisks in variables are for highlighting fields that were filled incompletely when the page outputs all the fields again in case of an error? Or maybe that was the plan but never implemented?