255 reputation
14
bio website
location
age 39
visits member for 3 years
seen Mar 3 at 9:34

Oct
15
awarded  Critic
Oct
15
comment Functions with side-effects in Delphi/Pascal
-1 Please don't promote excessive exception handler bloat.
Sep
26
comment If your unit test code “smells” does it really matter?
Excellent answer. I have just one small quibble: far more important than "one logical assertion per test" is one action per test. The point is no matter how many steps it takes to arrange a test, there should only be one "production code action under test". If said action should have more than one side-effect, you may well have multiple assertions.
Sep
26
comment If your unit test code “smells” does it really matter?
@Sklivvz Copy/paste code in tests is not necessarily a problem in itself. It's generally far more important for test code to read naturally. However, if you do find yourself with "high maintenance" tests, that's more likely an indicator of other problems... Are you using a decent refactoring editor to make many trivial edits easy? Do have lots of almost identical tests? (Perhaps "congruent" tests would be a good term i.e. no significant variation between tests E.g. 1+1=, 1+2=, 1+3=, 1+4, etc.) Do you have the right split between Test Classes, Test SetUp, and actual test code?
Sep
26
comment If your unit test code “smells” does it really matter?
+1 I suggest adding a smell that tests with a lot of decision logic and calls to subroutines is a big red flag. The point is that tests should be very easy to read. If a test fails and you have to spend 5 minutes deciphering test code before you even touch the production code - you have a big problem! Unfortunately obsession with DRY and tendency to fall into "old production coding style tends to lead to very smelly test code.
Sep
24
comment Why use an OO approach instead of a giant “switch” statement?
Re: "EDIT2" First, the question was about OO vs. switch - bunch of it/else doesn't feature. Second, switch using a jump table would be O(1) i.e. constant & if/else O(n) i.e. linear - neither is logarithmic. Third, switch (if appropriate in the first place) is both faster and more readable than if/else - so there's not much to debate about. (However: yes switch is faster. But n is usually too small to make a real difference. Even at 50 options, if overall performance is improved that much, the method is probably called too often.)
Sep
23
comment Is object pooling a deprecated technique?
The only thing I need to warm up is the coffee!
Sep
23
awarded  Commentator
Sep
23
comment Is object pooling a deprecated technique?
@user10326 RE: "So one should design its classes and benchmark and then decide to use pooling? But this could require refactoring the whole code." I really don't see how. I think you're making a mountain out of a (possibly non-existent) molehill. If you've designed your system to keep object creation as a separate concern in the first place, the refactoring should be trivial. Even if you haven't, switching 1 or 2 classes to use a pool shouldn't be too difficult.
Sep
22
answered What causes bad performance in consumer apps?
Jul
3
awarded  Yearling
Jul
2
awarded  Teacher
Jul
2
answered DRY, string, and unit testing
Jul
1
comment Do poor writers make poor programmers?
I'm in agreement with @n1ckp. I'm also willing to bet his choice of names for variables/methods/classes would sometimes be cryptic and confusing. I tend to be very wary of programmers with extremely high productivity, because it often comes at the expense of spending a little extra time to improve long term maintainability.
Jul
1
answered Are unit tests really used as documentation?
Jul
1
comment How do you define elegant code?
@Chad I understand your concern with the term succinct. Perhaps there are people who equate the term with code-golf. Personally I don't consider o.a(b).c(d) to be succinct/elegant at all - it's just cryptic. Whereas Date.AddHour(mBeginHour).AddDays(mBeginDay) is about as succinct as possible in most languages. The only thing more succinct would be Date.Add(x days, y hours).
Jul
1
comment “Kill switch” in customer hosted environments, to protect payment?
+1 esp. for "Don't be afraid of your client just because he's a lawyer" ... If you take the aw(e) out of lawyer, what are you left with?
Jul
1
comment Are programmers bad testers?
@Tacroy You're making the assumption that I'm "making assumptions (about users)". Your assumption is totally wrong. ;) If I'm to be making any assumption at all, it's that: programmers who say "That's impossible!" instead of "How could that be possible?" aren't as good as they think they are. When a programmer develops an application there are always assumptions about it's environment (eg. genealogy system assumes time travel is impossible). When a program 'misbehaves', the programmer needs to put aside arrogant confidence, consider evidence, ask how and reassess those assumptions.
Jul
1
comment Are programmers bad testers?
@MadKeithV "in testing you should not use logical thinking to eliminate "unnecessary" tests": You certainly need some means of eliminating certain tests, otherwise you'll test forever. If not "logical thinking", then what exactly do you propose? Personally if I'm testing something that adds two numbers, I would apply logical thinking so I don't test: (1+1,1+2,1+3...), (2+1,2+2,2+3...), (3+1,3+2,3+3...)...**forever** Furthermore, I use logical thinking to test permutations like: 0+x,x+0,pos+neg,neg+pos,large+small,small+large. Yes logical thinking has me consider the last two options!
Jun
29
comment Are programmers bad testers?
@MadKeithV is that more indicative of "logical thinking being detrimental to good testing" or "a programmer who is not as good at logical thinking as he'd like to believe"?