Some Anti-Patterns At My Job
-
And in a couple of cases they use 0 as the 'true' value and 1 as the 'false' value.
That's probably the worst part.
-
@CoyneTheDup said:
@mihi said:
(precedence of && and || can sometimes be a bitch).
That's why you should always insert parenthesis, to make execution order explicit, before you apply DeMorgan's Laws.
No... if you don't remember the precedence, you write test code to figure out what the precedence is. Then you don't add unnecessary parentheses to your condition.
No. You add parentheses, so the precedence is unambiguously clear at first glance. Two extra characters are a very small and justifiable price to pay for clarity and maintainability.
-
Two extra characters are a very small and justifiable price to pay for clarity and maintainability.
You don't use spaces for clarity and maintainability?
-
No. You add parentheses, so the precedence is unambiguously clear at first glance. Two extra characters are a very small and justifiable price to pay for clarity and maintainability.Order of operations? I DUNNO LOL, just add more parentheses so idiots like me won't have to think too hard.Okay, that's your style. My style is
- figure out exactly how it works
- do the minimum to get exactly the desired result
That means not using unnecessary parentheses.
-
My style is
- figure out exactly how it works
- do the minimum to get exact the desired result
That means not using unnecessary parentheses.
I guess you also don't write comments, don't use
{
and}
around single-statementif
-bodies and so on?Also, you don't use more than one programming language, I guess? Especially not one that has
||
,&&
but alsoor
andand
(which have different precedence than the former two operators)?
-
do the minimum to get exactly the desired result
Really? Minimalism is your primary goal? Is typing difficult for you? Do you pay for code by the character? Are you a fan of Perl?
For most of us, maintainability and correctness trump everything else. Minimalism rarely aids maintainability.
-
That means not using unnecessary parentheses.
You're probably also the kind of guy who likes "elegant" solutions that everyone else needs to look at for at least 15 minutes to understand them.
-
Minimalism rarely aids maintainability.
I worked at one place where that would result in an automatic code review rejection. (that was a good thing) When I started there, it was actually fairly easy learning the code because it didn't try to be clever.
-
I assume you are referring to rules like "Always enclose conditional blocks in braces." Where leaving out braces for a single statement block introduces the risk of adding a second line and forgetting that you need to block it to get the intended result.
I hope they didn't reject this:
a = b + c + d;
... and make the programmer resubmit as ...
a = (b + c) + d;
-
a = (b + c) + d;
Huh. Apparently that's Lisp code. And the one above is "ini".
Nice one highlighter...
-
that's Lisp code
22% of the symbols are parentheses, Lisp seems like a reasonable guess.
-
That's actually a really good example.
Butbutubutbut I can't remember which addition it does first! I can't remember whether it matters for addition or not! Instead of taking 15 minutes to actually understand how your math and logic operators work, why not just add some parentheses to make it obvious?
-
I apologize for giving you ammunition in this argument. Here's my attempt to undo the damage I've done:
CREATE PROC FireSomeone (@employeeID int, @departmentID int) AS UPDATE employees SET status = 'terminated' WHERE employeeID = @employeeID AND departmentID = @departmentID OR @departmentID IS NULL GO EXEC FireSomeone 12, NULL
-
SQL ERROR 1024: @ACCALIA'D PROCEDURE NAME
-
Spelling error fixed... this comment is here so your post doesn't look insane.
-
AND
takes precedence overOR
in SQL, so...In fact, it usually takes precedence.
Pay attention to what you're writing, I guess. That's just sloppy coding, on par with someone who wrote
a * b + c
when they meanta * (b + c)
.
-
If T-SQL you can use parens on your AND and ORs, I highly recommend using parens. Instead of memorizing precedence rules.
-
Good catch. @Jaime, plausible disgruntled bomb.
-
XML += myadorecorset.Fiels[0].ToSTring()
"My Adore Corset"? what?
myadorecordset = new ADODB.Recordset();
...oh, I read that wrong.
...wait...XML += my-adore-corset.Fiels[0].ToSTring()
no, I didn't.
there's some corsets I adore too. none of them is mine, though :'(